This is an archive of the discontinued LLVM Phabricator instance.

[JITLink][NFC] Store external symbols in a StringMap
ClosedPublic

Authored by jobnoorman on May 18 2023, 8:14 AM.

Details

Summary

External symbols used to be stored in a DenseSet. An assert in
addExternalSymbol ensures that names of external symbols are unique.
However, for objects containing a huge number of external symbols, this
assert can be a performance bottleneck.

This patch proposes to store external symbols in a StringMap instead
making it significantly cheaper to check if a certain symbol name
already exists.

This issue came up while porting BOLT to JITLink (D147544): linking a
large binary using the JITLink port turned out to be about 4x slower
than the current version of BOLT that uses RuntimeDyld. This slowdown
was caused entirely by the assert in addExternalSymbol. Using this
patch, the JITLink port is slightly faster than RuntimeDyld.

Note that I fully understand that adding complexity to improve the
performance of an assert might not be acceptable (since the checks
shouldn't exist in release builds). This patch has another advantage,
however: since external symbol names really have to be unique, it could
make sense to make this clear at the type level.

Diff Detail

Event Timeline

jobnoorman created this revision.May 18 2023, 8:14 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 18 2023, 8:14 AM
Herald added subscribers: asb, pmatos. · View Herald Transcript
jobnoorman requested review of this revision.May 18 2023, 8:14 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 18 2023, 8:14 AM

I'll have to maintain this diff downstream when BOLT switches to JITLink. If this can be maintained by upstream JITLink devs, I would appreciate it. Thanks.

Ping. Can't we just remove this assertion? Is it worth making the runtime much slower to check that we don't have a duplicate external symbol?

maksfb accepted this revision.Jul 12 2023, 11:15 AM
maksfb added a subscriber: maksfb.

@lhames, this looks pretty harmless change to me. Please let us know if you disagree.

This revision is now accepted and ready to land.Jul 12 2023, 11:15 AM
maksfb added a comment.Aug 3 2023, 2:22 AM

@jobnoorman: should be fine to land it.

Hi @lhames, I'm planning to land this at the beginning of next week. Please let me know if you have any issues with this.

This revision was landed with ongoing or failed builds.Aug 29 2023, 12:21 AM
This revision was automatically updated to reflect the committed changes.