RFD, draft patch: IRA costs for reg_equiv_invariant regs

[Bernd Schmidt]

Sorry for not replying for a while, I was on a different project for a
few weeks.

On 05/14/2010 01:03 AM, Vladimir N. Makarov wrote:
> I very like the idea of the patch.  But IMHO, it might create some
> problems too.  For example, you have invariant fp + constant.  You can
> not say will it be valid expression after elimination into bp + constant
> until you know the final frame size which is mostly known after RA and
> assigning stack slots for spilled pseudos.  So for some cases and some
> targets, the result might be not what you expected.

That's true, but we're replacing an always-incorrect cost with something
that is much more likely to be correct.

If this scenario ever turns out to be a problem, we could try to
speculatively allocate a hard reg to such pseudos as a final step of
register allocation if there are still hard regs available.  Then,
reload could be modified to choose between using the hard reg or using
the equivalence depending on which is better.

> I've run SPEC2000 benchmarks on x86/x86_64 (-O3 -mpc64 for x86 and -O3
> for x86_64) on Core i7.  The SPEC ratio looks good for x86_64
> (practically the same or may be even a bit better, although it is hard
> to say, than without the patch) but there is a big average code size
> increase about 0.9% on SPECFP2000 (biggest one is more 5% on mgrid).
> 
> SPECFP2000 for x86 is the same too but SPECInt2000 is 0.5% worse with
> the patch (mostly because of more than 5% degradation on perlbmk).  The
> code size is ok for x86 (in range of 0.03% change).

Can you redo these tests?  I just ran tests with current gcc sources.
For 32 bit SPEC2k on a Westmere Xeon (essentially Core i7) I'm seeing  a
minor perlbmk improvement with various compilation options including -O3
-mpc64.

> So there is a small harm for x86/x86_64.  It would be nice to
> investigate and fix (if it is possible) code increase on SPECFP2000 for
> x86_64 and perlbmk degradation on x86.

I think I have a fix on the x86_64 code size problem; patch to come.

On a not-quite-unrelated note, in the 2004 GCC summit proceedings you
write that you had implemented rematerialization.  Do you still have the
patch?


Bernd