Re: [PING][PATCH][REVISED] Fix PR middle-end/PR28690, modify swap_commutative_operands_p

["H.J. Lu" <hjl at lucon dot org>]

On Tue, Jul 17, 2007 at 08:49:22AM +0300, Paolo Bonzini wrote:
> 
> >Why not make the default conservative so that the impacts on other
> >processors are minimum and generating decent code for Power 6 at the
> >same time?
> 
> Because you still haven't gotten it that all your performance impacts 
> are red herrings.  I believe we can fix them.

Why make a big change when a small change is good enough and we
can't show that a big change improves performance? 

> 
> For example, you didn't get my suggestion on -frename-registers.  I'm 
> not suggesting you should use -O2 -frename-registers, I was trying to 
> validate your hypothesis that OOO scheduling pessimizes performance: if 
> -frename-registers improves performance a lot, that's true.  Otherwise 
> it's probably not.  If rename registers happens to be effective on x86, 
> work hard to improve it and to make it faster so that it can be enabled 
> at -O2.

You know adding -frename-registers to -O2 isn't as easy as you
suggested even if it may improve sereval benchmarks by 5% since it
hurt others by 4%. It will a long time to make it consistent and
fix all the bugs since it has't been widely tested. I doesn't think
it makes senses to use

1. REG_POINTER
2. MEM_POINTER
3. REG_P
4. MEM_P

when

1. REG_POINTER/MEM_POINTER
2. REG_P/MEM_P

also works around Power 6 issue. What do you get with

1. REG_POINTER
2. MEM_POINTER
3. REG_P
4. MEM_P

on performance? Can you show it?

> 
> Don't shoot patches whose rationale you apparently did not try to 
> understand, just because they are prepared to help another architecture. 
>    PR19653 was a reload fix that broke three or four architectures in 
> the beginning, but caused 100% improvements on some SSE code.  I bet you 
> wouldn't have used the same way of measuring impact in that case.
> 
> Maintainers (I am not one) have in the past rejected common-code 
> modifications if they could hurt other architectures in a predictable 
> way.  But if they hurt in an unpredictable way, I would say it's the 
> architecture's fault, not the patch.  Try to understand *what* *could* 
> *help* *x86* *for* *real*, file PRs, and I bet people will help 
> implementing it.

I am not against middle end patches improving Power 6. The problem
I have is use a bigger change when a smaller change can address Power
6 and we have nothing to show for on performance with the bigger one.



H.J.