[Bug tree-optimization/97085] [11 Regression] aarch64, SVE: ICE in gimple_expand_vec_cond_expr since r11-2610-ga1ee6d507b
glisse at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Wed Sep 23 15:13:57 GMT 2020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97085
--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
I would be happy with a revert of that patch, if the ARM backend gets fixed,
but indeed a missed optimization should not cause an ICE.
(In reply to Richard Biener from comment #2)
> At least we're not at all expecting to have a VEC_COND_EXPR where
> the comparison feeding the mask has different operand modes than the
> VEC_COND_EXPR result mode.
Ah, I see why that might cause trouble, although I think supporting this makes
sense, when the modes have the same size or when we use AVX512-style bool
vectors.
> We'd also want to add verification if we do not want
> VECTOR_BOOLEAN_TYPE_P VEC_COND_EXPR.
I understand that a VEC_COND_EXPR which outputs a vector of bool (à la AVX512)
is a different thing from a VEC_COND_EXPR which outputs a "true" vector, but
VEC_COND_EXPR still looks like the right tree code to represent both.
(In reply to Richard Biener from comment #3)
> +/* Canonicalize mask ? { 0, ... } : { -1, ...} to ~mask if the mask
> + types are compatible. */
> +(simplify
> + (vec_cond @0 VECTOR_CST@1 VECTOR_CST@2)
> + (if (VECTOR_BOOLEAN_TYPE_P (type)
> + && types_match (type, TREE_TYPE (@0)))
> + (if (integer_zerop (@1) && integer_all_onesp (@2))
> + (bit_not @0)
> + (if (integer_all_onesp (@1) && integer_zerop (@2))
> + @0))))
Is the test VECTOR_BOOLEAN_TYPE_P necessary?
(sorry, I may not be very reactive these days)
More information about the Gcc-bugs
mailing list