[llvm] [RISCV] Improvements to .note.gnu.property section. (PR #151436)

[Ming-Yi Lai via llvm-commits]

================
@@ -83,29 +86,21 @@ void RISCVTargetStreamer::emitNoteGnuPropertySection(
   OutStreamer.switchSection(NoteSection);
 
   // Emit the note header
-  OutStreamer.emitIntValue(4, 4); // n_namsz
-
-  MCSymbol *const NDescBeginSym = Ctx.createTempSymbol();
-  MCSymbol *const NDescEndSym = Ctx.createTempSymbol();
-  const MCExpr *const NDescSzExpr =
-      MCBinaryExpr::createSub(MCSymbolRefExpr::create(NDescEndSym, Ctx),
-                              MCSymbolRefExpr::create(NDescBeginSym, Ctx), Ctx);
-
-  OutStreamer.emitValue(NDescSzExpr, 4);                    // n_descsz
+  OutStreamer.emitValueToAlignment(NoteAlign);
+  OutStreamer.emitIntValue(4, 4);                           // n_namsz
+  OutStreamer.emitIntValue(DescSize, 4);                    // n_descsz
   OutStreamer.emitIntValue(ELF::NT_GNU_PROPERTY_TYPE_0, 4); // n_type
   OutStreamer.emitBytes(StringRef("GNU", 4));               // n_name
 
   // Emit n_desc field
-  OutStreamer.emitLabel(NDescBeginSym);
-  OutStreamer.emitValueToAlignment(NoteAlign);
 
   // Emit the feature_1_and property
   OutStreamer.emitIntValue(ELF::GNU_PROPERTY_RISCV_FEATURE_1_AND, 4); // pr_type
   OutStreamer.emitIntValue(4, 4);              // pr_datasz
   OutStreamer.emitIntValue(Feature1And, 4);    // pr_data
-  OutStreamer.emitValueToAlignment(NoteAlign); // pr_padding
+  if (Triple.isArch64Bit())
+    OutStreamer.emitIntValue(0, 4);            // pr_padding
----------------
mylai-mtk wrote:

While we're not supposed to emit alignment directives at an already aligned location (as indicated by @MaskRay), I guess this does not prohibit us from emitting alignment directives at an location that is known to be misaligned like this? If so, why emit ambiguous zeros when alignment directives can be used here to improve readability and robustness?

https://github.com/llvm/llvm-project/pull/151436