<div dir="ltr">This isn't used for code, it's used for data.  It's not so much a nop so much as it is padding.<div><br></div><div>For additional reassurance, the ARM backend works in a very similar way:</div><div>
ARMAsmBackend::writeNopData() for 'thumb' mode will use thumb nops and follow it up with a zero.</div><div>ARMAsmBackend::writeNopData() for 'arm' mode will use arm nops and follow it up with some % 4 number of bytes.<br>
</div><div><br></div><div>N.B.  I see no rationale for why the ARMAsmBackend::writeNopData() will emit 0x00 0x00 0xa0 when faced with three padding bytes...</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Sep 30, 2013 at 3:07 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div><div class="h5">On Thu, Sep 26, 2013 at 2:18 AM, David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.com</a>></span> wrote:<br>
</div></div><div class="gmail_quote"><div><div class="h5">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Author: majnemer<br>
Date: Thu Sep 26 04:18:48 2013<br>
New Revision: 191426<br>
<br>
URL: <a href="http://llvm.org/viewvc/llvm-project?rev=191426&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=191426&view=rev</a><br>
Log:<br>
PPC: Allow partial fills in writeNopData()<br>
<br>
When asked to pad an irregular number of bytes, we should fill with<br>
zeros.  This is consistent with the behavior specified in the AIX<br>
Assembler Language Reference as well as other LLVM and binutils<br>
assemblers.<br>
<br>
N.B. There is a small deviation from binutils' PPC assembler:<br>
when handling pads which are greater than 4 bytes but not mod 4,<br>
binutils will not emit any NOP sequences at all and only use zeros.<br>
This may or may not be a bug but there is no excellent rationale as to<br>
why that behavior is important to emulate.  If that behavior is needed,<br>
we can change writeNopData() to behave in the same way.<br>
<br>
This fixes PR17352.<br>
<br>
Modified:<br>
    llvm/trunk/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp<br>
    llvm/trunk/test/MC/PowerPC/ppc-nop.s<br>
<br>
Modified: llvm/trunk/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp<br>
URL: <a href="http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp?rev=191426&r1=191425&r2=191426&view=diff" target="_blank">http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp?rev=191426&r1=191425&r2=191426&view=diff</a><br>


==============================================================================<br>
--- llvm/trunk/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp (original)<br>
+++ llvm/trunk/lib/Target/PowerPC/MCTargetDesc/PPCAsmBackend.cpp Thu Sep 26 04:18:48 2013<br>
@@ -132,14 +132,17 @@ public:<br>
   }<br>
<br>
   bool writeNopData(uint64_t Count, MCObjectWriter *OW) const {<br>
-    // Can't emit NOP with size not multiple of 32-bits<br>
-    if (Count % 4 != 0)<br>
-      return false;<br>
-<br>
     uint64_t NumNops = Count / 4;<br>
     for (uint64_t i = 0; i != NumNops; ++i)<br>
       OW->Write32(0x60000000);<br>
<br>
+    switch (Count % 4) {<br>
+    default: break; // No leftover bytes to write<br>
+    case 1: OW->Write8(0); break;<br>
+    case 2: OW->Write16(0); break;<br>
+    case 3: OW->Write16(0); OW->Write8(0); break;<br>
+    }<br><br></blockquote><div><br></div></div></div><div>This is probably a silly question, but are you sure the switch is supposed to be after the loop?  It looks like you're emitting misaligned nops.</div><span class="HOEnZb"><font color="#888888"><div>
<br></div><div>
-Eli </div></font></span></div><br></div></div>
</blockquote></div><br></div>