For the following code: int mul(int x, int y) { return x * y * y * y * y; } with -O2 GCC produces the frollowing assembly: mul(int, int): mov eax, edi imul eax, esi imul eax, esi imul eax, esi imul eax, esi ret However, a more optimal code could be generated with less multiplications: mul(int, int): mov eax, edi imul esi, esi imul eax, esi imul eax, esi ret Godbolt playground: https://godbolt.org/z/6dP11jPfx
The above godbolt link for an old version of GCC, here's for 14.0 https://godbolt.org/z/dTPYY1T9W
We don't do as much reassociation as we should with signed integers due to overflow. If you use -fwrapv, you get the reassociation; I am 99% sure there is a dup for this bug too.
(In reply to Andrew Pinski from comment #2) > We don't do as much reassociation as we should with signed integers due to > overflow. If you use -fwrapv, you get the reassociation; I am 99% sure there > is a dup for this bug too. I should say we also do it for unsigned already (see PR 95867), -fwrapv case we just treat signed similar to unsigned here. Anyways what needs to happen is we need 2 levels of gimple, one with signed integer overflow behavior and then one with wrapping behavior. RTL does not distinguish between signed and unsigned behaviors for many operations (plus and multiple) so we get some optimizations there but not all.
I think we've been discussing an idea of turning on flag_wrapv very late among the GIMPLE passes and reassociate again. Because RTL also kind of assumes flag_wrapv, there is no difference between signed/unsigned addition/subtraction/non-widening multiplication. Though, a question is if it wouldn't screw up range info for use during expansion too much. Other option is to rewrite into unsigned operations only what we've successfully reassociated in the late reassoc pass.
For the case in question when x is zero then y can be INT_MAX and thus y * y already overflow. But x * y * y * y * y * y could be associated as (x * y) * (y^4).