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.
