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.
