https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67145
Richard Henderson <rth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #10 from Richard Henderson <rth at gcc dot gnu.org> --- (In reply to Alan Modra from comment #1) > 1) Why isn't "in + x" hoisted out of the loop? With the patch in #c3, we do hoist indeed it during the rtl loop pass. That said... > 2) If we care about associativity, isn't the r224768 ordering correct in > that it follows the gimple association? See gimple below. ... > _13 = _11 + x_12(D); > _14 = (sizetype) _13; > _16 = in_15(D) + _14; This is tricky. The _11 + x_12 expression is signed, while of course the in_15 + _14 POINTER_PLUS_EXPR requires a sizetype. I don't see how we could re-associate at the gimple level without changing semantics. But once we lower to rtl, we lose signed vs unsigned, and can legitimately re-associate the expressions. > 3) If we want reverse associativity at the rtl level, isn't relying on > sorting done according to pseudo reg numbering deep inside a function > simplifying additive expressions, just a little bit fragile? It isn't the best way, I'll grant you. For this particular case, if x had pseudo number 200, we wouldn't have formed the in+x subexpression that turns out to be so helpful. What would be better is a primary sort for loop invariability. But we don't have that here. And when we're doing rtl loop optimizations we don't re-associate (to my knowledge). In the end, if we don't use *something* to produce a stable sort, then we're unlikely to see that w+x+y+z is equal to z+y+x+w. I still believe that the ppc backend should change to allow CA in any order, as Jakub suggested. I'll give it a go.