[llvm-dev] LLVM multithreading support

Eli Friedman via llvm-dev llvm-dev at lists.llvm.org
Sun Apr 12 15:56:25 PDT 2020


(reply inline)

From: Chris Lattner <clattner at nondot.org>
Sent: Sunday, April 12, 2020 3:28 PM
To: Eli Friedman <efriedma at quicinc.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [EXT] Re: [llvm-dev] LLVM multithreading support

On Apr 12, 2020, at 2:23 PM, Eli Friedman <efriedma at quicinc.com<mailto:efriedma at quicinc.com>> wrote:
So probably I’d recommend two things:

1.      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).

2.      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?

Yes, I would like to remove LLVM_ENABLE_THREADS. Assuming you’re not building for some exotic target that doesn’t have threads, there isn’t any reason to randomly shut off all thread-related functionality in the LLVM support libraries.  There isn’t any significant performance or codesize gain to be had outside of MLIR, as far as I know, and it increases the number of configurations we have to worry about.  I have no idea if turning it off even works on master; I don’t know of any buildbots or users using that configuration.

If you want to support some sort of lockless mode in MLIR, I think that burden should be carried as part of MLIR, instead of infecting the entire LLVM codebase.
-Eli
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200412/9a95d19c/attachment.html>


More information about the llvm-dev mailing list