https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97085
--- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Richard Biener from comment #5) > (In reply to Marc Glisse from comment #4) > > 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. > > Not sure what the ARM backend issue is. PR 96528 > Well, VEC_COND_EXPR (as some other VEC_ tree codes) are special in that > we are (try to...) be careful to only synthesize ones supported "directly" > by the target. After vector lowering, yes. But before that, the front-end can produce vec_cond_expr for vector types that are not supported. Ah, you probably meant synthesize them from optimization passes, ok. > For the mask vectors (VECTOR_BOOLEAN_TYPE_P, in the > AVX512/SVE case) I don't think the targets support ?: natively but they > have bitwise instructions for this case. That means we could 'simply' > expand mask x ? y : z as (y & x) | (z & ~x) I guess [requires x and y,z > to be of the same type of course]. I wondered whether we ever > need to translate between, say, vector<bool:1> and vector<bool:2> > where lowering ?: this way would require '[un]packing' one of the vectors. I still need to go back to the introduction of those types to understand why vector<bool:2> exists at all... > True, unless you go to bitwise ops. For scalar flag ? bool_a : bool_b > ?: isn't the natural representation either - at least I'm not aware > of any pattern transforming (a & b) | (c & ~b) to b ? a : c for > precision one integer types ;) There are PRs asking for this transformation (and for transformations that this one would enable).
