https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79734
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |kyukhin at gcc dot gnu.org,
| |uros at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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?
