[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