This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: optimizations
- From: <tm_gccmail at mail dot kloo dot net>
- To: Reza Roboubi <reza at linisoft dot com>
- Cc: Bonzini <bonzini at gnu dot org>, gcc at gcc dot gnu dot org, gcc-help at gcc dot gnu dot org
- Date: Wed, 15 Jan 2003 13:47:14 -0800 (PST)
- Subject: Re: optimizations
On Wed, 15 Jan 2003, Reza Roboubi wrote:
> Bonzini wrote:
>
> CHANGE:
> -------
> .L2:
> movl -4(%ebp), %eax <== still does the load
> cmpl $16, %eax
> je .L7
> incl %eax
> movl %eax, -4(%ebp) <== and store
> jmp .L2
> .L7:
>
> TO:
> -------
> movl -4(%ebp), %eax
> .L2:
> cmpl $16, %eax
> je .L7
> incl %eax
> jmp .L2
> .L7:
> movl %eax, -4(%ebp)
The optimization you are suggesting is called "load hoist/store sink" if I
remember correctly.
Here is the story as I remember it:
When egcs-1.0 or 1.1 was released, people noticed a large performance
drop from gcc-2.7.2. I did a little investigation, and verified a large
performanc drop on Whetstone. I did a comprehensive analysis of it, and
isolated a case similar to yours where a variable in a critical loop was
entirely contained in registers in 2.7.2 but was loaded/save from/to
memory in gcc-2.95.
I mentioned this on the gcc-bugs mailing list, and Mark Mitchell
contributed a fairly simple load hoisting improvement to the loop
optmiizer which restored performance on Whetstone.
If you look at the gcc-bugs archives for 1998, you may be able to find
this message thread.
This load-hoisting optimization seems to be responsible for the hoisted
load in your testcase. However, the corresponding store sink portion of
the optimizer has never been written, and I believe that is why the store
is not sunk out of the loop on your testcase.
Toshi