0x0f 0x6f 0xc8 And 0x0f 0x7f 0xc1 Should both be movq % mm0, % mm1. (AT&T) However, llvm 3.4 at least does not recognise the second variant as being a valid instruction. We are currently compiling up latest src incase it has been fixed. If not, could someone take a look or recommend how to fix? Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140416/782efc94/attachment.html>
It has not been fixed. This should do it. I don't have time to commit it or
write the test case at the moment.
diff --git a/lib/Target/X86/X86InstrMMX.td b/lib/Target/X86/X86InstrMMX.td
index 050ee39..47672f3 100644
--- a/lib/Target/X86/X86InstrMMX.td
+++ b/lib/Target/X86/X86InstrMMX.td
@@ -254,6 +254,11 @@ let neverHasSideEffects = 1 in
def MMX_MOVQ64rr : MMXI<0x6F, MRMSrcReg, (outs VR64:$dst), (ins VR64:$src),
"movq\t{$src, $dst|$dst, $src}", [],
IIC_MMX_MOVQ_RR>;
+let isCodeGenOnly = 1, ForceDisassemble = 1, hasSideEffects = 0 {
+def MMX_MOVQ64rr_REV : MMXI<0x7F, MRMDestReg, (outs VR64:$dst), (ins
VR64:$src),
+ "movq\t{$src, $dst|$dst, $src}", [],
+ IIC_MMX_MOVQ_RR>;
+}
} // SchedRW
let SchedRW = [WriteLoad] in {
On Wed, Apr 16, 2014 at 6:37 AM, Lee Hammerton
<savoury.snax at googlemail.com>wrote:
>
> 0x0f 0x6f 0xc8
>
> And
>
> 0x0f 0x7f 0xc1
>
> Should both be movq % mm0, % mm1. (AT&T)
>
> However, llvm 3.4 at least does not recognise the second variant as being
> a valid instruction.
>
> We are currently compiling up latest src incase it has been fixed. If not,
> could someone take a look or recommend how to fix?
>
> Lee
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
--
~Craig
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140416/1aaf89a1/attachment.html>
There was a minor typo in that patch, but I submitted a real fix to the trunk. On Wed, Apr 16, 2014 at 8:28 AM, Craig Topper <craig.topper at gmail.com>wrote:> It has not been fixed. This should do it. I don't have time to commit it > or write the test case at the moment. > > diff --git a/lib/Target/X86/X86InstrMMX.td b/lib/Target/X86/X86InstrMMX.td > > index 050ee39..47672f3 100644 > > --- a/lib/Target/X86/X86InstrMMX.td > > +++ b/lib/Target/X86/X86InstrMMX.td > > @@ -254,6 +254,11 @@ let neverHasSideEffects = 1 in > > def MMX_MOVQ64rr : MMXI<0x6F, MRMSrcReg, (outs VR64:$dst), (ins > VR64:$src), > > "movq\t{$src, $dst|$dst, $src}", [], > > IIC_MMX_MOVQ_RR>; > > +let isCodeGenOnly = 1, ForceDisassemble = 1, hasSideEffects = 0 { > > +def MMX_MOVQ64rr_REV : MMXI<0x7F, MRMDestReg, (outs VR64:$dst), (ins > VR64:$src), > > + "movq\t{$src, $dst|$dst, $src}", [], > > + IIC_MMX_MOVQ_RR>; > > +} > > } // SchedRW > > > > let SchedRW = [WriteLoad] in { > > > On Wed, Apr 16, 2014 at 6:37 AM, Lee Hammerton < > savoury.snax at googlemail.com> wrote: > >> >> 0x0f 0x6f 0xc8 >> >> And >> >> 0x0f 0x7f 0xc1 >> >> Should both be movq % mm0, % mm1. (AT&T) >> >> However, llvm 3.4 at least does not recognise the second variant as being >> a valid instruction. >> >> We are currently compiling up latest src incase it has been fixed. If >> not, could someone take a look or recommend how to fix? >> >> Lee >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> > > > -- > ~Craig >-- ~Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140416/1d5b6c9e/attachment.html>