[llvm-dev] LLVM multithreading support

[Eli Friedman via llvm-dev]

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.

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.

-Eli


From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Chris Lattner via llvm-dev
Sent: Saturday, April 11, 2020 5:16 PM
To: LLVM Developers' List <llvm-dev at lists.llvm.org>
Subject: [EXT] [llvm-dev] LLVM multithreading support

Hi all,

I was looking at the profile for a tool I’m working on, and noticed that it is spending 10% of its time doing locking related stuff.  The structure of the tool is that it reading in a ton of stuff (e.g. one moderate example I’m working with is 40M of input) into MLIR, then uses its multithreaded pass manager to do transformations.

As it happens, the structure of this is that the parsing pass is single threaded, because it is parsing through a linear file (the parser is simple and fast, so this is bound by IR construction).  This means that none of the locking during IR construction is useful.

Historically, LLVM had a design where you could dynamically enable and disable multithreading support in a tool, which would be perfect for this use case, but it got removed by this patch<https://github.com/llvm/llvm-project/commit/9c9710eaf4c1f01b8b518bdba89aba059ab14175#diff-bb772a7e6d4ebf2b46c6d42c95f40ddf>: (xref https://reviews.llvm.org/D4216).  The rationale in the patch doesn’t make sense to me - this mode had nothing to do with the old LLVM global lock, this had to do with whether llvm::llvm_is_multithreaded() returned true or false … which all the locking stuff is guarded on.

Would it make sense to re-enable this, or am I missing something?

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