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

Yevgeny Rouban via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 23 19:26:21 PDT 2018


On Wed, Oct 24, 2018 at 3:27 AM Jacob Lifshay <programmerjake at gmail.com>
wrote:

>
> On Tue, Oct 23, 2018, 03:29 Yevgeny Rouban via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>>
>> If all threads were bound to a non-null context then there would be no
>> one which initialized the global options. This would result in unset
>> default values. That is why we need the very first thread (that is used to
>> load and initialize LLVM libraries) to have the ThreadOptionContext unset,
>> so the default option values get into the default option storage. Then, I
>> believe, it would be ok to force all threads to have non-null
>> ThreadOptionContexts. In other words we need to identify the library
>> loading thread and the initialization time period while the
>> ThreadOptionContext must be null.
>> These are just my thoughts. I have not tried this use model.
>>
> If the global options are not used because every thread has a
> ThreadOptionContext, wouldn't it work fine to leave the global values
> uninitialized since nothing is using them? They could be initialized on
> first use.
>

You are right, but on the first use where can the default values be found?
It seems I know how to force cl::opt initialization to be in the global
context: we have to explicitly set the ThreadOptionContext to nullptr at
the beginning of the the cl::opt constructor and restore it at the end -
this way all applicators are applied with null context that is the default.

  template <class... Mods>
  explicit opt(const Mods &... Ms)
      : Option(Optional, NotHidden), Parser(*this) {
*    auto SavedCtx = ContextValues::ThreadOptionContext;*
*    SetThreadOptionContex(nullptr);*
    apply(this, Ms...);

*    SetThreadOptionContex(SavedCtx); *    done();
  }

Thanks.
-Yevgeny Rouban
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20181024/36d72f18/attachment.html>


More information about the llvm-dev mailing list