http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50213
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-09-06
15:45:10 UTC ---
This regressed with http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161655
and with -Os -fno-tree-forwprop you get the same code as you used to get
before.
At the tree level, the difference seems to be in
<bb 3>:
- D.2724_9 = *p_8;
+ D.2724_9 = MEM[(const unsigned int *)p_2 + -4B];
csum_10 = csum_1 ^ D.2724_9;
<bb 4>:
# csum_1 = PHI <0(2), csum_10(3)>
# p_2 = PHI <p_6(2), p_8(3)>
p_8 = p_2 + -4;
if (p_8 > tlv_5(D))
goto <bb 3>;
else
goto <bb 5>;
<bb 5>:
- D.2724_11 = *p_8;
+ D.2724_11 = MEM[(const unsigned int *)p_2 + -4B];
being now done in forwprop while it wasn't possible before MEM_REF - it wasn't
valid GIMPLE.
While in the loop IVOPTs undoes the undesirable transformation back to
MEM[base: p_8], in bb5 as it is not a loop we keep the longer form and thus use
a var from the middle of the loop instead of p after the loop. That results in
different expansion.
