[LLVMbugs] [Bug 17691] New: ARM has conflicting aliases for VMOV.F64

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=17691

            Bug ID: 17691
           Summary: ARM has conflicting aliases for VMOV.F64
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
          Assignee: unassignedbugs at nondot.org
          Reporter: t.p.northover at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The ARM NEON instructions define an InstAlias from "vmov.64 dD, dN" to "vmov
dD, dN" (the canonical NEON vmov). Unfortunately we also define a TokenAlias
from ".f64" to ".64".

Together these mean that "vmov.f64 d0, d0" will be accepted as a NEON
instruction:

$ echo "vmov.f64 d0, d0" | llvm-mc -triple thumbv7 -mattr=+neon,+fp-only-sp
-show-inst
        vorr    d11, d10, d10           @ <MCInst #1477 VORRd
                                        @  <MCOperand Reg:25>
                                        @  <MCOperand Reg:24>
                                        @  <MCOperand Reg:24>
                                        @  <MCOperand Imm:14>
                                        @  <MCOperand Reg:0>>

The ARM ARM states that .f64 must not be used for the NEON encoding.

The order of these aliases as emitted by TableGen could switch at any time,
leaving "vmov.f64" being assembled as VORR generally (I believe this may
currently be the case on Windows).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20131025/eb93a2c4/attachment.html>