Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

[Segher Boessenkool <segher@kernel.crashing.org>]

On Fri, May 29, 2020 at 06:05:14PM +0100, Richard Sandiford wrote:
> Segher Boessenkool <segher@kernel.crashing.org> writes:
> > On Fri, May 29, 2020 at 02:43:12PM +0200, Richard Biener wrote:
> >> Segher - do you actually know this code to guess why the patterns are defensive?
> >
> > Yes.
> 
> In that case, can you give a specific example in which the patterns do
> actually fail?

That is a very different question.  (And this is shifting the burden of
proof again.)

> I think Richard's point is that even the current compiler will ICE if
> the vcond* patterns fail.  All Martin's patch did was expose that via
> the extra static checking we get for directly-mapped internal fns.

How will they ICE?

> If you want us to fix that by providing a fallback, we need to know what
> the fallback should do.

Just whatever vcond* is documented to do, of course ;-)

> E.g. the obvious thing would be to emit the
> embedded comparison separately and then emit bitwise operations to
> implement the select.  But in the powerpc case, it's actually the
> comparison that's the potential problem, so that expansion would just
> kick the can further down the road.
> 
> So which vector comparisons doesn't powerpc support, and what should the
> fallback vcond* expansion for them be?

It depends on which set of vector registers is in use, and on the ISA
version as well, what the hardware can do.  What the backend can do --
well, it is allowed to FAIL these patterns, and it sometimes does.
That's the whole point isn't it?

vec_cmp* won't FAIL.  I don't know if there is a portable variant of
this?


Segher