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.
Thanks,
Richard
