> On 7 Aug 2026, at 17:48, Jeffrey Law <[email protected]> wrote: > > > > On 8/4/2026 7:51 AM, [email protected] wrote: >> From: Kyrylo Tkachov <[email protected]> >> >> v2: Add flag_associative_math on top of flag_reciprocal_math as >> condition >> >> (A / B) * (C / D) is (A * C) / (B * D), which replaces one of the two >> divisions with a multiply. The operation count is unchanged and a division >> costs several multiplies on every target. >> >> double f (double a, double b, double c) >> { return (a / b) * (1.0 / c); } >> >> aarch64 -Ofast before: >> >> fdiv d0, d0, d1 >> fdiv d0, d0, d2 >> >> after: >> >> fmul d1, d1, d2 >> fdiv d0, d0, d1 >> >> The reciprocal spelling is what appears in source that has been hand-tuned >> for -freciprocal-math: the reciprocal is folded into a quotient by the >> existing rules, but the resulting division of a division was never revisited >> because the multiply had already consumed it. The existing (A/B)/C rule >> therefore only caught the case where the second division was written out. >> >> The rule also needs infinities and NaNs excluded. It forms two products, >> and each is a new place for the exponent to leave the range: with both >> divisors large B * D is an infinity and the quotient becomes inf / inf, with >> both small it is a zero and the quotient becomes 0 / 0, and either turns a >> finite result into a NaN. The cancellation rules in the same block carry >> the same test for the same reason. >> >> Complex values also require signed zeros to be ignored, >> because reassociation can change the sign of an imaginary zero. >> >> Bootstrapped and tested on aarch64-none-linux-gnu. >> Ok for trunk? >> Thanks, >> Kyrill >> >> gcc/ChangeLog: >> >> * match.pd ((A / B) * (C / D)): New simplification. >> >> gcc/testsuite/ChangeLog: >> >> * gcc.dg/tree-ssa/recip-mult-div-1.c: New test. >> * gcc.dg/tree-ssa/recip-mult-div-2.c: New test. >> >> Signed-off-by: Kyrylo Tkachov <[email protected]> > I don't guess you've done something like test spec2017 or spec2026 with this? > One of the guidelines we've had for the -ffast-math family is they don't > break specfp. So it would be best to verify spec is still OK with > -ffast-math (or the narrower set to allow reassociation and turn off -0.0 > support) > > Assuming that test is OK, then this is fine for the trunk. Sorry to add the > additional testing request, but I've been bitten by these kinds of things too > many times.
When I was writing the patch I tested it on SPEC2026. In fact it was motivated by it as it triggers ~600 times (though not in hot paths). It works fine there. Since you brought it up, I just tried SPEC2017 fprate -Ofast and it didn’t cause any problems there either. I’ll push it when I get the chance. Thanks, Kyrill > > Jeff
