https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67145
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-08-10
Summary|[6 Regression] Innefective |[6 Regression]
|plus-minus simplification |associativity from
| |psuedo-reg ordering
Ever confirmed|0 |1
--- Comment #1 from Alan Modra <amodra at gmail dot com> ---
This is what is really going on. Shown below are the first two differences at
expand, shorn of irrelevant insn numbering, clobbers etc.
r224767 r224768
(set (reg:SI 143) (set (reg:SI 143)
(plus:SI (reg/v/f:SI 134 [ in ]) (plus:SI (reg/v/f:SI 134 [ in ])
(reg/v:SI 139 [ x ]))) (reg:SI 142)))
(set (reg/f:SI 144) (set (reg/f:SI 144)
(plus:SI (reg:SI 143) (plus:SI (reg:SI 143)
(reg:SI 142))) (reg/v:SI 139 [ x ])))
...
(set (reg:SI 151) (set (reg:SI 151)
(plus:SI (reg/v/f:SI 134 [ in ]) (plus:SI (reg/v/f:SI 134 [ in ])
(reg/v:SI 139 [ x ]))) (reg:SI 150)))
(set (reg/f:SI 152) (set (reg/f:SI 152)
(plus:SI (reg:SI 151) (plus:SI (reg:SI 151)
(reg:SI 150))) (reg/v:SI 139 [ x ])))
It isn't too hard to see why fwprop sees an optimisation opportunity for one
but not the other.
The questions I have are:
1) Why isn't "in + x" hoisted out of the loop?
2) If we care about associativity, isn't the r224768 ordering correct in that
it follows the gimple association? See gimple below.
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?
# ivtmp.7_47 = PHI <ivtmp.7_42(3), 0(2)>
_11 = *pretmp_53;
_13 = _11 + x_12(D);
_14 = (sizetype) _13;
_16 = in_15(D) + _14;
_17 = *_16;
MEM[base: out_4(D), index: ivtmp.7_47, offset: 0B] = _17;
_21 = *pretmp_54;
_22 = x_12(D) + _21;
_28 = *pretmp_57;
_29 = _22 + _28;
_30 = (sizetype) _29;
_31 = in_15(D) + _30;
_32 = *_31;
MEM[base: out_4(D), index: ivtmp.7_47, offset: 1B] = _32;
