[llvm-dev] LLVM multithreading support

[Chris Lattner via llvm-dev]

On Apr 12, 2020, at 2:23 PM, Eli Friedman <efriedma at quicinc.com> wrote:
> 
> Yes, the llvm::Smart* family of locks still exist.  But very few places are using them outside of MLIR; it’s more common to just use plain std::mutex.
>  
> That said, I don’t think it’s really a good idea to use them, even if they were fixed to work as designed.  It’s not composable: the boolean “enabled” bit is process-wide, not local to whatever data structure you’re trying to build.  So your single-threaded tool gets some benefit, but the benefit goes away as soon as the process starts using multiple threads, even if there still only one thread using the MLIR context in question.

Yes, I agree, this is similar to Mehdi’s point.  I think it is clear that “enable” and “disable” multithreaded mode should only be called from applications, not libraries.  Calling one of them from a library breaks composability.

> So probably I’d recommend two things:
> If locking uncontended locks is showing up on profiles as a performance bottleneck, it’s probably worth looking into ways to reduce that overhead in both single-threaded and multi-threaded contexts. (Reducing the number of locks taken in frequently called code, or using a better lock implementation).
> If you want some mechanism to disable MLIR locking, it should probably be a boolean attached to the MLIR context in question, not a global variable.
>  

Ok, but let me argue the other way.  We currently have a cmake flag that sets LLVM_ENABLE_THREADS, and that flag enables an across the board speedup.  That cmake flag is the *worst* possible thing for library composability. :-). Are you suggesting that we remove it?

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200412/1541072a/attachment.html>