[Bug rtl-optimization/67145] [6 Regression] associativity from pseudo-reg ordering

[rth at gcc dot gnu.org]

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.