This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PING][PATCH][REVISED] Fix PR middle-end/PR28690, modify swap_commutative_operands_p


On Fri, Jul 13, 2007 at 09:34:09PM +0200, Paolo Bonzini wrote:
> 
> >It will take 2 days. SPEC CPU 2K results aren't very encouraging.
> >One benchmark is down by 7% on IA32.  I suspect AMD processors may
> >have similar issues. Given the SPEC CPU 2K/2006 impact I have been
> >seeing on IA32 and Intel64, and the current addresing model has been
> >used for such a long time, I don't think it is a good idea to make
> >such a change which affects every architecture for one architecture.
> 
> Some SPEC benchmarks are notoriously volatile, and the more 
> sophisticated the cores, the worse this can be.  The impact of this 
> patch has been analyzed a handful of times.  Once it was an effect of 
> loop alignment, arguably a latent bug.  This time it was out-of-order 
> execution, and nobody outside Intel knows how this works.  Next time we 
> don't know what it will be.
> 
> I understand your position because in the beginning I was also thinking 
> that this change should have been done in target-dependent code; however 
> 1) the benefits on POWER have been clearly identified, unlike the reason 
> for the performance problems on Intel 2) canonicalization is in general 
> a good thing, and 3) the next iteration of Intel/AMD processors might 
> also prefer base registers to come first in indexed addressing modes.

I see several problems in the patch:

1. The x86 backend is optimized based on the current addressing model
over several years. Changing the addressing model may take a long
time to get back the performance loss this change causes.
2. There is no performance tracking on most backends. Performance
loss on those backends may not know for months, at which time, it
may be very hard to go back without side-effects.
3. I believe this patch can be broken into several independent parts.
Evaluate them one by one will help us better understand their
performance impacts, at least on x86.


H.J.


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