On 6/26/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
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.
I think the overall idea of RABLET is quite sound. Especially if integrating
expand with out-of-ssa this might provide early instruction selection (now, that
would possibly require moving all of RTL loop optimizations before this point).
Of course re-doing expand is the hard part here...
Richard.
