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
