search for: optionregistry

...arizer pass to scalarize loads and store")); This poses a problem for clients of LLVM that aren’t traditional compilers (i.e. WebKit, and Mesa). My proposal is to take a phased approach at addressing this issue. The first phase is to move the ownership of command line options to a singleton, OptionRegistry. The OptionRegistry can be made to work with the existing global command line definitions so that the changes to migrate options can be done in small batches. The primary purpose of this change is to move the ownership of the command line options out of the global scope, and to provide a vehicle fo...

...;> This poses a problem for clients of LLVM that aren’t traditional compilers >> (i.e. WebKit, and Mesa). My proposal is to take a phased approach at >> addressing this issue. >> >> The first phase is to move the ownership of command line options to a >> singleton, OptionRegistry. The OptionRegistry can be made to work with the >> existing global command line definitions so that the changes to migrate >> options can be done in small batches. The primary purpose of this change is >> to move the ownership of the command line options out of the global scope,...

...want to expose to users and the ones which we use for >>>>>> testing llvm itself. The options we want to expose should be just >>>>>> constructor arguments. With that distinction we should be able to just >>>>>> not use the options added by cl::OptionRegistry::CreateOption unless >>>>>> cl::ParseCommandLineOptions is called. WebKit like clients would just >>>>>> not call cl::ParseCommandLineOptions. Would that work? >>>>>> >>>>>> >>>>>> This is actually how some...

...ifferent types of options. >> The ones we want to expose to users and the ones which we use for >> testing llvm itself. The options we want to expose should be just >> constructor arguments. With that distinction we should be able to just >> not use the options added by cl::OptionRegistry::CreateOption unless >> cl::ParseCommandLineOptions is called. WebKit like clients would just >> not call cl::ParseCommandLineOptions. Would that work? >> >> >> This is actually how some of our internal clients are already working. There >> are a few caveats wi...

> On Aug 19, 2014, at 1:32 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > >>> * Nobs for which there is not a single right answer for all users. >>> There are very few of these currently and we expect it to remain like >>> that. These should not use cl::opt or static storage at all. They >>> should be an option passed to the

...gt;>> The ones we want to expose to users and the ones which we use for >>>> testing llvm itself. The options we want to expose should be just >>>> constructor arguments. With that distinction we should be able to just >>>> not use the options added by cl::OptionRegistry::CreateOption unless >>>> cl::ParseCommandLineOptions is called. WebKit like clients would just >>>> not call cl::ParseCommandLineOptions. Would that work? >>>> >>>> >>>> This is actually how some of our internal clients are already work...

...9;t have to understand > options in order to pass them on to the backend. > > The static variables should be straightforward to migrate to an LLVMContext > once ParseCommandLineOptions stores things there instead of in globals. I also think that the OptionStore in conjunction with the OptionRegistry (rather than any of the cl APIs) should have all the parsing code. In fact, you shouldn’t have to call ParseCommandLineOptions, we could make encoding and decoding the stored options associated with a module part of loading and storing the module. > >> diff --git a/lib/CodeGen/CodeGenOpt...

...re when there's no > reason for the opt or the storage to be global. > > We frown upon the use of globals, otherwise LLVM would be littered with them > like many other C++ code bases. I don't think cl::opts should be special at > all in this respect. Note that the call cl::OptionRegistry::CreateOption<bool>(&ScalarizeLoadStore, "ScalarizeLoadStore", "scalarize-load-store", cl::Hidden, cl::init(false), cl::desc("Allow the scalarizer pass to scalarize loads and store")); ScalarizeLoadStore can actually be a member variable as long as cal...

...opt or the storage to be global. > > > > We frown upon the use of globals, otherwise LLVM would be littered with them > > like many other C++ code bases. I don't think cl::opts should be special at > > all in this respect. > > > Note that the call > > cl::OptionRegistry::CreateOption<bool>(&ScalarizeLoadStore, > "ScalarizeLoadStore", > "scalarize-load-store", cl::Hidden, cl::init(false), > cl::desc("Allow the scalarizer pass to scalarize loads and store")); > > ScalarizeLoadStore can actually be a member...

...gt; > > > We frown upon the use of globals, otherwise LLVM would be littered with them > > > like many other C++ code bases. I don't think cl::opts should be special at > > > all in this respect. > > > > > > Note that the call > > > > cl::OptionRegistry::CreateOption<bool>(&ScalarizeLoadStore, > > "ScalarizeLoadStore", > > "scalarize-load-store", cl::Hidden, cl::init(false), > > cl::desc("Allow the scalarizer pass to scalarize loads and store")); > > > > ScalarizeLoadStore...

...e the cl::opt structures owned and eliminate global option storage. > > For now, please eliminate only the static constructor and leave the > storage. Since it seems only a few options that need to be exposed by > non-command line APIs, we might be able to avoid the need for a > cl::OptionRegistry::GetValue. I strongly feel this is the wrong decision. If you have a single process using two LLVM clients (say WebKit and Mesa), and they both are using an opt pass with different settings. If the storage is global this will not work. > >> I’d >> also like to add to it that when...

...e use of globals, otherwise LLVM would be littered with them > > > > like many other C++ code bases. I don't think cl::opts should be special at > > > > all in this respect. > > > > > > > > > Note that the call > > > > > > cl::OptionRegistry::CreateOption<bool>(&ScalarizeLoadStore, > > > "ScalarizeLoadStore", > > > "scalarize-load-store", cl::Hidden, cl::init(false), > > > cl::desc("Allow the scalarizer pass to scalarize loads and store")); > > > > &gt...

I'm working on fixing PR21471, which is about embedding codegen command line options into the bitcode as function or module-level attributes so that they don't get ignored when doing LTO. http://llvm.org/bugs/show_bug.cgi?id=21471 I have an initial patch (attached to this email) which enables clang/llvm to recognize one command line option, write it to the IR, and read it out in a