[Bug tree-optimization/105312] [12 Regression] ICE in gimple_expand_vec_cond_expr on arm-linux since r12-834-ga6eacbf1055520

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.