[llvm-dev] LLVM multithreading support

[River Riddle via llvm-dev]

On Sun, Apr 12, 2020 at 3:56 PM Eli Friedman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> (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> 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.
>

I agree here. It is going to be much easier, and likely saner, to have the
MLIR bits controlled by a flag in the MLIR context. Trying to stop/start
threading bits in utilities doesn't seem reliable given all of the
different factors, e.g. ThreadPool /llvm::parallel_for/etc. functionality.
It also provides a much more controlled interface/contract.

-- River


> -Eli
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200412/ba49bdee/attachment.html>