Am 10.06.26 um 07:31 schrieb [email protected]:
From: MITSUNARI Shigeo <[email protected]>
On <Tue, 9 Jun 2026 10:55:53 +0200>, Georg-Johann Lay wrote:
What happens on other target? For example, when 32-bit division is
preferred over 64-bit multiplication?
I will add a guard in v5:
if (GET_MODE_BITSIZE (wide_mode) <= BITS_PER_WORD)
{
/* ... optimization ... */
}
where wide_mode = GET_MODE_WIDER_MODE (int_mode) = DImode.
I am not sure if that's the right mode:
In the rare case where there's a mode between SImode and DImode,
you would get the first in-between mode, not DImode.
Perhaps consider GET_MODE_2XWIDER_MODE (int_mode) instead?
Johann
This ensures the optimization is only attempted when the 64-bit widened
mode fits in a single native register (BITS_PER_WORD >= 64).
The three cases are:
- 64-bit targets with a native highpart multiply (x86_64, AArch64, RISC-V64):
condition is true; optimization is applied.
- 32-bit targets (BITS_PER_WORD = 32, e.g. targets where 64-bit operations
require register pairs):
condition is false; falls back to the traditional sub/shift/add sequence.
- 64-bit targets without a native 64x64->128-bit highpart multiply:
condition is true, but expmed_mult_highpart returns NULL_RTX because no
suitable optab is found (expmed_mult_highpart always takes the optab-only
path when the doubly-widened mode exceeds BITS_PER_WORD, which is the
case here since TImode > 64 bits). The code then falls back to the
traditional sequence.
I will post v5 with this fix.
