Re: [PATCH][v2] match.pd: turn a product of two quotients into one division

> 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