new-new-ra thoughts

[neroden at fastmail dot fm (Nathanael Nerode)]

Steven Bosscher wrote:
>1) It tries *really* hard to do well for subregs, which is kinda
>   nice, but it causes an immense amount of cruft in the register   
>   allocator, throughout.  The proper fix would be to try and
>   avoid subregs as much as possible, and leave it to reload to
>   fix up that mess.
Well, I can't really agree with that *at the moment* given the amount of
subregs which seem to be used currently.  But frankly I don't understand
subregs.

Does someone have a list of the major uses of subregs?  :-)  Maybe we can work
out some more logical treatment of them.

...
>2) The version on mainline finds itself overruled by reload too
>   often.  The fix on the new-regalloc branch is pre-reload,
OK.  I think we're agreed that pre-reload or some equivalent "make them satisfy
their constraints" pass is actually a pretty good idea
and will help in any future register allocation strategy.  How messy is the
stripped pre-reload on the new-regalloc branch?  Would it make a decent
basis for such a pass, or is it better to Start From Scratch?

...
>3) It does not include enough information in the conflict graph.
OK, this is enough reason to write a new regalloc.  :-)

>There really are at least three good ideas on the new-regalloc branch
>that are IMHO must-haves for a graph coloring register allocator for
>GCC:
>- web class, to replace regclass and choose register classes for
>  webs instead of pseudos.  This also includes splitting webs if
>  a register in a web really wants to be in two different classes
>  to satisfy constraints in two different insns.  Right now, as
>  far as I understand, regclass just picks one and lets reload
>  figure out how to fix up that mistake.
Hmm.  Unfortunately, I don't see how we can steal code from the branch
for that if we're going to write a new allocator....

>- A semi-strict RTL mode.  Right now there is just strict and
>  non-strict.  On the branch there is a semi-strict mode which is
>  the same as strict RTL except that pseudo-registers are still
>  allowed.
...but this, on the other hand, sounds like it could be its own patch and
probably could be put in mainline pretty quickly (once we reach stage 1) and
would be a useful tool for the future.

-- 
This space intentionally left blank.