[PATCH] D132482: RISCV: permit unaligned nop-slide padding emission

[Saleem Abdulrasool via Phabricator via llvm-commits]

compnerd created this revision.
compnerd added reviewers: asb, luismarques.
Herald added subscribers: sunshaoce, VincentWu, luke957, StephenFan, vkmr, frasercrmck, evandro, apazos, sameer.abuasal, pengfei, s.egerton, Jim, benna, psnobl, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, atanasyan, edward-jones, zzheng, jrtc27, shiva0217, kito-cheng, niosHD, sabuasal, simoncook, johnrusso, rbar, hiraditya, kristof.beyls, arichardson, sdardis.
Herald added a project: All.
compnerd requested review of this revision.
Herald added subscribers: pcwang-thead, eopXD, MaskRay.
Herald added a project: LLVM.

We may be requested to emit an unaligned nop sequence (e.g. 7-bytes or
3-bytes).  These should be 0-filled even though that is not a valid
instruction.  This matches the behaviour on other architectures like
ARM, X86, and MIPS.  When a custom section is emitted, it may be
classified as text even though it may be a data section or we may be
emitting data into a text segment (e.g. a literal pool).  In such cases,
we should be resilient to the emission request.

The test case may seem to be under-reduced due to the use of LLVM IR
rather than assembly for the input, however, I was unable to reproduce
the failure when using the assembly input.

This was originally identified by the Linux kernel build and reported on
D131270 <https://reviews.llvm.org/D131270> by Nathan Chancellor.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D132482

Files:
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVAsmBackend.cpp
  llvm/test/MC/RISCV/nop-slide.ll


Index: llvm/test/MC/RISCV/nop-slide.ll
===================================================================
--- /dev/null
+++ llvm/test/MC/RISCV/nop-slide.ll
@@ -0,0 +1,10 @@
+; RUN: llc -mtriple riscv64-unknown-linux-gnu -filetype obj -o - %s | llvm-objdump -t - | FileCheck %s
+
+target datalayout = "e-m:e-p:64:64-i64:64-i128:128-n64-S128"
+target triple = "riscv64-unknown-linux-gnu"
+
+ at b = dso_local global i8 0, section ".init.data", align 1
+ at c= dso_local global ptr null, section ".init.data", align 8
+
+; CHECK: 0000000000000000 g     O .init.data	0000000000000001 b
+; CHECK: 0000000000000008 g     O .init.data	0000000000000008 c
Index: llvm/lib/Target/RISCV/MCTargetDesc/RISCVAsmBackend.cpp
===================================================================
--- llvm/lib/Target/RISCV/MCTargetDesc/RISCVAsmBackend.cpp
+++ llvm/lib/Target/RISCV/MCTargetDesc/RISCVAsmBackend.cpp
@@ -354,20 +354,21 @@

 bool RISCVAsmBackend::writeNopData(raw_ostream &OS, uint64_t Count,
                                    const MCSubtargetInfo *STI) const {
-  bool HasStdExtC = STI->getFeatureBits()[RISCV::FeatureStdExtC];
-  unsigned MinNopLen = HasStdExtC ? 2 : 4;
-
-  if ((Count % MinNopLen) != 0)
-    return false;
-
   // The canonical nop on RISC-V is addi x0, x0, 0.
   for (; Count >= 4; Count -= 4)
     OS.write("\x13\0\0\0", 4);

   // The canonical nop on RVC is c.nop.
-  if (Count && HasStdExtC)
-    OS.write("\x01\0", 2);
-
+  if (STI->getFeatureBits()[RISCV::FeatureStdExtC])
+    for (; Count >= 2; Count -= 2)
+      OS.write("\x01\0", 2);
+
+  // If the count is not 4-byte aligned, we must be writing data into the text
+  // section (otherwise we have unaligned instructions, and thus have far
+  // bigger problems), so just write zeros instead.  This also may occur for
+  // non-standard data sections which are not declared and thus get detected as
+  // text rather than data.
+  OS.write_zeros(Count);
   return true;
 }



-------------- next part --------------
A non-text attachment was scrubbed...
Name: D132482.454867.patch
Type: text/x-patch
Size: 1950 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220823/66c13ce7/attachment.bin>