On Thu, May 28, 2020 at 5:28 PM Richard Sandiford <richard.sandif...@arm.com> wrote: > > Martin Liška <mli...@suse.cz> writes: > > Hi. > > > > There's a new patch that adds normal internal functions for the 4 > > VCOND* functions. > > > > The patch that survives bootstrap and regression > > tests on x86_64-linux-gnu and ppc64le-linux-gnu. > > I think this has the same problem as the previous one. What I meant > in yesterday's message is that: > > expand_insn (icode, 6, ops); > > is simply not valid when icode is allowed to FAIL. That's true in > any context, not just internal functions. If icode does FAIL, > the expand_insn call will ICE: > > if (!maybe_expand_insn (icode, nops, ops)) > gcc_unreachable (); > > When using optabs you either: > > (a) declare that the md patterns aren't allowed to FAIL. expand_insn > is for this case. > > (b) allow the md patterns to FAIL and provide a fallback when they do. > maybe_expand_insn is for this case. > > So if we keep IFN_VCOND, we need to use maybe_expand_insn and find some > way of implementing the IFN_VCOND when the pattern FAILs.
But we should not have generated the pattern in that case - we actually verify we can expand at the time we do this "instruction selection". This is in-line with other vectorizations where we also do not expect things to FAIL. See also the expanders that are removed in the patch. But adding a comment in the internal function expander to reflect this is probably good, also pointing to the verification routines (the preexisting expand_vec_cond_expr_p and expand_vec_cmp_expr_p routines). Because of this pre-verification I suggested the direct internal function first, not being aware of the static cannot-FAIL logic. 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? Thanks, Richard. > Thanks, > Richard
