[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).
