https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105312
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.
_37 = vect_vec_iv_.13_32 == { 0, 0, 0, 0 };
vect_iftmp.14_38 = VEC_COND_EXPR <_37, { 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0 }, {
0.0, 0.0, 0.0, 0.0 }>;
(gdb) p debug_tree (op0)
<ssa_name 0x7ffff642d708
type <vector_type 0x7ffff6431888
type <boolean_type 0x7ffff64317e0 public SI
size <integer_cst 0x7ffff6528018 constant 32>
unit-size <integer_cst 0x7ffff6528030 constant 4>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff64317e0 precision:32 min <integer_cst 0x7ffff64326a8 -2147483648> max
<integer_cst 0x7ffff6432738 2147483647>>
V4SI
size <integer_cst 0x7ffff6528378 constant 128>
unit-size <integer_cst 0x7ffff6528390 constant 16>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff6431888 nunits:4>
visited
def_stmt _37 = vect_vec_iv_.13_32 == { 0, 0, 0, 0 };
version:37>
we can't do VCONDEQ, we _can_ compute op0 but do not have vcond_mask which
we assume here. So this is a mismatch between ISEL and vector lowering
or alternatively a failure to - for non-mask vectors - provide a fallback
via masking.
For vcond_mask I see there is v2sfv2si but no v4sfv4si, so not sure whether
this can be tackled on the backend side.
Note for a masking fallback we'd have to ensure support for integer mode
bitwise ops as well as view-converting V4SF to and from V4SI. There is
/* Lower mask typed, non-vector mode VEC_COND_EXPRs to bitwise operations.
Those can end up generated by folding and at least for integer mode masks
we cannot expect vcond expanders to exist. We lower a ? b : c
to (b & a) | (c & ~a). */
if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (lhs))
&& !VECTOR_MODE_P (mode))
{
gcc_assert (types_compatible_p (TREE_TYPE (op0), TREE_TYPE (op1)));
gimple_seq stmts = NULL;
tree type = TREE_TYPE (lhs);
location_t loc = gimple_location (stmt);
tree tem0 = gimple_build (&stmts, loc, BIT_AND_EXPR, type, op1, op0);
tree tem1 = gimple_build (&stmts, loc, BIT_NOT_EXPR, type, op0);
tree tem2 = gimple_build (&stmts, loc, BIT_AND_EXPR, type, op2, tem1);
tree tem3 = gimple_build (&stmts, loc, BIT_IOR_EXPR, type, tem0, tem2);
gsi_insert_seq_before (gsi, stmts, GSI_SAME_STMT);
return gimple_build_assign (lhs, tem3);
}
but as said the immediate failure is that veclower thinks we can handle
_37 = vect_vec_iv_.13_32 == { 0, 0, 0, 0 };
vect_iftmp.14_38 = VEC_COND_EXPR <_37, { 1.0e+0, 1.0e+0, 1.0e+0, 1.0e+0 }, {
0.0, 0.0, 0.0, 0.0 }>;
but ISEL thinks we cannot. I will look into that.
