https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79734
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #3)
> I think the problem is that generic vector lowering isn't prepared to handle
> _4 = VEC_COND_EXPR <_3 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 }, { 0, 0, 0, 0 },
> { -1, -1, -1, -1 }>;
> where _3 is V4SFmode vector and _4, { 0, 0, 0, 0 } and { -1, -1, -1, -1 } are
> QImode (i.e. the AVX512-ish boolean vectors). The vectorizer would try to
> do something like _5 = _3 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
> _4 = ~_5;
> in this case I believe.
> So, either we shouldn't create these at all (but they come from the FEs
> already), or expand_vec_cond_expr_p/expand_vec_cond_expr should also handle
> the cases where value_type is VECTOR_BOOLEAN_TYPE_P but cmp_op_type is not
> (use a new optab for it, or expand directly) and value_mode is MODE_INT?
> If one or both of rhs2 and rhs3 are constant, then it can be expanded into
> performing the comparison first and on the VECTOR_BOOLEAN_TYPE with MODE_INT
> result do bitwise ops, (cmp_result & rhs2) | ((~cmp_result) & rhs3) with
> simplifications if rhs2 and/or rhs3 is a constant true or false vector.
>
> So, shall we handle this in the FEs, or transform it in vector lowering to
> the bitwise stuff, something different?
I'd be fine with handling this in vector lowering.
