[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534

--- Comment #15 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #14)
> I wonder if this could be addressed with a more reasonable address
> computation reassociation.

> ISTM that we associating as (x + (y + c)) which seems like a mistake in this
> case.
> 
> If we associated as (x + y) + c, then the (x + y) would become a common
> subexpression eliminating a bunch of unnecessary address computations.

Coming out of SSA for hand_benchmark_cache_ronly(), we seem to be calculating:

((index + 1) * 8) + x
((index + 2) * 8) + x
((index + 3) * 8) + x
etc

After slsr we have:

(index * 8) + x
(((index * 8) + 8) + x)
((((index * 8) + 8) + 8) + x)

And finally after forwprop4:

(index * 8) + x
(((index * 8) + 8) + x)
(((index * 8) + 16) + x)

Are you suggesting we reassociate the above as:

((index * 8) + CONSTANT) + x

Is there a preferred place to put this kind of transformation?  A separate pass
after forwprop4?  Much earlier?  Is there a pass that already does this kind of
juggling?

BTW, it seems like a pass like tree-ssa-reassoc, tries to precisely convert:

x + (y + constant)  INTO (x + CONSTANT) + y

which is the opposite of what we want.