[llvm] [MC][DebugInfo] Emit linetable entries with known offsets immediately (PR #134677)

[via llvm-commits]

llvmbot wrote:


<!--LLVM PR SUMMARY COMMENT-->

@llvm/pr-subscribers-debuginfo

Author: Jeremy Morse (jmorse)

<details>
<summary>Changes</summary>

DWARF linetable entries are usually emitted as a sequence of MCDwarfLineAddrFragment fragments containing the line-number difference and an MCExpr describing the instruction-range the linetable entry covers. These then get relaxed during assembly emission.

However, a large number of these instruction-range expressions are ranges within a fixed MCDataFragment, i.e. a range over fixed-size instructions that are not subject to relaxation at a later stage. Thus, we can compute the address-delta immediately, and not spend time and memory describing that computation so it can be deferred.

~

A slightly earlier+dirtier version of this patch scored a cool 5% reduction in max-rss on most compile-time tracker samples -- see [0], scroll down to stage1-releaselto-g and observe the improvement in ".link" jobs. The intermediate jobs are LTO bitcode compilations so don't codegen, thus only the .link jobs are representative. The three compiles that don't improve (tramp3d, mafft, SPASS) are due to the domination of variable-location storage for tramp3d, and LiveDebugValues hitting max-rss for the last two. 

I'm not intensely familiar with the MCFragment layer so I'm not sure what the best test strategy is. A stage2reldeb build of clang produced an identical binary, but as a performance improvement it's not clear if this needs a functional test. If so, I imagine using `-debug-only=mc-dump` and examining what fragments are produced would be the way forwards?

Note that the RISCV opt-out comes from precedent set in `MCObjectStreamer::emitAbsoluteSymbolDiff` and friends, RISCV appears to want to opt out of these space optimisations.

[0] https://llvm-compile-time-tracker.com/compare.php?from=e2c43ba981620cf71ce3ccf004db7c0db4caf8a7&to=ca512762f92108bea21b2e2517f9e17f9d680a33&stat=max-rss&details=on

---
Full diff: https://github.com/llvm/llvm-project/pull/134677.diff


1 Files Affected:

- (modified) llvm/lib/MC/MCObjectStreamer.cpp (+18) 


``````````diff
diff --git a/llvm/lib/MC/MCObjectStreamer.cpp b/llvm/lib/MC/MCObjectStreamer.cpp
index e228418fea987..8d1eab03290a9 100644
--- a/llvm/lib/MC/MCObjectStreamer.cpp
+++ b/llvm/lib/MC/MCObjectStreamer.cpp
@@ -462,6 +462,24 @@ void MCObjectStreamer::emitDwarfAdvanceLineAddr(int64_t LineDelta,
                          Label, PointerSize);
     return;
   }
+
+  // If the two labels are within the same fragment and it's a plain data
+  // fragment, then the address-offset is already a fixed constant and is not
+  // relaxable. Emit the advance-line-addr data immediately to save time and
+  // memory.
+  // As per commit bbea64250f6548, RISCV always desires symbolic relocations.
+  MCFragment *LastFrag = LastLabel->getFragment();
+  if (!getAssembler().getContext().getTargetTriple().isRISCV() &&
+      LastFrag->getKind() == MCFragment::FT_Data &&
+      Label->getFragment() == LastFrag) {
+    uint64_t AddrDelta = Label->getOffset() - LastLabel->getOffset();
+    SmallString<16> Tmp;
+    MCDwarfLineAddr::encode(getContext(), Assembler->getDWARFLinetableParams(),
+                            LineDelta, AddrDelta, Tmp);
+    emitBytes(Tmp);
+    return;
+  }
+
   const MCExpr *AddrDelta = buildSymbolDiff(*this, Label, LastLabel, SMLoc());
   insert(getContext().allocFragment<MCDwarfLineAddrFragment>(LineDelta,
                                                              *AddrDelta));

``````````

</details>


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