[llvm-dev] [RFC] Enable thread specific cl::opt values for multi-threaded support (original) (raw)

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Fri Oct 19 09:45:58 PDT 2018

+Lang Hames <lhames at gmail.com> since he's playing with multithreaded compilation in the ORC JIT too.

My off-the-cuff thought (which is a lot of work, I realize) would be that cl::opts that aren't either in drivers (like opt.cpp, llc.cpp, etc) or developer options (dump-after-all, things like that) shouldn't be cl::opts and should be migrated to options structs and the like?

I realize that's a ton of work, and we all sort of cringe a little when we add another "backend option" (accessing cl::opts via -backend-option in the Clang driver when invoking clang cc1) & then do it anyway, etc... but would be pretty great to clean it up and have a clear line about what cl::opts are for.

(totally reasonable for you to push back and say "that's not the hill I want to die on today", etc - and see what everyone else thinks)

On Fri, Oct 19, 2018 at 3:58 AM Yevgeny Rouban via llvm-dev < llvm-dev at lists.llvm.org> wrote:

Hello LLVM Developers.

We at Azul Systems are working on a multi-threaded LLVM based compiler. It can run several compilations each of which compiles its own module in its own thread. One of the limitation we face is that all threads use the same options (instances of cl::opt). In other words, the options are global and cannot be changed for one thread and left unchanged for the others. One solution I propose in the patch https://reviews.llvm.org/D53424 Enable thread specific cl::opt values for multi-threaded support As the change affects many source files (though slightly) I decided to share it with wider audience. Any less intrusive solution is welcome. Here is the patch description for your convenience: === When several threads compile different modules the compiler options (instances of cl::opt) cannot be set individually for each thread. That is because the options are visible to all threads. In other words all options are global. It would be convenient if the options were specific to LLVMContext and they were accessed through an instance of LLVMContext. This kind of change would need changes in all source files where options are used. This patch proposes a solution that needs minimal changes in LLVM source base. It is proposed to have a thread local set of re-defined option values mapped by pointers to options. Specifically, every time a program gets/sets a value for an option it is checked if the current thread local context is set for the current thread and the option has its local copy in this context. If so the local copy of the option is accessed, otherwise the global option is accessed. For all programs that existed so far the context is not set and they work with the global options. For new multi-threaded compilers (where every thread compiles its own module) every thread can be linked to its own context (see ContextValues) where any option can have its thread specific value that do not affect the other threads' option values. See the threadroutine() in the test ContextSpecificValues2. This feature allows a configuration flexibility for multi-threaded compilers that can compile every compilation unit in its own thread with different command line options. === Thanks. -Yevgeny Rouban

LLVM Developers mailing list llvm-dev at lists.llvm.org http://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/20181019/43d3d4d6/attachment.html>

More information about the llvm-dev mailing list