[Bug tree-optimization/106063] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106063 Andrew Macleod changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #1 from Andrew Macleod --- That option enables legacy EVRP, and will be going away soon. however, looking at the IL, the difference out of EVRP is that legacy doesnt touch the code. The IL is: vector(1) __int128 _1; vector(1) _2; V _4; : _1 = v_3(D) & { 15 }; _2 = v_3(D) == _1; _4 = VEC_COND_EXPR <_2, { -1 }, { 0 }>; return _4; Ranger ends up triggering a simplification : Folding statement: _2 = v_3(D) == _1; gimple_simplified to _6 = v_3(D) & { -16 }; _2 = _6 == { 0 }; Folded into: _2 = _6 == { 0 }; producing: _1 = v_3(D) & { 15 }; _6 = v_3(D) & { -16 }; _2 = _6 == { 0 }; _4 = VEC_COND_EXPR <_2, { -1 }, { 0 }>; return _4; Which ends up not causing the ICE seen in this PR. However, if we completely disable EVRP, we also get the trap. -O2 -fno-tree-forwprop --disable-tree-evrp So it would seem the problem probably lies with vector expansion?
[Bug tree-optimization/106063] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106063 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||tnfchris at gcc dot gnu.org Last reconfirmed||2022-06-24 --- Comment #2 from Richard Biener --- Interestingly typedef __int128 __attribute__((__vector_size__ (16))) V; typedef unsigned __int128 __attribute__((__vector_size__ (16))) uV; typedef V bV __attribute__((vector_mask)); V __GIMPLE (ssa,startwith("isel")) foo (V v) { uV _1; bV _2; V _4; __BB(2,guessed_local(1073741824)): _1 = __VIEW_CONVERT (v_3(D)); _2 = _1 <= _Literal (uV) { _Literal (unsigned __int128) 15 }; _4 = _2 ? _Literal (V) { _Literal (__int128) -1 } : _Literal (V) { 0 }; return _4; } works, even with -fdisable-tree-veclower21 The issue is that we cannot expand the unsigned comparsion _2 = _1 <= { 15 }; which is introduced in VRP2 from the equality compare: --- t2.c.197t.threadfull2 2022-06-24 12:25:08.204648605 +0200 +++ t2.c.198t.vrp2 2022-06-24 12:25:08.204648605 +0200 @@ -10,13 +10,15 @@ ;; 2 succs { 1 } V foo (V v) { + vector(1) uint128_t _1; vector(1) _2; V _4; vector(1) __int128 _6; [local count: 1073741824]: _6 = v_3(D) & { -16 }; - _2 = _6 == { 0 }; + _1 = VIEW_CONVERT_EXPR(v_3(D)); + _2 = _1 <= { 15 }; _4 = VEC_COND_EXPR <_2, { -1 }, { 0 }>; return _4; but after vector lowering only vector operations that are handled by the target may be introduced. The pattern /* Transform comparisons of the form (X & Y) CMP 0 to X CMP2 Z where ~Y + 1 == pow2 and Z = ~Y. */ (for cst (VECTOR_CST INTEGER_CST) (for cmp (eq ne) icmp (le gt) (simplify (cmp (bit_and:c@2 @0 cst@1) integer_zerop) (with { tree csts = bitmask_inv_cst_vector_p (@1); } (if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2))) (if (TYPE_UNSIGNED (TREE_TYPE (@1))) (icmp @0 { csts; }) (with { tree utype = unsigned_type_for (TREE_TYPE (@1)); } (icmp (view_convert:utype @0) { csts; } fails to check that in the vector case. Caused by r12-5650-g29df53fe349073 (thus latent on the branch).