https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97085
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Marc Glisse from comment #6) > (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. Yeah. I'm also not sure whether the user can synthesize VEC_COND_EXPR for say AVX512 vector masks - you cannot even declare those "vector types", instead the intrinsic header uses typedef unsigned char __mmask8; typedef unsigned short __mmask16; maybe for SVE this is different, but the SVE header is "hidden" ;) /* NOTE: This implementation of arm_sve.h is intentionally short. It does not define the SVE types and intrinsic functions directly in C and C++ code, but instead uses the following pragma to tell GCC to insert the necessary type and function definitions itself. The net effect is the same, and the file is a complete implementation of arm_sve.h. */ #pragma GCC aarch64 "arm_sve.h" > > 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). heh ;)
