This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug rtl-optimization/50213] [4.6/4.7 Regression] Regression in space-optimized code relative to 4.5.x


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]