[MC] Explicitly use memcpy in emitBytes() (NFC)

[nikic]

We've observed a compile-time regression in LLVM 22 when including large blobs. The root cause was that emitBytes() was copying bytes one-by-one, which is much slower than using memcpy for large objects.

Optimization of std::copy to memmove is apparently much less reliable than one might think. In particular, when using a non-bleeding-edge libstdc++ (anything older than version 15), this does not happen if the types of the input and output iterators do not match (like here, where there is a signed/unsigned mismatch).

As this code is performance sensitive, I think it makes sense to directly use memcpy.

Previously this code used SmallVector::append, which explicitly uses memcpy here:

llvm-project/llvm/include/llvm/ADT/SmallVector.h

Line 519 in 82d7a52

std::memcpy(reinterpret_cast<void *>(Dest), I, (E - I) * sizeof(T));

[llvmbot]

@llvm/pr-subscribers-llvm-mc

Author: Nikita Popov (nikic)

Changes

We've observed a compile-time regression in LLVM 22 when including large blobs. The root cause was that emitBytes() was copying bytes one-by-one, which is much slower than using memcpy for large objects.

Optimization of std::copy to memmove is apparently much less reliable than one might think. In particular, when using a non-bleeding-edge libstdc++ (anything older than version 15), this does not happen if the types of the input and output iterators do not match (like here, where there is a signed/unsigned mismatch).

As this code is performance sensitive, I think it makes sense to directly use memcpy.

Previously this code used SmallVector::append, which explicitly uses memcpy here:

llvm-project/llvm/include/llvm/ADT/SmallVector.h

Line 519 in 82d7a52

std::memcpy(reinterpret_cast<void *>(Dest), I, (E - I) * sizeof(T));

---

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

1 Files Affected:

• (modified) llvm/lib/MC/MCObjectStreamer.cpp (+3-1)

diff --git a/llvm/lib/MC/MCObjectStreamer.cpp b/llvm/lib/MC/MCObjectStreamer.cpp
index 261e9a37ecb55..d44e14a35cac8 100644
--- a/llvm/lib/MC/MCObjectStreamer.cpp
+++ b/llvm/lib/MC/MCObjectStreamer.cpp
@@ -109,7 +109,9 @@ void MCObjectStreamer::addSpecialFragment(MCFragment *Frag) {
 void MCObjectStreamer::appendContents(ArrayRef<char> Contents) {
   ensureHeadroom(Contents.size());
   assert(FragSpace >= Contents.size());
-  llvm::copy(Contents, getCurFragEnd());
+  // As this is performance-sensitive code, explicitly use std::memcpy.
+  // Optimization of std::copy to memmove is unreliable.
+  std::memcpy(getCurFragEnd(), Contents.begin(), Contents.size());
   CurFrag->FixedSize += Contents.size();
   FragSpace -= Contents.size();
 }

[nikic]

/cherry-pick 15e421d

[llvmbot]

/pull-request #177320

[pcc]

Looks like this caused a ubsan failure: https://lab.llvm.org/buildbot/#/builders/85/builds/17944 . Can you please take a look?

(Specifically the tools/llvm-dwarfutil/ELF/X86/dwarf4-macro-vendor-specific.test failure; the LLD failures are unrelated and were fixed by #177562.)

[nikic]

I've pushed a speculative fix at d064f39.

[nikic]

/cherry-pick d064f39

[llvmbot]

/pull-request #177907