<div dir="ltr">Such bits often become non-zero on later versions of the architecture.<div><br></div><div>As Ralf says the code in question came from firmware, not from LLVM, it's entirely possible that it's a valid but undocumented instruction, and attempting to use re-assembled code with that bit forced to zero will not work.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 1, 2016 at 9:24 PM, Colin LeMahieu via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This looks similar to <a href="https://llvm.org/bugs/show_bug.cgi?id=25956" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_bug.cgi?id=25956</a>, it looks like the instruction is encoded incorrectly, for instance if you re-assemble that packet that bit is not set.<br>
<br>
I added r259380 which points out the location in the manual which says this bit must be 0, 10.11 "Nt[0] is reserved and should always be encoded as zero".<br>
<br>
Your patch does work around the issue in the meantime.<br>
<div><div class="h5"><br>
-----Original Message-----<br>
From: llvm-dev [mailto:<a href="mailto:llvm-dev-bounces@lists.llvm.org">llvm-dev-bounces@lists.llvm.org</a>] On Behalf Of Ralf-Philipp Weinmann via llvm-dev<br>
Sent: Monday, February 01, 2016 8:00 AM<br>
To: <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
Subject: [llvm-dev] [Hexagon] Failure to disassemble some new-value instructions<br>
<br>
Dear list,<br>
<br>
I noticed that the Hexagon disassembler has issues with disassembling some firmwares I have. When tracing one of these problems, the handling of some new-value instructions in HexagonDisassembler::getSingleInstruction() turned out to be the cause, specifically this statement:<br>
<br>
[lines 384-386 in HexagonDisassembler.cpp in HEAD]<br>
else if (SubregBit)<br>
// Subreg bit should not be set for non-doublevector newvalue producers<br>
return MCDisassembler::Fail;<br>
<br>
Where does the requirement come from? Maybe I overlooked it, but I do not see it in the Hexagon V5/V55 Programmer’s Reference Manual.<br>
<br>
One instruction packet I have encountered in the wild that triggers this failure is:<br>
<br>
10: e0 7e df 78 78df7ee0 { r0 = #-9<br>
14: 01 40 91 91 91914001 r1 = memw(r17 + #0)<br>
18: 10 e1 03 25 2503e110 if (cmp.gtu(r1.new, #1)) jump:t 0x30 }<br>
<br>
Removing the requirement seems to work fine (see attached patch).<br>
<br>
Cheers,<br>
Ralf<br>
<br>
<br>
</div></div>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div>