This is an archive of the discontinued LLVM Phabricator instance.

[SelectionDAG] use <mutex> instead of LLVM home-grown primitive
AbandonedPublic

Authored by davide on Jun 20 2016, 10:41 AM.

Details

Summary

I hope to get rid of SmartMutex et similia in the short to medium term, now that C++ has a decent infrastructure for locking.
Some comments (on the patch):
!) SmartMutex by default allows recursion but I'm not entirely sure we need that here? Anyway, to keep the semantic equivalent to the existing code I switched to std::recursive_mutex.

  1. I'm not entirely sure if we want to guard the mutex code with #if defined(LLVM_ENABLE_THREADS) to make it a no-op in the single threaded case. I wasn't able to measure a substantial impact when benchmarking, but, that goes without saying, your mileage may vary and, of course, feedback welcome.

Diff Detail

Event Timeline

davide updated this revision to Diff 61265.Jun 20 2016, 10:41 AM
davide retitled this revision from to [SelectionDAG] use <mutex> instead of LLVM home-grown primitive.
davide updated this object.
davide added reviewers: bogner, resistor.
davide added a subscriber: llvm-commits.
rafael added a subscriber: rafael.

Gosh, this code is horrible.

It uses a global for a set of structs that include a pointer to a LLVM type. The type itself is not global, it is part of the LLVMContext.

So while this change is probably fine, how much harder would it be to avoid the lock completely by moving the guarded globals to LLVMContext? You might need to use a "void *CodeGenData" pointer to work around the library layering.

rnk edited edge metadata.Jun 30 2016, 8:22 AM

It's actually important for performance to compile out this mutex when threading is disabled. We do this in Chromium and apparently it matters.

If you implement Rafael's suggestion you can avoid the lock entirely.

davide abandoned this revision.Dec 14 2016, 8:56 PM