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)