https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64322
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-12-16
Ever confirmed|0 |1
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Well, I rather wonder how the store to an otherwise unused value can affect
the code. It doesn't on the GIMPLE level. I suppose RTL somehow invalidly
thinks that after b = 0; c = 0; b is still zero (so it only considers the
two volatiles aliasing but doesn't consider the b volatile).
It seems to be combine optimizing the case with c = 0, not sure why it doens't
with c = 0x1000000L. Ah, the large constant is split to a reg.
Difference:
-Successfully matched this instruction:
-(set (reg:DI 98)
- (ashift:DI (reg:DI 94 [ D.1849 ])
- (const_int 1 [0x1])))
-Successfully matched this instruction:
-(set (reg:DI 97 [ a ])
- (const_int 0 [0]))
-allowing combination of insns 10, 11 and 12
-original costs 4 + 3 + 0 = 0
-replacement costs 6 + 4 = 10
-deferring deletion of insn with uid = 10.
-modifying insn i2 11: {r98:DI=r94:DI<<0x1;clobber flags:CC;}
Otherwise I agree with Jakub that VRP should be enhanced (it's weak with
handling non-initeger-VR_RANGES for most codes).
But combine probably exposes a RTL simplification so I wonder if we can
add a similar one (after figuring out which one applies) on the GIMPLE level.
Confirmed (at -O2 both codes are bad).
