This is an archive of the discontinued LLVM Phabricator instance.

[ELF] Parallelize input section initialization
ClosedPublic

Authored by MaskRay on Jul 29 2022, 5:18 PM.

Details

Summary

This implements the last step of
https://discourse.llvm.org/t/parallel-input-file-parsing/60164 for the ELF port.

For an ELF object file, we previously did: parse, (parallel) initializeLocalSymbols, (parallel) postParseObjectFile.
Now we do: parse, (parallel) initSectionsAndLocalSyms, (parallel) postParseObjectFile.

initSectionsAndLocalSyms does most of input section initialization.
The sequential parse does SHT_ARM_ATTRIBUTES/SHT_RISCV_ATTRIBUTES/SHT_GROUP initialization for now.

Performance linking some programs with --threads=8 (glibc 2.33 malloc and mimalloc):

  • clang: 1.05x as fast with glibc malloc, 1.03x as fast with mimalloc
  • chrome: 1.04x as fast with glibc malloc, 1.03x as fast with mimalloc
  • internal search program: 1.08x as fast with glibc malloc, 1.05x as fast with mimalloc

Diff Detail

Event Timeline

MaskRay created this revision.Jul 29 2022, 5:18 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 29 2022, 5:18 PM
MaskRay requested review of this revision.Jul 29 2022, 5:18 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 29 2022, 5:18 PM
MaskRay updated this revision to Diff 448751.Jul 29 2022, 5:22 PM

reduce diff

Will take a look as soon as I can. Have been on holiday the past week so I'm a bit behind schedule.

peter.smith added inline comments.Aug 3 2022, 9:36 AM
lld/ELF/Driver.cpp
2397

I don't think any caller has used the ignoreComdats default parameter, is it worth removing the = false ?

lld/ELF/InputFiles.cpp
524

Worth a comment along the lines of:
"Handle dependent libraries and selection of ELF Section Groups as these cannot be done in parallel."

777

Out of curiosity, is there a reason this needs to be moved from the previous place? No objections to moving it, just curious.

955–956

IIUC createInputSection can be called in parallel now from initializeSections will be worth a comment as a warning to what is safe to be done within the function and any functions called from it.

LLD's handling of Arm build attributes is somewhat threadbare at the moment. I expect that Arm will want to send in some patches to improve this in the future. When they do I think this will need to be moved to avoid threading problems. The current implementation gets away with it as I don't think it ever reads from the global state, just writes to it.

955–956

I'm guessing make_unique is thread safe in this context?

981

Will be worth checking readAndFeatures as they read and update a global value.

lld/include/lld/Common/Memory.h
65 ↗(On Diff #448751)

Apologies in advance, I'm not too familiar with LLVM in this area:

  • As I understand it, we'll be creating a new allocator per thread, and storing it in TLS?
  • I'm assuming that if the underlying threads are destroyed then the allocator and all the memory it points to will be destroyed as well?
  • I'm assuming that we're relying on parallelForEach never destroying threads during the lifetime of a link? Is this safe to rely on?

Would be useful to document the assumptions, as we may have to implement a different solution if parallelForEach ever changes policy in the future.

79 ↗(On Diff #448751)

I suggest makeThreadLocal rather than makeTL as it isn't obvious from the call site that TL is Thread Local and there are not that many calls to it. Not a strong opinion though.

MaskRay updated this revision to Diff 449876.Aug 3 2022, 10:07 PM
MaskRay marked 8 inline comments as done.
MaskRay edited the summary of this revision. (Show Details)

address comments

MaskRay added inline comments.Aug 3 2022, 10:07 PM
lld/ELF/InputFiles.cpp
777

Moved back. The reason is that I have had a very old patch and just recently fixed some issues and posted it here. The code move was due to playing with some parallelism schemes and was not needed.

955–956

Thanks for the heads-up. I have to move the attributes code to ObjFile<ELFT>::parse as otherwise in.attributes == nullptr is racy, though benign, would likely fail thread sanitizer.

981

Thx. readAndFeatures is thread-safe.

lld/include/lld/Common/Memory.h
65 ↗(On Diff #448751)

Good catch. Yes to all 3 questions. I've added a comment to document the assumption.

peter.smith accepted this revision.Aug 4 2022, 2:06 AM

Thanks for the update, looks good to me, I don't have any more comments.

This revision is now accepted and ready to land.Aug 4 2022, 2:06 AM
MaskRay edited the summary of this revision. (Show Details)Aug 4 2022, 11:42 AM
MaskRay updated this revision to Diff 450088.Aug 4 2022, 11:47 AM
MaskRay edited the summary of this revision. (Show Details)

Moved makeThreadLocal to a separate commit to reduce diff and make the patch more focused.

This revision was landed with ongoing or failed builds.Aug 4 2022, 11:50 AM
This revision was automatically updated to reflect the committed changes.