[llvm-dev] [RFC] Enable thread specific cl::opt values for multi-threaded support (original) (raw)
Nicolai Hähnle via llvm-dev llvm-dev at lists.llvm.org
Sat Oct 20 03:08:02 PDT 2018
- Previous message: [llvm-dev] [RFC] Enable thread specific cl::opt values for multi-threaded support
- Next message: [llvm-dev] [RFC] Enable thread specific cl::opt values for multi-threaded support
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Yevgeny,
This would be a very welcome feature for Mesa as well, thank you for doing this!
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. That seems very sensible and pragmatic to me.
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.
Just to make sure I'm understanding this correctly: When a thread has a non-null option context, then options set in the global context will have no effect at all for that thread. Right? (That's what I would expect and what makes sense to me.)
Cheers, Nicolai
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
-- Lerne, wie die Welt wirklich ist, Aber vergiss niemals, wie sie sein sollte.
- Previous message: [llvm-dev] [RFC] Enable thread specific cl::opt values for multi-threaded support
- Next message: [llvm-dev] [RFC] Enable thread specific cl::opt values for multi-threaded support
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]