similar to: [LLVMdev] [RFC] Internal command line options should not be statically initialized.

Wait, I have a terrible idea. Why don't we roll our own .init_array style appending section? I think we can make this work for all toolchains we support. We'd have something like: struct PODOptData { const char *FlagName; ... // Common POD stuff, can be initialized at ParseCommandLine time. }; LLVM_SECTION(".llvmopt") PODOptData OptionRegisterer = { "foo_flag",

On Sep 17, 2013, at 10:31 AM, Eric Christopher <echristo at gmail.com> wrote: > Hi Andy, > > I definitely agree with the desire to remove command line options and > having them be initialized as part of the pass would be general > goodness. However, a few possible issues: > > a) a number of command line options aren't really connected to passes > per-se

>> I definitely agree with the desire to remove command line options and >> having them be initialized as part of the pass would be general >> goodness. However, a few possible issues: >> >> a) a number of command line options aren't really connected to passes >> per-se (backend options) > > We don’t have to ban the old-style options. They can live-on

Hi Andy, I definitely agree with the desire to remove command line options and having them be initialized as part of the pass would be general goodness. However, a few possible issues: a) a number of command line options aren't really connected to passes per-se (backend options) b) "As long as pass initialization happens before parseCommandLine, usage should be consistent." I'm

Isnt all the command line options only relevant to the driver, so if all the command line options are migrated to the driver, the library will be free from static initializers. Doesnt this make it more cleaner ? Thanks Shankar Easwaran On 9/17/2013 12:10 PM, Andrew Trick wrote: > LLVM's internal command line library needs to evolve. We have an immediate need to build LLVM as a library

----- Original Message ----- > LLVM's internal command line library needs to evolve. We have an > immediate need to build LLVM as a library free of static > initializers, but before brute-force fixing this problem, I'd like > outline the incremental steps that will lead to a desirable long > term solution. We want infrastructure in place to provide an > evolutionary path.

On Sep 17, 2013, at 11:25 AM, Shankar Easwaran <shankare at codeaurora.org> wrote: > Isnt all the command line options only relevant to the driver, so if all the command line options are migrated to the driver, the library will be free from static initializers. > > Doesnt this make it more cleaner ? Yes, but less convenient for developing experimental passes. I think we want to

Hey Andy > One easy pattern to follow is to register the option during pass initialization with all the convenient flags and parameters, but refer to a globally defined option storage that enforces the singleton and provides visibility. As long as pass initialization happens before parseCommandLine, usage should be consistent. > > Strawman: > > cl::optval<bool> MyOption; //

On Tue, Sep 17, 2013 at 11:29 AM, Reid Kleckner <rnk at google.com> wrote: > Wait, I have a terrible idea. Why don't we roll our own .init_array style > appending section? I think we can make this work for all toolchains we > support. > Andy and I talked about this, but I don't think its worth it. My opinion is: 1. For tool options (the top-level llc, opt, llvm-as

Hi , Regarding my previous help on LLVM Instrumentation , gdb helped me out. Your docs on Writing an LLVM Pass - Using gdb with dynamically loaded passes was very useful. I've done some instrumentation and collected profiles during runtime using library routines in a separate pass with opt tool. I used : In the tools/lli/Makefile , I included the following line TOOLLINKOPTS :=

On Sep 17, 2013, at 10:10 AM, Andrew Trick <atrick at apple.com> wrote: > LLVM's internal command line library needs to evolve. We have an immediate need to build LLVM as a library free of static initializers, but before brute-force fixing this problem, I'd like outline the incremental steps that will lead to a desirable long term solution. We want infrastructure in place to

Is it possible for a pass to get access to the command line options passed to it? That is, if I use the CommandLine library to define cl::opt<int> Foo("foo", ...); cl::opt<int> Bar("bar", ...); cl::opt<bool> Baz("baz", ...); and the user runs "opt -load mypass.so -foo=123 -std-compile-opts -baz", can I somehow get a string

On Sep 18, 2013, at 8:58 AM, Chris Lattner <clattner at apple.com> wrote: > On Sep 17, 2013, at 10:10 AM, Andrew Trick <atrick at apple.com> wrote: >> LLVM's internal command line library needs to evolve. We have an immediate need to build LLVM as a library free of static initializers, but before brute-force fixing this problem, I'd like outline the incremental steps

> On Dec 13, 2016, at 3:23 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Dec 13, 2016, at 1:22 PM, Matthias Braun via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> >>> On Dec 13, 2016, at 12:56 PM, Reid Kleckner <rnk at google.com> wrote: >>> >>> Given that LLVM has so many auto-registration systems

As I wrote the trick here is sneak the initGlobals() into the places where we do pass registration which should get you a big part of the way. For the remaining cases you have to add a few functions and call them from init() like functions which we have all over llvm anyway because of pass registration. - Matthias > On Dec 13, 2016, at 3:46 PM, Mehdi Amini <mehdi.amini at apple.com>

On Wed, Sep 18, 2013 at 9:06 PM, Andrew Trick <atrick at apple.com> wrote: > > On Sep 18, 2013, at 8:58 AM, Chris Lattner <clattner at apple.com> wrote: > > On Sep 17, 2013, at 10:10 AM, Andrew Trick <atrick at apple.com> wrote: > > LLVM's internal command line library needs to evolve. We have an immediate > need to build LLVM as a library free of static

CommandFlags.inc is only included by llc and opt. I think it mostly just sets things on TargetMachine and TargetOptions and connects them to command line options. Clang has its own code for setting up TargetMachine and TargetOptions. I think a lot of configuration things these days tend to be done with function attributes in IR. You can just query the function attribute wherever without any need

Thank you all for your suggestions! @David, thanks for the advice, I'll check MCOptions again and look into LLVMContext. @Craig, @Aaron, great suggestion, moving the option away from CommandFlags.inc to a more appropriate file and adding an extern declaration to the corresponding header gives me more flexibility and allows me to invoke the option by using -mllvm. From my current

But it is more work: My strawman proposal only needs a very mechanical change of adding one xxx.init(); line for each global. Putting the variables into context classes is more involved: You have to actually decide on the appropriate context class for each of them and you will face lots of small helper functions outside of classes that simply have no appropriate context at hand. - Matthias >

I don’t believe it is any more work (except the registry infrastructure) to do than you strawman proposal. > On Dec 13, 2016, at 3:36 PM, Matthias Braun <mbraun at apple.com> wrote: > > I don't agree with an ideological "burn and remove all the globals" stance. For one thing that means heavy rewriting (we would need to move all the Statistic variable into classes