I had missed that integer_onep can match vector types with uniform constant of `1`.
This means the shifter could be an scalar type and then doing a comparison against `0`
would be an invalid transformation.
This fixes the problem by adding a check for the type of the integer_onep to make
sure it is a INTEGRAL_TYPE_P (which does not match a vector type).
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR tree-optimization/111414
gcc/ChangeLog:
* match.pd (`(1 >> X) != 0`): Check to see if
the integer_onep was an integral type (not a vector type).
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/pr111414-1.c: New test.
/* `(1 >> X) != 0` -> `X == 0` */
/* `(1 >> X) == 0` -> `X != 0` */
(simplify
- (cmp (rshift integer_onep @0) integer_zerop)
- (icmp @0 { build_zero_cst (TREE_TYPE (@0)); })))
+ (cmp (rshift integer_onep@1 @0) integer_zerop)
+ (if (INTEGRAL_TYPE_P (TREE_TYPE (@1)))
+ (icmp @0 { build_zero_cst (TREE_TYPE (@0)); }))))
/* (CST1 << A) == CST2 -> A == ctz (CST2) - ctz (CST1)
(CST1 << A) != CST2 -> A != ctz (CST2) - ctz (CST1)
--- /dev/null
+int a, b, c, d, e, f, g;
+int h(int i) { return b >= 2 ?: i >> b; }
+void j() {
+ int k;
+ int *l = &c;
+ for (; d; d++) {
+ g = h(0 != j);
+ f = g >> a;
+ k = f << 7;
+ e = k > 5 ? k : 0;
+ *l ^= e;
+ }
+}