This is the mail archive of the 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: Project RABLET

On Sun, 2006-06-25 at 01:04 -0400, Vladimir N. Makarov wrote:
> Andrew MacLeod wrote:

>   Having no information about the final register allocator decision,
> the partial register pressure reducing through rematerialization is
> not working in many cases.  For example, making rematerialization of
> a <- b + c
> when you reduce the pressure from 100 to 50 for x86 there is a big
> chance that b and c will be not placed in hard registers.  Instead of
> one load (of a), two loads (b and c) will be needed.  This result code
> is even worse than before reducing pressure.

Having implemented a complex rematerialization pass before, I understand
it well enough to know that replacing 'a' with 'b + c' is the wrong
thing to do, unless at least one of b or c is used again right next to
the use of 'a'. That can actually increase register pressure, or have
nothing more than a neutral effect. Its *way* more complicated than
simply moving expressions downward. Its tracking all the things used in
expressions and determining that at a given location, it *is* worthwhile
to do it because the correct values are already trivially available, or
can alternatively be recomputed in a worthwhile way. Often, there are
only a few worthwhile remats out of all the possible ones.

In general, I have never found the primary benefit of rematerialization
to be register pressure reduction, but rather one of avoiding placing
stores to spill in the instruction stream.  When there is a lot of
spilling, those stores can really bog down a pipeline. 

>   So rematerialization in out-of-ssa pass will work well only for full
> pressure relief (to the level equal to the number of hard registers)
> or close to the full relief.

That's a pretty broad assertion to make, and I disagree with it :-)
Especially when you only talk about a single component of the whole. 

 RABLET is a group of things which tend to enable each other. Any one of
them by themselves would actually accomplish less. Some of the required
components have a benefit of some sort unrelated to the others (such as
faster out of ssa translation). Others require interaction with the
whole to see any benefit. 

Remember that one of the components is a new integrated expand... RABLET
will have an understanding of the instructions that can be generated,
and will try to make use of those when making decisions. 

An additional benefit likely to be seen from this is that code tends to
utilize more of the variable names the user will recognize, rather than
something like 'SPILL_678'. And maybe, just maybe, it'll be easier to
get the debug info correct (TER can muck it up pretty badly :-)

> The SSA pressure relief through rematerialization described in
> Simpson's theses is oriented for such architectures (with a big
> regular register file size of 32 as I remember).  So it can work for
> ppc but it will be less successful for major interest platforms x86 and
> x86_64.

I haven't read the thesis, but I would be surprised if it describes what
I am planning to do. Without the integration with expand to do
instruction selection, a few tweaks in some RTL optimizations, and a
very specific gcc-oriented union of all these components, what I am
planning to do would be completely worthless. Remat is really a small
part of it.

What benefit I will see?  Well, time will tell :-)


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