search for: scalarizeloadstore

Today command line arguments in LLVM are global variables. An example argument from Scalarizer.cpp is: static cl::opt<bool> ScalarizeLoadStore ("scalarize-load-store", cl::Hidden, cl::init(false), cl::desc("Allow the scalarizer 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 addres...

...om> wrote: > > On 18 August 2014 14:49, Chris Bieneman <beanz at apple.com <mailto:beanz at apple.com>> wrote: >> Today command line arguments in LLVM are global variables. An example >> argument from Scalarizer.cpp is: >> >> static cl::opt<bool> ScalarizeLoadStore >> ("scalarize-load-store", cl::Hidden, cl::init(false), >> cl::desc("Allow the scalarizer pass to scalarize loads and store")); >> >> >> This poses a problem for clients of LLVM that aren’t traditional compilers >> (i.e. WebKit, and Mesa...

...>> paying for something it will never use. >> >> What about when we're debugging the WebKit JIT? For development of libraries using LLVM it would be nice to be able to toggle these values too, which is why Filip’s suggestion of an API like LLVMConfigSetBoolValue(Config, "ScalarizeLoadStore", 1) would be nice. > > Most llvm bugs reproduce with just opt or llc, but if that is not the > case, cl::ParseCommandLineOptions when debugging seems fine. There are two reasons this doesn’t work: (1) Cases where I might want to set a debug variable for the WebKit JIT but not for...

...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 caller guarantees it is still around when the command...

...t; > 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 caller > guarantees it is...

...obals, 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 call...

...herwise the client is > paying for something it will never use. What about when we're debugging the WebKit JIT? For development of libraries using LLVM it would be nice to be able to toggle these values too, which is why Filip’s suggestion of an API like LLVMConfigSetBoolValue(Config, "ScalarizeLoadStore", 1) would be nice. -Chris > > Cheers, > Rafael

...ered 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...

> On Aug 19, 2014, at 11:09 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > > On 19 August 2014 13:47, Chris Bieneman <beanz at apple.com> wrote: >> I’d like to propose moving forward with the first phase of my proposal to >> make the cl::opt structures owned and eliminate global option storage. > > For now, please eliminate only the static