This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: new-new-ra thoughts


Steven Bosscher <stevenb@suse.de> writes:

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

I can try to anwer all questions about pre-reload and web-class.

Denis.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]