Rakudo *Needs* Register Allocation

chromatic chromatic at wgz.org
Mon Jun 28 19:16:29 UTC 2010

On Monday 28 June 2010 at 00:40, Peter Lobsinger wrote:

> Those aren't the temporaries I'm referring to. Many PIR operations
> which appear to be single ops compile down to multi-op sequences which
> use temporary registers. For example "sqrt $N0, $I0" is internally
> "set $N<temp>, $I0 ; sqrt $N0, $N<temp>". As another example, every
> function call that IMCC cannot resolve statically uses a
> find_sub_not_null and a temporary. It can be almost guaranteed that
> any HLL compilation will hit several cases of these IMCC internal
> temporaries.

That's right; I'd forgotten about those.  I'm almost certain that IMCC's 
(naive) register allocation takes place after this; I don't know how it would 
work otherwise.

> Does IMCC really have more information than that available in PBC?
> What information is present in PIR, isn't present in PBC, and is
> relevant to register allocation or optimization in general?

It's somewhat easier to detect basic blocks in IMCC's internal structures than 
in PBC, but that's only relevant if we use some sort of graph coloring 
algorithm--in the case of an infinite register set, we're better off with linear 
> By all means, replace IMCC then. But whatever replaces it will also
> need to create these temporaries if it is to provide the same kind of
> op selection and desugaring to protect the users from lower-level
> aspects of Parrot. Full register allocation can only occur after the
> selection/desugaring step.

Agreed.  Register allocation *must* take place after desugaring.

-- c

More information about the parrot-dev mailing list