Re: RFD, draft patch: IRA costs for reg_equiv_invariant regs

[Jeff Law <law at redhat dot com>]

On 06/02/10 15:14, Vladimir Makarov wrote:
> Bernd Schmidt wrote:
> > 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'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.
> I've redone it twice and now the degradation on perlbmk is about 1% on 
> my Corei7 machine.  I also checked my Core2 machine,  perlbmk with  
> your patch is 0.5%  better.  So  I think  it is  my Core i7 specifics 
> (it is very early version of  the processor).   But even with the 
> degradation on the Corei7 the overall SPECInt2000 score is 0.4% better 
> with your patch.
>
> Sorry for this issue and wasting your time.   The patch is ok to 
> commit.  Thank you for working on this problem.
Is perlbmk generally stable?  I vaguely recall perl from spec (95?  2k?) 
which highly sensitive to the placement of spills on the stack, at least 
on some processors.    After the joys of tracking it down I generally 
ignored the results of the perl component.

Jeff