Segher Boessenkool <seg...@kernel.crashing.org> writes:
> 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.
Well, the docs say:
… For **certain** named patterns, it may invoke @code{FAIL} to tell the
compiler to use an alternate way of performing that task. …
(my emphasis). Later on they say:
@findex FAIL
@item FAIL
…
Failure is currently supported only for binary (addition, multiplication,
shifting, etc.) and bit-field (@code{extv}, @code{extzv}, and @code{insv})
operations.
which explicitly says that vcond* isn't allowed to fail.
OK, so that list looks out of date. But still. :-)
We now explicitly say that some patterns aren't allowed to FAIL,
which I guess gives the (implicit) impression that all the others can.
But that wasn't the intention. The lines were just added for emphasis.
(AFAIK 7f9844caf1ebd513 was the first patch to do this.)
Richard
