[PATCH] D53424: Enable thread specific cl::opt values for multi-threaded support

JF Bastien via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 22 10:09:14 PDT 2018


jfb added a comment.

In https://reviews.llvm.org/D53424#1270456, @nhaehnle wrote:

> In https://reviews.llvm.org/D53424#1270322, @MatzeB wrote:
>
> > Can you explain what you would use per-thread command line options for?
> >  Intuitively I would not expect actual commandline users wanting to set options per thread. If you need it to tweak compiler behavior then it might be better to find ways to encode the information in `TargetOptions.h`, function attributes or similar, so we have a streamlined way of setting them independently of programmatically modifying commandline options.
>
>
> It's about proper encapsulation of state.
>
> There are use cases where there are multiple components using LLVM in the same process for different purposes, and we should really be able to properly isolate those purposes. The use case that I care about is Mesa, where one of the users is an OpenGL driver (using LLVM as a shader compiler backend) which may be loaded into an application that uses LLVM for something else as well.


The outcome you wants seems highly desirable. The method (thread local storage) doesn't seem desirable when `LLVMContext` could be used for this. It seems you've collected a list of `cl::opt` values which really shouldn't be per-process when using LLVM as a library. How about making that happen instead?


Repository:
  rL LLVM

https://reviews.llvm.org/D53424





More information about the llvm-commits mailing list