diff options
| author | Fangrui Song <maskray@google.com> | 2019-04-18 07:46:09 +0000 |
|---|---|---|
| committer | Fangrui Song <maskray@google.com> | 2019-04-18 07:46:09 +0000 |
| commit | 957c356ffec47c9693b740244fe3001e1f5c7c00 (patch) | |
| tree | 62ee513af11d49b23dc06b908cb62fde9364afaf /llvm/lib/Passes/PassBuilder.cpp | |
| parent | 009a21d2fdff9117cafc853a2fe7e8355d2d31cc (diff) | |
| download | bcm5719-llvm-957c356ffec47c9693b740244fe3001e1f5c7c00.tar.gz bcm5719-llvm-957c356ffec47c9693b740244fe3001e1f5c7c00.zip | |
[ELF] Place SectionPiece::{Live,Hash} bit fields together
Summary:
We access Live and OutputOff (which may share the same memory location)
concurrently in 2 parallelForEachN loops. Separating them avoids subtle
data races like D41884/PR35788. This patch places Live and Hash
together.
2 reasons this is appealing:
1) Hash is immutable. Live is almost read-only - only written once in MarkLive.cpp where
Hash is not accessed
2) we already discard low bits of Hash to decide ShardID. It doesn't
matter much if we make 32-bit Hash to 31-bit.
For a huge internal clang -O3 executable (1.6GiB),
`Strings` in StringTableBuilder::finalizeStringTable contains at most 310253 elements.
The expected number of pair-wise collisions 2^(-31) * C(310253,2) ~= 22.41 is too small to have a negative impact on performance.
Actually, my benchmark shows there is actually a minor performance improvement.
Differential Revision: https://reviews.llvm.org/D60765
llvm-svn: 358645
Diffstat (limited to 'llvm/lib/Passes/PassBuilder.cpp')
0 files changed, 0 insertions, 0 deletions

