[LLVMdev] Bogus X86-64 Patterns

[Evan Cheng]

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.

Right.

>
> 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  
expected:
movd %rax, %xmm0

$ otool64 -t a.o
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  
rex.w:

movd %xmm0, (%eax)
$ otool64 -t a.o
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.

Thanks,

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