On Thu, Apr 11, 2024 at 9:47 AM Richard Henderson <richard.hender...@linaro.org> wrote: > > + case MO_32: > > +#ifdef TARGET_X86_64 > > + /* > > + * This could also use the same algorithm as MO_16. It produces > > fewer > > + * TCG ops and better code if flags are needed, but it requires a > > 64-bit > > + * multiply even if they are not (and thus the high part of the > > multiply > > + * is dead). > > + */ > > Is 64-bit multiply ever slower these days? > My intuition says "slow" multiply is at least a decade out of date.
I was thinking more about TCG_TARGET_REG_BITS == 32. > > + tcg_gen_negsetcondi_i32(TCG_COND_LT, s->tmp2_i32, s->tmp2_i32, 0); > > This seems like something the optimizer should handle, but doesn't. I wanted to avoid using TARGET_LONG_BITS - 1, but it's not a problem to use extract. I've changed it. At least the ppc and x86 backends do support it and convert it to SAR, so I didn't notice in my test that it was the backend doing it and not the optimizer! Paolo
