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
