summaryrefslogtreecommitdiffstats
path: root/llvm/lib/IR/Module.cpp
diff options
context:
space:
mode:
authorPeter Collingbourne <peter@pcc.me.uk>2018-08-23 05:39:36 +0000
committerPeter Collingbourne <peter@pcc.me.uk>2018-08-23 05:39:36 +0000
commita67161fffae78b400866860be51e1388139251ba (patch)
treebafa00d97cd2db251b17beb38aa1e7f2aced7b1a /llvm/lib/IR/Module.cpp
parent8505dcf7459ef6fafe1326ecc1fe6b67d4d95739 (diff)
downloadbcm5719-llvm-a67161fffae78b400866860be51e1388139251ba.tar.gz
bcm5719-llvm-a67161fffae78b400866860be51e1388139251ba.zip
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
Diffstat (limited to 'llvm/lib/IR/Module.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud