[llvm-bugs] [Bug 25956] New: hexagon 3bit .new register fields are not decoded properly

via llvm-bugs llvm-bugs at lists.llvm.org
Mon Dec 28 11:09:02 PST 2015


https://llvm.org/bugs/show_bug.cgi?id=25956

            Bug ID: 25956
           Summary: hexagon 3bit .new register fields are not decoded
                    properly
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Target Description Classes
          Assignee: unassignedbugs at nondot.org
          Reporter: itsme at xs4all.nl
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

for example:  ( disassembly by quic binutils )

    0x78004021   { r1 = #1
    0x0FCC4200     immext (#0xFCC08000)
    0x91994711     r17 = memw (r25 + ##dword_FCC08038)
    0x2403E00C     if (cmp.eq (r17.new, #0)) jump:t loc_FCC08530 }

the last intruction is defined like this in the v5 programmers reference:

      1098 7 65432 10 9 876 54 3 21098 7654321 0
----  0010 0 10000 00 0 011 11 1 00000 0000110 0  0x2403E00C
pdf:  0010 - 10000 ii - sss PP 1 IIIII iiiiiii -  if (cmp.eq(Ns.new,#U5))
jump:t #r9:2

llvm decodes this to: J4_cmpeqi_t_jumpnv_t

the tablegen definition is  NVJri_template, where:
  bits<3> src1;  is defined  as  IntRegs in 'ins'

this causes the 'sss' field to be de/en-coded in
decodeToMCInst/getBinaryCodeForInstr as a normal register, instead of using the
'sss' field as an index in the instruction packet outputs.

The programmers reference describes this in section 10.11 "New-value operands"

-- 
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/20151228/36d2ff38/attachment.html>


More information about the llvm-bugs mailing list