on 2024/6/17 14:16, Richard Biener wrote: > On Mon, 17 Jun 2024, Kewen.Lin wrote: > >> Hi Richi, >> >> on 2024/6/14 18:31, Richard Biener wrote: >>> 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. >> >> Thanks for making this change, this patch can be bootstrapped on ppc64{,le} >> but both have one failure on gcc/testsuite/gcc.target/powerpc/pr66144-3.c, >> by looking into it, I found it just exposed one oversight in the current >> rs6000 vcond_mask support (the condition mask location is wrong), so I think >> this change is fine for rs6000 port, I'll also test SPEC2017 for this (with >> rs6000 vcond_mask change) soon. > > Btw, for those targets where the patch works out fine it would be nice > to delete their vcond{,u,eq} expanders (and double-check that doesn't > cause issues on its own).
OK, will do, thanks for reminding! > > Can target maintainers note whether their targets support all condition > codes for their vector comparisons (including FP variants)? And On Power, hardware only supports EQ and GT for vector INT (well ISA 3.0 supports NE for b/h/w), while EQ, GT & GE for vector FP. But vec_cmp optab supports {EQ,NE,LT,LE,GT,GE} for signed, {EQ,NE,LTU,LEU,GTU,GEU} for unsigned, and {EQ,NE,LT,LE,GT,GE,UNORDERED,ORDERED,UNEQ,LTGT,UNGE,UNGT,UNLT,UNLE} for fp. > whether they choose to implement all condition codes in vec_cmp > and adjust with inversion / operand swapping for not supported cases? Yes for rs6000 port, some relies on define_insn_and_split. BR, Kewen