Re: SPEC sixtrack regression on 64 bits machines

[Daniel Berlin <dberlin at dberlin dot org>]

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.