[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