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

[Yevgeny Rouban via llvm-dev]

Hello Neil.

Out of the solutions mentioned in the comments
https://reviews.llvm.org/D5389 by beanz
https://reviews.llvm.org/D53424#1273950 by delcypher
https://reviews.llvm.org/D53424 by yrouban

none has got future community agreement on further development.

https://reviews.llvm.org/D53424 seems to be simple and gives a new use model (thread specific redefinition) for all existing cl::opts. This scares those who have another development direction in mind, because such new use model will have to be handled in future. In other words, this *increases technical debt*.
On the other hand I see the other ideas to be hardly applicable to all cl::opts at once: they have to be changed for every single cl::opt and it could not be done automatically or with a script.

It seems we stack but I agree with you, we need something to go further.

Thanks.
-Yevgeny Rouban

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Neil Henning via llvm-dev
Sent: Thursday, December 13, 2018 6:07 PM
To: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] [RFC] Enable thread specific cl::opt values for multi-threaded support


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<mailto: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/20181217/7f4ed373/attachment.html>