[LLVMdev] Wrong encoding of movd on x64
evan.cheng at apple.com
Mon Jul 13 22:54:49 PDT 2009
Intel syntax is extremely confusing. I often can't figure out when to
use movd or movq.
On Jul 9, 2009, at 10:12 AM, Eli Friedman wrote:
> On Thu, Jul 9, 2009 at 8:44 AM, Nicolas Capens<nicolas at capens.net>
>> I believe I’ve found a bug in the encoding of the movd instruction
>> on x64.
>> Here’s some IR code to reproduce it:
>> Note the last movq. What was probably intended to be generated was
>> ecx, mm0”. LLVM mistakenly sets the ‘wide’ bit of the REX prefix to
>> turning movd into movq. Also, reg and r/m encoding has been
>> swapped. I have
>> not found a fix for this yet, but the MMX_MOVD64* definitions and
>> looks suspicious.
> Thanks for the testcase; fixed in r75142.
>> Note that on x86-32 it produces correct code (though not optimal
>> either; it
>> doesn’t use movd). Also, notice that the last two instructions
>> above should
>> ideally just be a single movd to memory, instead of first writing
>> to a GP
> The suboptimal code on x86-32 is because there aren't patterns for i32
> extract from <2 x i32> yet (so it gets expanded through memory). The
> suboptimal code on x86-64 is due to a missing dagcombine; it doesn't
> know that extracting an i64 and truncating it to an i32 is equivalent
> to extracting an i32.
>> In the same breath, I believe the encoding of MMX_MOVDQ2Qrr is
>> I’ve been able to fix the first two definitions by using MRMSrcReg
>> (and set
>> hasNoSideEffects). I’m not sure about the third definition though,
>> is this
>> for 3DNow! And should it use MRMSrcReg as well?
> Also fixed in r75142. Note that MMX_MOVQ2FR64rr is actually exactly
> the same instruction as MMX_MOVQ2DQrr; they're separated because it's
> a bit more straightforward to write that way (FR64 and VR128 are both
> XMM registers, but TableGen isn't aware of the precise relationship).
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev