On May 27, 2020 6:13:24 PM GMT+02:00, Richard Sandiford
<richard.sandif...@arm.com> wrote:
>Martin Liška <mli...@suse.cz> writes:
>> On 5/26/20 12:15 PM, Richard Sandiford wrote:
>>> So longer-term, I think we should replace VCOND(U) with individual
>ifns,
>>> like for VCONDEQ. We could reduce the number of optabs needed by
>>> canonicalising greater-based tests to lesser-based tests.
>>
>> Hello.
>>
>> Thanks for the feedback. So would it be possible to go with something
>> like DEF_INTERNAL_OPTAB_CAN_FAIL (see the attachment)?
>
>It doesn't look like this will solve the problem. The reason that we
>don't allow optabs for directly-mapped IFNs to FAIL is that:
>
> expand_insn (icode, 6, ops);
>
>will (deliberately) ICE when the pattern FAILs. Code that copes with
>FAILing optabs instead needs to do:
>
>rtx_insn *watermark = get_last_insn (); <-- position whether it should
>go.
> ...
> if (maybe_expand_insn (icode, 6, ops))
> {
> ...Success...;
> }
>
> delete_insns_since (watermark);
> ...fallback code that implements the IFN without optab support...
>
>At this point the IFN isn't really directly-mapped in the intended
>sense:
>the optab is “just” a way of optimising the IFN.
>
>So I think the effect of the patch will be to suppress the build
>failure,
>but instead ICE for PowerPC when the FAIL condition is hit. It might
>be quite difficult to trigger though. (That's why the static checking
>is there. :-))
>
>I think instead we should treat VCOND(U) as not directly-mapped,
>as Richard suggested (IIRC). The internal-fn.c code should then handle
>the case in which we have an IFN_VCOND(U) call and the associated
>optab fails. Of course, this is only going to be exercised on targets
>like powerpc* that having failing patterns, so it'll need testing
>there.
>
>What I meant by the quote above is that I think this shows the flaw in
>using IFN_VCOND(U) rather than splitting it up further. Longer term,
>we should have a separate IFN_VCOND* and optab for each necessary
>condition. There would then be no need (IMO) to allow the patterns
>to FAIL, and we could use directly-mapped IFNs with no fallback.
>There'd also be no need for the tree comparison operand to the IFN.
That might be indeed a good idea.
Richard.
>Thanks,
>Richard
