[llvm-dev] LLVM multithreading support

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Tue Apr 14 16:34:45 PDT 2020

My only input on this is that, if we do add this back, threading should be
enabled by default, and then apps can disable it if they know it is safe to
do so.

As Eli mentioned, C++11 threading primitives have proliferated in LLVM, and
I would hesitate to add wrappers for them all. Either way I don't feel
super strongly about it.

On Sat, Apr 11, 2020, 5:15 PM Chris Lattner <clattner at nondot.org> wrote:

> 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/20200414/9f32de7a/attachment.html>

More information about the llvm-dev mailing list