https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96528
--- Comment #2 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> I think that eventually vector lowering should lower
>
> _1 = a == 5;
> _2 = b == 7;
> _3 = _1 | _2;
> _4 = _3 ? -1 : 0;
>
> to
>
> _31 = _1 ? -1 : 0;
> _32 = _2 ? -1 : 0;
> _33 = _31 | _32;
> _34 = _33 == -1;
_34 = _33 < 0; // for consistency with what we do elsewhere? But I think isel
already handles that.
> _4 = _34 ? -1 : 0;
>
> or so.
... on platforms like ARM. On AVX512, we clearly want to keep the bool vectors.
> Conditionals are really a mess, GIMPLE and optabs do not match 1:1
> (we've rejected the idea of "splitting" VEC_COND_EXPR to
> VEC_COND_{EQ,NE,...}_EXPR and making it four-operand). Forcing
> vector compares to produce a bool vector result was the attempt to make
> the GIMPLE IL more streamlined, but obviously the above shows that code
> generation needs to be "fixed" - in this case it is vector lowering doing
> "code generation" (together with the later isel pass).
I wonder if doing it during isel (and updating the predicates so they advertise
a==b as supported for vector lowering when a==b?-1:0 is) would be sufficient.
It requires considering that a bool vector and an integer vector of the same
shape are essentially the same thing on platforms that do not have true bool
vectors. This way we would only need to rewrite
_1 = a == 5;
to
_1 = a == 5 ? true : false;
