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

[Nicolai Hähnle via llvm-dev]

On 22.10.18 16:14, Yevgeny Rouban wrote:
> On Sat, Oct 20, 2018 at 5:08 PM Nicolai Hähnle via llvm-dev 
> <llvm-dev at lists.llvm.org> wrote:
> 
>     Hi Yevgeny,
> 
>     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.)
> 
> Yes, but the global context has no effect on your thread only for those 
> options that have been changed in this thread's context.
> That is because a thread local copy of an option is created in the 
> current thread context when this option is set by this thread or another 
> thread with the same option context. If the option has not been set then 
> its global value is used.
> For your case, I would suggest that you explicitly set a new thread 
> option context for every thread (or thread group) that uses LLVM. This 
> way the threads/groups will not affect each other and will use the 
> options in the copy-on-write way.

That's not quite what we'd need, and we can't control all threads -- 
Mesa is a library, and so we can't control what other threads are doing.

That said, it may be possible to add what we need on top of what you're 
proposing without too much effort. Basically, we'd need the 
ThreadOptionContext to be optionally "opaque" in the sense of hiding 
global options.

Do you actually need the ThreadOptionContext to be "transparent" for 
your use case, or is that just an accidental consequence of the current 
implementation?

Cheers,
Nicolai

> May be it makes sense to try playing with the tests in the patch to 
> better understand the use model.
> 
> Thanks.
> -Yevgeny Rouban
> 


-- 
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.