Re: simplify_plus_minus busted in 4.3

[Paolo Bonzini <bonzini at gnu dot org>]

Paolo Bonzini wrote:
> Bernd Schmidt wrote:
>> While trying to teach the doloop code new tricks in our Blackfin tree
>> based on 4.3, I've noticed that simplify_plus_minus appears to be
>> busted.
> 
> I will try on 4.4 and let you know.  I remember some fixes going in for
> s_p_m; all of them could be backported to your tree, even though some
> were unsafe for other targets (they depended on using UNSPECs rather
> than MINUSes for things such as PIC access).

Here it is (extracted from r142035).  In
http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00792.html Zdenek said
"simplify-rtx.c:simplify_plus_minus may fail before it actually tries to
simplify the expression, so it may e.g. leave (x+y)-y unsimplified" and
that seems exactly your case).

As I said in the previous email, it is safe for Blackfin even though I
am not sure it would be okay for the FSF 4.3 tree.

Paolo

Index: simplify-rtx.c
===================================================================
--- simplify-rtx.c	(.../branches/gcc-4_3-branch/gcc/simplify-rtx.c)	(revisione 144054)
+++ simplify-rtx.c	(.../trunk/gcc/simplify-rtx.c)	(revisione 144054)
@@ -3574,10 +3604,6 @@ simplify_plus_minus (enum rtx_code code,
           ops[j + 1] = save;
         }
 
-      /* This is only useful the first time through.  */
-      if (!canonicalized)
-        return NULL_RTX;
-
       changed = 0;
       for (i = n_ops - 1; i > 0; i--)
 	for (j = i - 1; j >= 0; j--)
@@ -3633,10 +3659,15 @@ simplify_plus_minus (enum rtx_code code,
 		    ops[i].neg = lneg;
 		    ops[j].op = NULL_RTX;
 		    changed = 1;
+		    canonicalized = 1;
 		  }
 	      }
 	  }
 
+      /* If nothing changed, fail.  */
+      if (!canonicalized)
+        return NULL_RTX;
+
       /* Pack all the operands to the lower-numbered entries.  */
       for (i = 0, j = 0; j < n_ops; j++)
         if (ops[j].op)