RFD, draft patch: IRA costs for reg_equiv_invariant regs

[Jeff Law]

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