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

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

On Fri, May 29, 2020 at 02:17:00PM +0200, Richard Biener wrote:
> Now it looks like that those verification also simply checks optab
> availability only but then this is just a preexisting issue (and we can
> possibly build a testcase that FAILs RTL expansion for power...).
> 
> So given that this means the latent bug in the powerpc backend
> should be fixed and we should use a direct internal function instead?

I don't see what you consider a bug in the backend here?  The expansion
FAILs, and it is explicitly allowed to do that.

Not allowed to FAIL are:
-- The "lanes" things;
-- vec_duplicate, vec_series;
-- maskload, maskstore;
-- fmin, fmax;
-- madd and friends;
-- sqrt, rsqrt;
-- fmod, remainder;
-- scalb, ldexp;
-- sin, cos, tan, asin, acos, atan;
-- exp, expm1, exp10, exp2, log, log1p, log10, log2, logb;
-- significand, pow, atan2, floor, btrunc, round, ceil, nearbyint, rint;
-- copysign, xorsign;
-- ffs, clrsb, clz, ctz, popcount, parity.

All vcond* patterns are allowed to fail.

Maybe ours don't *need* to, but that doesn't change a thing.

In general, it is a Very Good Thing if patterns are allowed to fail: if
they are not allowed to fail, they have to duplicate all the code that
the generic expander should have, into ever target that needs it.  It
also makes writing a (new) backend easier.


Segher