On Fri, 14 Jun 2024, Richard Sandiford wrote:
> Richard Biener <rguent...@suse.de> writes:
> > On Fri, 14 Jun 2024, Richard Sandiford wrote:
> >
> >> Richard Biener <rguent...@suse.de> writes:
> >> > The following retires vcond{,u,eq} optabs by stopping to use them
> >> > from the middle-end. Targets instead (should) implement vcond_mask
> >> > and vec_cmp{,u,eq} optabs. The PR this change refers to lists
> >> > possibly affected targets - those implementing these patterns,
> >> > and in particular it lists mips, sparc and ia64 as targets that
> >> > most definitely will regress while others might simply remove
> >> > their vcond{,u,eq} patterns.
> >> >
> >> > I'd appreciate testing, I do not expect fallout for x86 or arm/aarch64.
> >> > I know riscv doesn't implement any of the legacy optabs. But less
> >> > maintained vector targets might need adjustments.
> >> >
> >> > I want to get rid of those optabs for GCC 15. If I don't hear from
> >> > you I will assume your target is fine.
> >>
> >> Great! Thanks for doing this.
> >>
> >> Is there a plan for how we should handle vector comparisons that
> >> have to be done as the inverse of the negated condition? Should
> >> targets simply not provide vec_cmp for such conditions and leave
> >> the target-independent code to deal with the fallout? (For a
> >> standalone comparison, it would invert the result. For a VEC_COND_EXPR
> >> it would swap the true and false values.)
> >
> > I would expect that the ISEL pass which currently deals with finding
> > valid combos of .VCMP{,U,EQ} and .VCOND_MASK deals with this.
> > So how do we deal with this right now? I expect RTL expansion will
> > do the inverse trick, no?
>
> I think in practice (at least for the targets I've worked on),
> the target's vec_cmp handles the inversion itself. Thus the
> main optimisation done by targets' vcond patterns is to avoid
> the inversion (and instead swap the true/false values) when the
> "opposite" comparison is the native one.
I see. I suppose whether or not vec_cmp is handled is determined
by a FAIL so it's somewhat difficult to determine this at ISEL time.
Meanwhile I've opened PR115490 with the x86 fallout from applying the
patch.
Richard.
