[Bug tree-optimization/97228] [11 regression] New ICEs on arm since r11-3426 g:10843f8303509fcba880c6c05c08e4b4ccd24f36

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97228

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
So for

FAIL: gcc.dg/tree-ssa/ifc-cd.c (internal compiler error)

I see before ISEL changes like

@@ -180,16 +180,12 @@
   vect_b1_24.24_112 = vect_a1_16.12_97 + { 1, 1, 1, 1 };
   vect_b1_25.25_114 = vect_a1_16.12_97 + { 2, 2, 2, 2 };
   _118 = vect_a2_18.15_100 > { 0, 0, 0, 0 };
-  vect_patt_35.26_119 = VEC_COND_EXPR <_118, { 1, 1, 1, 1 }, { 0, 0, 0, 0 }>;
   _122 = vect__8.23_110 == { 0, 0, 0, 0 };
-  vect_patt_26.27_123 = VEC_COND_EXPR <_122, vect_patt_35.26_119, { 0, 0, 0, 0
}>;
-  _125 = vect_patt_26.27_123 != { 0, 0, 0, 0 };
+  _125 = VEC_COND_EXPR <_122, _118, { 0, 0, 0, 0 }>;
   vect_patt_44.28_126 = VEC_COND_EXPR <_125, vect_b1_25.25_114,
vect_b1_24.24_112>;
   vect_patt_37.31_138 = VEC_COND_EXPR <_125, vect_b1_24.24_112,
vect_a1_16.12_97>;
-  vect_patt_36.32_143 = VEC_COND_EXPR <_122, { 1, 1, 1, 1 }, { 0, 0, 0, 0 }>;
   _146 = vect_a3_20.18_103 < { 0, 0, 0, 0 };
-  vect_patt_72.33_147 = VEC_COND_EXPR <_146, vect_patt_36.32_143, { 0, 0, 0, 0
}>;
-  _149 = vect_patt_72.33_147 != { 0, 0, 0, 0 };
+  _149 = VEC_COND_EXPR <_146, _122, { 0, 0, 0, 0 }>;
   vect_patt_12.34_150 = VEC_COND_EXPR <_149, vect_patt_37.31_138,
vect_patt_44.28_126>;
   vect__ifc__73.35_154 = VEC_COND_EXPR <_122, vect_patt_12.34_150, { 0, 0, 0,
0 }>;
   MEM <vector(4) int> [(int *)vectp_y.19_105] = vect__ifc__73.35_154;

where the difference is that we end up with a used vector comparison
that is not supported by the target (see also the other PR which Richard
has kindly taken).

Now, folding produces

   _118 = vect_a2_18.15_100 > { 0, 0, 0, 0 };
   _122 = vect__8.23_110 == { 0, 0, 0, 0 };
   _125 = VEC_COND_EXPR <_122, _118, { 0, 0, 0, 0 }>;

that's still not fully simplified, if written as bitwise ops it could be
as simple as

   _125 = _122 & _118;

but then this will probably make the issue worse ;)

I think this is a duplicate of that other bug.