[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for-9.1 09/19] target/i386: move 60-BF opcodes to new decoder
|
From: |
Paolo Bonzini |
|
Subject: |
Re: [PATCH for-9.1 09/19] target/i386: move 60-BF opcodes to new decoder |
|
Date: |
Thu, 11 Apr 2024 13:18:29 +0200 |
On Thu, Apr 11, 2024 at 9:47 AM Richard Henderson
<richard.henderson@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