[Bug tree-optimization/97085] [11 Regression] aarch64, SVE: ICE in gimple_expand_vec_cond_expr since r11-2610-ga1ee6d507b

[rguenth at gcc dot gnu.org]

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 ;)