new-new-ra thoughts

[Steven Bosscher]

I 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.

To which Nathanael Nerode replied:

> 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.

And Jeff Law replied:

> I would tend to disagree.  Yes, I'd like to avoid subregs, but I think
> they are going to be unavoidable for a long long time.  And doing a 
> good job on them is actually reasonably important.

First of all, if subregs are so important, why do local-alloc.c and
global.c almost ignore them?  I think a new RA effort should not try
to do everything better all at once, like new-ra did.  Not follwing
existing practice and doing lots of work to compute subreg conflicts
is one of those things that made new-ra so incomprehensible.


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

I don't know how they are used exactly, but I can give you some
numbers.  For a c,c++,f95 bootstrap, I have the following number
of subregs in the .lreg dump, the number of SETs to a SUBREG, and
a total number of SETs (ie. "grep subreg *.lreg|wc ",
"grep subreg *.lreg|grep -w set|wc", and "grep -w set *.lreg|wc".):

TARGET        # SUBREGs     # SETs to a SUBREG     TOTAL # SETs
amd64         13657           549                  1391975
i686           9921           342                  1382996
ppc (C only)  51337         13289                  1490724

FWIW many of the ppc SUBREGs are paradoxical, e.g. for TREE_CODE:
(compare:CC (subreg:SI (reg:QI 246 [ <variable>.common.code ]) 0)


> How messy is the 
> stripped pre-reload on the new-regalloc branch?

Very.


> Would it make a decent 
> basis for such a pass,

No.

> or is it better to Start From Scratch? 

Yes.

Gr.
Steven