MC: Don't align COFF section contents.
Aligning section contents is not required, but only
recommended, by the specification. Microsoft's documentation says
(https://docs.microsoft.com/en-us/windows/desktop/debug/pe-format#section-table-section-headers):
"For object files, the value should be aligned on a 4-byte boundary
for best performance."
However, according to my measurements, aligning section contents has
a neutral to negative effect on performance.
I measured the median run time of 100 links of Chromium's
base_unittests on Linux with lld-link and on Windows with link.exe with
both aligned and unaligned sections. On Linux I didn't see a measurable
performance difference, and on Windows the link was slightly faster
with unaligned sections (presumably because on Windows the bottleneck
is I/O).
Also, the sections created by cl.exe are unaligned, so we should expect
tools to broadly accept unaligned sections.
Differential Revision: https://reviews.llvm.org/D51149
llvm-svn: 340514
diff --git a/llvm/lib/MC/WinCOFFObjectWriter.cpp b/llvm/lib/MC/WinCOFFObjectWriter.cpp
index 82c9fe7..ab6fc2b 100644
--- a/llvm/lib/MC/WinCOFFObjectWriter.cpp
+++ b/llvm/lib/MC/WinCOFFObjectWriter.cpp
@@ -620,14 +620,9 @@
// Write the section contents.
if (Sec.Header.PointerToRawData != 0) {
- assert(W.OS.tell() <= Sec.Header.PointerToRawData &&
+ assert(W.OS.tell() == Sec.Header.PointerToRawData &&
"Section::PointerToRawData is insane!");
- unsigned PaddingSize = Sec.Header.PointerToRawData - W.OS.tell();
- assert(PaddingSize < 4 &&
- "Should only need at most three bytes of padding!");
- W.OS.write_zeros(PaddingSize);
-
uint32_t CRC = writeSectionContents(Asm, Layout, MCSec);
// Update the section definition auxiliary symbol to record the CRC.
@@ -912,10 +907,7 @@
Sec->Header.SizeOfRawData = Layout.getSectionAddressSize(&Section);
if (IsPhysicalSection(Sec)) {
- // Align the section data to a four byte boundary.
- Offset = alignTo(Offset, 4);
Sec->Header.PointerToRawData = Offset;
-
Offset += Sec->Header.SizeOfRawData;
}