This is the mail archive of the
mailing list for the GCC project.
Re: new-new-ra thoughts
- From: Steven Bosscher <stevenb at suse dot de>
- To: gcc at gcc dot gnu dot org
- Cc: Nathanael Nerode <neroden at fastmail dot fm>, law at redhat dot com
- Date: Wed, 5 Jan 2005 10:31:35 +0100
- Subject: Re: new-new-ra thoughts
- Organization: SUSE Labs
- References: <20050105034950.GA3340@fastmail.fm>
> >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
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?
> Would it make a decent
> basis for such a pass,
> or is it better to Start From Scratch?