SPEC sixtrack regression on 64 bits machines

SPEC sixtrack regression on 64 bits machines

[Steven Bosscher]

Hi,

Something commited a few days ago had resulted in a serious performance
hit for SPEC sixtrack on 64 bits machines...  The obvious suspect is
Sebastian Pop's scev patch.  The affected targets are at least AMD64 [1]
and PPC64 [2] but not i686 [3].

Sebastian, any idea what might have caused this?

Gr.
Steven

[1] http://www.suse.de/~aj/SPEC/amd64/CFP/summary-britten/200_sixtrack_recent_big.png
[2] http://people.redhat.com/dnovillo/spec2000.ppc64/gcc/200.sixtrack-run-ratio.png
[2] http://people.redhat.com/dnovillo/spec2000.i686/gcc/200.sixtrack-run-ratio.png

Re: SPEC sixtrack regression on 64 bits machines

[Sebastian Pop]

Steven Bosscher wrote:
> Hi,
> 
> Something commited a few days ago had resulted in a serious performance
> hit for SPEC sixtrack on 64 bits machines...  The obvious suspect is
> Sebastian Pop's scev patch.  The affected targets are at least AMD64 [1]
> and PPC64 [2] but not i686 [3].
> 
> Sebastian, any idea what might have caused this?
> 

doing a diff between the ivopts dump of current mainline and mainline
with patch for PR22236 reverted, I'm getting lots of:

-  (scalar_evolution = {(int8) lsm_tmp.63_323, +, 1}_3))
+  (scalar_evolution = (int8) {lsm_tmp.63_323, +, 1}_3))

These are due to the fact that scev_probably_wraps cannot prove that
these iv do not wrap (because the initial condition is unknown), so
the conversion fails and the cast is just kept around.

The consequence is that later on, you get less variables eliminated,

-  D.897_174 is invariant (19), eliminable
+  D.897_174 is invariant (19)

and in the context of a loop, a higher register pressure could cause
the regression.  Why is this happen on amd64 and not i686?  Because
type conversions are much more numerous on amd64, so simple iv on i686
would be wrapped into casts on amd64.

So the fix for this performance regression (if there is a fix...) is
to track every case where we get less precise information, and try to
improve the knowledge of the analyzer for making it again able to
convert.  I'll work on some patches.

seb

Re: SPEC sixtrack regression on 64 bits machines

[Daniel Berlin]

On Wed, 2005-08-17 at 02:45 +0200, Sebastian Pop wrote:
> Steven Bosscher wrote:
> > Hi,
> > 
> > Something commited a few days ago had resulted in a serious performance
> > hit for SPEC sixtrack on 64 bits machines...  The obvious suspect is
> > Sebastian Pop's scev patch.  The affected targets are at least AMD64 [1]
> > and PPC64 [2] but not i686 [3].
> > 
> > Sebastian, any idea what might have caused this?
> > 
> 
> doing a diff between the ivopts dump of current mainline and mainline
> with patch for PR22236 reverted, I'm getting lots of:
> 
> -  (scalar_evolution = {(int8) lsm_tmp.63_323, +, 1}_3))
> +  (scalar_evolution = (int8) {lsm_tmp.63_323, +, 1}_3))
> 
> These are due to the fact that scev_probably_wraps cannot prove that
> these iv do not wrap (because the initial condition is unknown), so
> the conversion fails and the cast is just kept around.
> 
> The consequence is that later on, you get less variables eliminated,
> 
> -  D.897_174 is invariant (19), eliminable
> +  D.897_174 is invariant (19)
> 
> and in the context of a loop, a higher register pressure could cause
> the regression.  Why is this happen on amd64 and not i686?  Because
> type conversions are much more numerous on amd64, so simple iv on i686
> would be wrapped into casts on amd64.
> 
> So the fix for this performance regression (if there is a fix...) is
> to track every case where we get less precise information, and try to
> improve the knowledge of the analyzer for making it again able to
> convert.  I'll work on some patches.

As a start, -funsafe-loop-optimizations should make scev_probably_wraps
return false in almost all cases.