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

Tue Nov 6 10:28:18 PST 2018

It seems relevant to point out there have been several efforts over the years to solve this problem by eliminating the static initializers in LLVM and migrate cl::opts to storing their values in a context object. One of those efforts was made by me back in 2014 (see https://reviews.llvm.org/D6207 <https://reviews.llvm.org/D6207>).

One of the perennial problems with cl::opt is that many of the values are declared in passes, and we rely on static initialization to register the options. My understanding is the new pass manager doesn't have pass registration, so that complicates how option initialization would work in a pass.

Personally I very much prefer the idea of having *Context objects be responsible for options rather than thread-local storage, but in order to not break how cl::opt works today we need an answer to the initialization story. Maybe per-library initialization? We already have that for most of our libraries.

-Chris

> On Oct 31, 2018, at 12:11 AM, Yevgeny Rouban via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> >>! In D53424#1273950 <tel:1273950>, @delcypher wrote:
> >>>! In D53424#1273737 <tel:1273737>, @yrouban wrote:
> >>>>! In D53424#1273728 <tel:1273728>, @jfb wrote:
> >>> Was there a commitment from the community, with some time horizon for moving away from this patch?
> …
> > While I agree that a transition away from global `cl::opt`s is going to be tough I think we need to get agreement from the community on some sort of plan before we land this. Otherwise we'll end up with this patch becoming a permanent part of LLVM's internal API which makes our technical debt even worse.
> > My suggestion would be to create a new RFC on llvm-dev that proposes a plan to move away from `cl::opt`s in LLVM's codebase (and probably other sub-projects). Given that you're looking at this issue you're probably in good position to discuss the technical problems with the available replacement APIs in LLVM's codebase.
>  
> I would not say that the patch https://reviews.llvm.org/D53424 <https://reviews.llvm.org/D53424> makes our technical debt worse. That is because it just allows us to set options per thread without almost any API change. Setting options locally (per thread, per pipeline, per LLVMContext, … etc.) is the one of the goal of the future changes you have in mind. When the future changes are ready it will not be difficult to start using them instead of D53424. At least it will be much easier than to implement the future changes themselves. Given that the future changes are just thoughts that need much effort and nobody has committed yet I would suggest that we accept the patch D53424. This can solve some problems.
>  
> From technical point of view I would say that the patch D53424 just slightly changes the angle of view on the cl::opts. They are still global options that should be changed only during the configuration stage. The only change proposed is the definition of the configuration stage - it used to be global and one for the while process, but now it can be done at different time for different threads.
>  
> Thanks.
> -Yevgeny Rouban
>  
> From: Yevgeny Rouban [mailto:yrouban at gmail.com <mailto:yrouban at gmail.com>] 
> Sent: Wednesday, October 31, 2018 12:47 PM
> To: llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>
> Cc: Yevgeny Rouban <yevgeny.rouban at azul.com <mailto:yevgeny.rouban at azul.com>>
> Subject: Re: [RFC] Enable thread specific cl::opt values for multi-threaded support
>  
> Here are copies of some key comments from the patch
>     https://reviews.llvm.org/D53424 <https://reviews.llvm.org/D53424> Enable thread specific cl::opt values for multi-threaded support
> So, please continue discussion here.
> _______________________________________________
> 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 <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/20181106/4d815e2f/attachment.html>