Hi!
The following testcase ICEs, because simplify_gen_binary (IOR, HImode, ...)
simplifies into (subreg:HI (reg:SI ...) 0), but was still passing
mode (HImode) as second argument to recursive combine_simplify_rtx call.
The second argument is op0_mode, so is supposed to be the real
mode which should be assumed for its first operand.
Passing mode in that case is only safe if simplify_gen_binary doesn't
actually simplify it, but as simplify_gen_binary would simplify constant
arguments anyway into a constant, it doesn't make any sense to hint
combine_simplify_rtx about the original op0_mode. That is something
only useful when called from subst, which simplifies the operands (which may
turn them from non-VOIDmode into VOIDmode) and then calls
combine_simplify_rtx to simplify the whole operation.
The second part of the patch attempts to optimize more, as
simplify_gen_binary may already simplify the expression, so often (including
the testcase) combine_simplify_rtx doesn't simplify anything, i.e.
tor == temp, yet it is simplified over (ior plus_arg0 plus_arg1).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
For 4.6, I think safer would be just the first one liner change to pass
VOIDmode to combine_simplify_rtx. Is that ok for 4.6?
2011-07-04 Jakub Jelinek <ja...@redhat.com>
PR rtl-optimization/49619
* combine.c (combine_simplify_rtx): In PLUS -> IOR simplification
pass VOIDmode as op0_mode to recursive call, and return temp even
when different from tor, just if it is not IOR of the original
PLUS arguments.
* gcc.dg/pr49619.c: New test.
--- gcc/combine.c.jj 2011-06-21 16:46:01.000000000 +0200
+++ gcc/combine.c 2011-07-04 16:05:52.000000000 +0200
@@ -5681,12 +5681,17 @@ combine_simplify_rtx (rtx x, enum machin
{
/* Try to simplify the expression further. */
rtx tor = simplify_gen_binary (IOR, mode, XEXP (x, 0), XEXP (x, 1));
- temp = combine_simplify_rtx (tor, mode, in_dest, 0);
+ temp = combine_simplify_rtx (tor, VOIDmode, in_dest, 0);
/* If we could, great. If not, do not go ahead with the IOR
replacement, since PLUS appears in many special purpose
address arithmetic instructions. */
- if (GET_CODE (temp) != CLOBBER && temp != tor)
+ if (GET_CODE (temp) != CLOBBER
+ && (GET_CODE (temp) != IOR
+ || ((XEXP (temp, 0) != XEXP (x, 0)
+ || XEXP (temp, 1) != XEXP (x, 1))
+ && (XEXP (temp, 0) != XEXP (x, 1)
+ || XEXP (temp, 1) != XEXP (x, 0)))))
return temp;
}
break;
--- gcc/testsuite/gcc.dg/pr49619.c.jj 2011-07-04 16:04:21.000000000 +0200
+++ gcc/testsuite/gcc.dg/pr49619.c 2011-07-04 16:04:06.000000000 +0200
@@ -0,0 +1,13 @@
+/* PR rtl-optimization/49619 */
+/* { dg-do compile } */
+/* { dg-options "-O -fno-tree-fre" } */
+
+extern int a, b;
+
+void
+foo (int x)
+{
+ a = 2;
+ b = 0;
+ b = (a && ((a = 1, 0 >= b) || (short) (x + (b & x))));
+}
Jakub
