[LLVMdev] Bogus X86-64 Patterns

Evan Cheng evan.cheng at apple.com
Wed Dec 12 16:16:25 PST 2007

On Dec 12, 2007, at 2:10 PM, David Greene wrote:

> Tracking down a problem with one of our benchmark codes, we've  
> discovered that
> some of the patterns in X86InstrX86-64.td are wrong.  Specifically:
> def MOV64toPQIrm : RPDI<0x6E, MRMSrcMem, (outs VR128:$dst), (ins  
> i64mem:$src),
>                         "mov{d|q}\t{$src, $dst|$dst, $src}",
>                         [(set VR128:$dst,
>                           (v2i64 (scalar_to_vector (loadi64 addr: 
> $src))))]>;
> def MOVPQIto64mr  : RPDI<0x7E, MRMDestMem, (outs), (ins i64mem: 
> $dst, VR128:
> $src),
>                          "mov{d|q}\t{$src, $dst|$dst, $src}",
>                          [(store (i64 (vector_extract (v2i64 VR128: 
> $src),
>                                        (iPTR 0))), addr:$dst)]>;
> These say that for an AT&T-style assembler, output movd and for an  
> Intel
> assembler, output movq.


> The problem is that such movs to and from memory must either use movq
> or put a rex prefix before the movd.  No such rex prefix appears in  
> these
> patterns, meaning the instructions will move 32 bits rather than 64  
> bits.

You mean there should be a "rex" in the assembly string? That is,

rex movd %rax, %xmm0

The Mac OS X assembly does not take rex prefix. So this is what's  
movd %rax, %xmm0

$ otool64 -t a.o
(__TEXT,__text) section
00000000 6e0f4866 000000c0

> For the rr variants it is ok because the assembler sees the r  
> register use and
> adds the necessary rex prefix.  It cannot do so for memory moves.
> These patterns are just wrong.  So either the MaxOS assembler adds  
> a rex
> (which is wrong if you really wanted 32 bits) or these patterns are  
> broken on
> MaxOS as well and the MacOS assembler really needs to be fixed.

Hrm. Good point. Looks like the Mac OS X assembler is always adding  

movd %xmm0, (%eax)
$ otool64 -t a.o
(__TEXT,__text) section
00000000 7e0f6667 00000000

I'll ping our assembler guy.

> We are changing these to movq in our copy of llvm.  Shall I send  
> the changes
> upstream?

Hold on, changing to movq will break it on Mac OS X. I'll need to  
find a proper solution.


>                                                -Dave
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list