Thanks!

rebase

added additional tests

rename variables per suggestion

thanks!

consolidate exclude/included patterns set into one

hi, friendly 🔔 :)

undo formatting changes

add tests for interaction with -exported_symbol

more tests

In D125732#3517791, @thakis wrote:

Linker behavior, including error output order, should be deterministic. (This allows caching results etc)

Oh I see - the test is bad because it was expecting the error messages to be in a particular order. (it shouldn't because the export symbol list is processed concurrentlly)

Seemed to fail on windows bot:

Thanks!

rebase

updated diff:

• addressed review comment
• trimmed error msg

nop update to test arc diff

In D122922#3469516, @MaskRay wrote:

I have a chrome build on Linux x86-64. Say /tmp/c/0 has a lld built from main branch. /tmp/c/1 is a lld built with this patch.

In D122922#3467647, @aganea wrote:

Right, but if the MachO part of lld does allocations from multiple threads, then it's essentially unreliable unless this option is enabled? So anyone building lld wanting to use the MachO part of it would need to enable it.

This question was left unanswered -- how do you plan on using LLD_THREAD_SAFE_MEMORY? Will it be enabled only when building for Darwin? What happens for cross-compilation or if LLD_THREAD_SAFE_MEMORY isn't enabled? The make/makePerThread/makeUnsafe APIs seem a bit error-prone to me. Ideally it is a choice that should be avoided, if possible, by the business logic/driver developer.

LG thanks!

! In D122922#3446376, @mstorsjo wrote:

Can someone summarize the high level roadmap of this feature? If threadsafe allocation is going to be optional/opt-in, lld can't generally rely on that, right? Or is it meant as a gradual way of merging the code and trying it out, and after it's ready to be enabled unconditionally, it can be relied upon in lld in general?

reverted threadtag back native TLS

put back differet make/saver options:

In D122922#3444540, @MaskRay wrote:

In the LLD_THREAD_SAFE_MEMORY code path, make<Foo>(...) now has significantly larger overhead due to the pthread_getspecific call (via llvm/Support/ThreadLocal.h).
A large number of make<...> instantiations in lld do not benefit from per-thread allocation.

removed the unneeded helpers and define the cmake option for LLD_THREAD_SAFE_MEMORY

rebase before submitting

LG , except the duplicate structs but then I don't have a better suggestion /shrug

In D122922#3436866, @int3 wrote:

We did experimented with using a modern/threadsafe allocator here, specifically tcmalloc internally at google and found that it was pretty good (ie., no slower than the bump-ptr alloc). But conceptually the bump-alloc could be faster in simple cases so we thought it wouldn't hurt to use both when possible. (ie., have a thread safe bump allocator and a fast system malloc).

IIRC you found that tcmalloc-for-everything was at parity with bump ptr alloc + system allocator, but bump ptr allocator + tcmalloc together was still faster than tcmalloc-for-everything, right?

Addressed review comments:

• Use llvm::sys::ThreadLocal instead of native thread_local (potential concern: the pthread_*() functions it uses might be a bit slower?)
• Rename macro to LLD_THREAD_SAFE_MEMORY

LG

In D122922#3436091, @aganea wrote:

Hello! Thanks for adding me :-) Interesting challenge!
It's a bit sad that we have to do all this high-level/application-level memory management. Most modern allocators already support (lock-free) per-thread memory pools out-of-the-box, along with migration between threads and to the global pool/arena. This patch seems to be needed solely because we use BumpPtrAllocator/SpecificBumpPtrAllocator. I wonder how things would perform with just using malloc() instead + a modern underlying allocator (rpmalloc, mimalloc, ...). Memory locality brought by the bumpalloc is important, but it'd be interesting to compare benchmarks. FWIW there were discussions with @lattner at some point about integrating rpmalloc into the LLVM codebase, but I never got to post a RFC.

thx!

thanks!

rebase

addressed review comments

updated diff

updated diff

fixed windows failures

use thread_local, which is more portable than __thread

keep an atomic incr to avoid locking

remoevd unused includes and rename make() func

abandoning in favour of D122922

squashed

rebase

The crash is fixed forward in https://reviews.llvm.org/rGe6e5e3e025ec1ccb8ebaff6ce4d6212edc491602

rebase