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

[Neil Henning via llvm-dev]

Hey all,

Trying to revive the RFC thread here - we have a need for this 
functionality (or some similar mechanism that lets us have a per-thread 
or per-context setting for options).

Is there any scope for getting something in that enables our (AMD's) 
graphics drivers and Azul to make use of it, in the short term, even if 
it's not the perfect solution that everyone desires?

Cheers,

-Neil.

On 08/11/2018 07:50, Yevgeny Rouban via llvm-dev wrote:
> Hello Chris.
>
> > One of the perennial problems with cl::opt is that ...
> My RFC does not change the way the options are initialized and 
> registered. So the static initialization problem is not made worse by 
> this RFC.
>
> > Personally I very much prefer the idea of having *Context objects be 
> responsible for options rather than thread-local storage ...
> This RFC defines a *Context* for options. In the patch the class is 
> called ContextValues. Essentially, it is similar to *Context objects*.
> With the RFC we will be able to make further changes for specific 
> options to get them from any specific Context, not only from the 
> thread local one. The thread local is proposed as the default context 
> to keep unchanged all places where cl::opts are accessed.
>
> If we have a flag:
> static cl::opt<bool> SomeFlag; // static global
>
> Flag access code looks like the following:
> if ( SomeFlag ) ... // global flag access
>
> With the RFC (thread specific cl::opt values) this code being 
> unchanged becomes equivalent to:
> if ( SomeFlag.getValue(cl::ContextValues::GetThreadOptionContext()) ) 
> ... // thread local flag access with fallback to global flag access
>
> Then we can manually change this source to:
> if ( SomeFlag.getValue(SomeSpecificContext) ) ... // context specific 
> flag access with fallback to thread local flag access
>
> In this example SomeSpecificContext can be specific to LLVMContext, 
> Pass, ...
>
> 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/20181213/b598899e/attachment.html>