On Fri, May 29, 2020 at 05:57:13PM +0100, Richard Sandiford wrote:
> 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.)
Most patterns *do* FAIL on some target. We cannot rewind time.
Segher
