Re: [stage1][PATCH] Lower VEC_COND_EXPR into internal functions.

[Richard Sandiford <richard.sandiford@arm.com>]

Martin Liška <mliska@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.

Thanks,
Richard