Re: [PATCH] match.pd: turn a product of two quotients into one division
Jakub Jelinek <[email protected]> Tue, 4 Aug 2026 12:03:45 +0200
| Newsgroups | gmane.comp.gcc.patches |
|---|---|
| Message-ID | <anG5AReHFbNhTkBe@tucnak> |
On Tue, Aug 04, 2026 at 11:40:28AM +0200, [email protected] wrote: > --- a/gcc/match.pd > +++ b/gcc/match.pd > @@ -819,6 +819,33 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > || !HONOR_SIGNED_ZEROS (type))) > (rdiv @0 (mult @1 @2)))) > > + /* Convert (A/B) * (C/D) to (A*C) / (B*D). Two divisions become one > + multiply and one division, and a division costs several multiplies on > + every target. > + > + The two products are new places for the exponent to leave the range, so > + the rule needs more than the rounding licence: with B and D both large > + B * D is an infinity and the quotient becomes inf / inf, and with both > + small it is a zero and the quotient becomes 0 / 0. Either way a finite > + result turns into a NaN, so the rule is restricted to the case where > + infinities and NaNs are excluded, as the cancellation rules above are. > + > + Both quotients have to be dead outside the product, otherwise a division > + would be added rather than removed, and a shared reciprocal is better > + left alone for the multiplications to reuse. That is a hard requirement > + rather than a :s marker, because :s only forbids emitting new statements > + and both products can fold away to nothing, as they do for X * X where X > + is one reciprocal square root. Requiring two singly used quotients also > + excludes that case, since a value feeding both operands of the product > + has two uses. */ > + (simplify > + (mult (rdiv@4 @0 @1) (rdiv@5 @2 @3)) > + (if (!HONOR_NANS (type) && !HONOR_INFINITIES (type) > + && (TREE_CODE (type) != COMPLEX_TYPE > + || !HONOR_SIGNED_ZEROS (type)) > + && single_use (@4) && single_use (@5)) > + (rdiv (mult @0 @2) (mult @1 @3)))) Shouldn't this depend also on flag_unsafe_math_optimizations? I mean, even if infinities, NaNs and signed zeros aren't involved, the optimization changes the results due to different rounding, doesn't it? Jakub