[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