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: GVN-PRE sucks -- well, for SPECCFP2000 mgrid anyway


Hi,

On Sun, 15 Aug 2004, Daniel Berlin wrote:

> > This is handled differently in different compilers.  There are basically two
> > schools of thought here:
> > 
> > 1) let pre be pre and have the register allocator "rematerialize" the guys
> > that have been pulled out of the loop.
> > 
> 
> I've always tried to argue this approach, but it never seems to get places
> with people, because it means the register allocator doing *a lot*.

I'm also a fan of this approach.  On the new-regalloc branch, there is a 
start for infrastructure for rematerializing expressions.  Up to now 
it more or less is constrained to constant expressions, or those where the 
operands are trivially proved live everywhere, and not-spillable (like for 
instance offsets from the frame pointer).

It currently just lacks the functions to validate arbitrary expressions, 
i.e. if their operands are still valid at the place where they are to be 
rematerialized.  Also missing is choosing which expressions to 
rematerialize, if given a big set of possibilities.  There are some 
approaches in the wild to minimize work, and be sure that such 
rematerialization is not pessimizing the code again.  The most powerful 
one unfortunately requires SSA form, which we can't have in RTL (subregs), 
so we need to constrain ourself to the easy cases.  But those should 
catch most things, in particular if one handles arbitrary expressions of 
operands which are defined only once (by luck).


Ciao,
Michael.


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