Bernd Schmidt <bschm...@redhat.com> writes:
> On 12/03/2015 02:06 PM, Richard Sandiford wrote:
>> As Bernd requested, this patch adds "This pattern cannot FAIL" to the
>> documentation of optabs that came to be mapped to interal functions.
>> For consistency I did the same for optabs that were already being
>> used for internal functions.
>>
>> Many of the optabs weren't documented in the first place, so I added
>> entries for the missing ones. Also, there were some inaccuracies in
>> the documentation of the rounding optabs. The bitcount optabs said
>> that operand 0 has mode @var{m} and that operand 1 is under target
>> control, whereas it should be the other way around.
>
> That actually goes beyond what I imagined. I was looking at the top part
> of md.texi (line 87), where there is a brief discussion of what is
> allowed to FAIL and what isn't. Also, there is "@item FAIL":
>
> "Failure is currently supported only for binary (addition,
> multiplication, shifting, etc.) and bit-field (@code{extv},
> @code{extzv}, and @code{insv}) operations."
>
> That's pretty outdated. I think unary operations are probably missing by
> accident, and from what my grep showed there are also conditional moves,
> atomic operations, certain vec_ patterns that can all fail. As a minimum
> this paragraph should also mention internal functions.
I don't think that quote means that FAIL is supported for _all_ optabs
with two inputs and one output. What "etc." includes is left vague.
A blanket statement about internal functions is likely to get out of
date, since there's no reason in principle why optabs used for future
internal functions couldn't have fallbacks. Also, "internal-function
optabs" aren't self-describing: no-one's going to know what an internal
function optab is without looking at the source.
I'd rather keep it as the patch has it and say for each relevant optab
that the expander can't fail.
Richard
