Rakudo *Needs* Register Allocation

chromatic chromatic at wgz.org
Mon Jun 28 00:26:47 UTC 2010


On Sunday 27 June 2010 at 16:33, Andrew Whitworth wrote:

> Do you think it should be
> part of normal POST operation, or added as an optional optimization
> step? I ask because we might want multiple pluggable/selectable
> allocators, and we may want to turn off the fancier ones entirelywhere
> speed is an issue.

I believe that POST already has some idea of the lifespan of registers (as it 
has to track their names), but I'm pretty sure it does no basic block tracing.  
It'd be nice to take advantage of the lifespan information where it's 
available.

An analysis step *could* poke into POST nodes to find ops which form the 
boundaries of basic blocks, and then perform visibility analysis there.  I 
suspect that functions which need hundreds of registers now would compile more 
slowly with a smart allocator, but the runtime benefit could be measurable.  
Maybe it's something we should do only on functions that use more than a dozen 
registers of a type.

-- c


More information about the parrot-dev mailing list