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