Spencer Abson <spencer.ab...@arm.com> writes: > On Fri, Jun 06, 2025 at 04:04:18PM +0100, Richard Sandiford wrote: >> Spencer Abson <spencer.ab...@arm.com> writes: >> > Extend the ternary op/UNSPEC_SEL combiner patterns from SVE_FULL_F/ >> > SVE_FULL_F_BF to SVE_F/SVE_F_BF, where the strictness value is >> > SVE_RELAXED_GP. >> > >> > We can only reliably test the 'merging with the third input' (addend) >> > and 'independent value' patterns at this stage as the canocalisation that >> > reorders the multiplicands based on the second SEL input would be performed >> > by the conditional expander. >> > >> > Another difficulty is that we can't test these fused multiply/SEL combines >> > without using __builtin_fma and friends. The reason for this is as >> > follows: >> > >> > We support COND_ADD, COND_SUB, and COND_MUL optabs, so match.pd will >> > canonicalize patterns like ADD/SUB/MUL combined with a VEC_COND_EXPR into >> > these conditional forms. Later, when widening_mul tries to fold these into >> > conditional fused multiply operations, the transformation fails - simply >> > because we haven’t implemented those conditional fused multiply optabs yet. >> > >> > Hence why this patch lacks tests for BFloat16... >> > >> > gcc/ChangeLog: >> > >> > * config/aarch64/aarch64-sve.md (*cond_<optab><mode>_2_relaxed): >> > Extend from SVE_FULL_F to SVE_F. >> > (*cond_<optab><mode>_4_relaxed): Extend from SVE_FULL_F_B16B16 >> > to SVE_F_B16B16. >> > (*cond_<optab><mode>_any_relaxed): Likewise. >> > >> > gcc/testsuite/ChangeLog: >> > >> > * gcc.target/aarch64/sve/unpacked_cond_fmla_1.c: New test. >> > * gcc.target/aarch64/sve/unpacked_cond_fmls_1.c: Likewise. >> > * gcc.target/aarch64/sve/unpacked_cond_fnmla_1.c: Likewise. >> > * gcc.target/aarch64/sve/unpacked_cond_fnmls_1.c: Likewise. >> >> OK, thanks. >> >> BTW, I just realised that all my comments saying "please add a token >> test that SEL doesn't get dropped" are probably completely bogus, >> since those cases will instead be handed by the follow-on patches >> to the conditional optabs. Is that right? Please ignore if so. :) > > Yeah, that's true where we have a conditional optab, but that isn't > the case for any of the interesting unary operations. > > Maybe I should include '_2.c' style tests for each of those, that > explicitly test for SEL?
Sounds good, but like I say, it doesn't need to be each of them :) (unless you want to, of course) Thanks, Richard
