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

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) {

apply(this, Ms...);

}

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