similar to: Enabling statistics in release builds / static constructors

Given that LLVM has so many auto-registration systems (cl::opt, target registry, pass registry, statistics, I'm sure there's more), maybe we should spend the time to build an auto-registration system that doesn't involve static constructors? It needs custom code for every supported object file format, and is hard to get right when DSOs are involved, but in the long run it's

> On Dec 13, 2016, at 12:56 PM, Reid Kleckner <rnk at google.com> wrote: > > Given that LLVM has so many auto-registration systems (cl::opt, target registry, pass registry, statistics, I'm sure there's more), maybe we should spend the time to build an auto-registration system that doesn't involve static constructors? I would volunteer to do the work, however this

> On Dec 13, 2016, at 3:28 PM, Matthias Braun <mbraun at apple.com> wrote: > >> >> On Dec 13, 2016, at 3:27 PM, Matthias Braun <mbraun at apple.com <mailto:mbraun at apple.com>> wrote: >> >>> >>> On Dec 13, 2016, at 3:23 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote: >>>

The intention with cl::opt was to use the singleton as a transitionary measure only. The end goal was to move option storage into the {MC|LLVM}Context. -Chris > On Dec 13, 2016, at 3:32 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > >> >> On Dec 13, 2016, at 3:28 PM, Matthias Braun <mbraun at apple.com <mailto:mbraun at apple.com>> wrote: >>

> On Dec 13, 2016, at 3:27 PM, Matthias Braun <mbraun at apple.com> wrote: > >> >> On Dec 13, 2016, at 3:23 PM, Mehdi Amini <mehdi.amini at apple.com <mailto: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 <mailto:llvm-dev at lists.llvm.org>>

> 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 (cl::opt, target registry, pass registry, statistics, I'm sure there's more), maybe we should spend the time to build

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 somewhere, pass around way more contexts). I am NOT volunteering for that part of work. - Matthias > On Dec 13, 2016, at 3:34 PM, Chris Bieneman <beanz at apple.com> wrote: > > The

> 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

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

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 >

Well for one you’re snippet includes a `static void init_globals() {` which definitely can be “static” and it is quite unclear to me how you’re gonna trigger the registration for it. > On Dec 13, 2016, at 3:43 PM, Matthias Braun <mbraun at apple.com> wrote: > > But it is more work: My strawman proposal only needs a very mechanical change of adding one xxx.init(); line for each

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>

That is as easy or hard to track like pass registration. All of that mostly happens when llvm starts up and the user calls all these functions like initializeCore(), intiaizlieCodeGen(), initializeAllTargets(), and all the other existing init functions. Also noticing missing init errors is obvious and fixing them trivial. - Matthias > On Dec 13, 2016, at 3:51 PM, Mehdi Amini <mehdi.amini

These type of constructs are less than ideal if you have something that uses LLVM as a library in a "long running" application (e.g. imagine something like photo editor that compiles "filters", and a user that loads the application on monday, and closes it on the following thursday) , as there is no (trivial) way to know that this stringmap exists, or that it may need cleaning

Hi all, Is there way to tell the ORC JIT infrastructure to run the static constructors in a module that has just been compiled? I see that the ExecutionEngine class has a runStaticConstructorsDestructors function, is that relevant with ORC and if so, how should it be accessed? Thanks, Daniele -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 10/8/10 3:44 PM, Owen Anderson wrote: > [snip] > >> Hrm. I see. >> >> I still don't like the idea of having every statically-linked tool explicitly initializing every library that gets linked in. Just dumping the library into the Makefile and being done with it was much nicer. >> >> If you can find a reasonable way to support that, it would be nice.

Thank you Alex, I went and implemented a solution along those lines. It works well. It may be worth mentioning static constructors in the Kaleidoscope tutorial. Cheers, Daniele ________________________________________ From: Alex Denisov [1101.debian at gmail.com] Sent: 15 March 2019 08:07 To: Daniele Vettorel Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Static constructors with ORC

Hi, I'm new here and have a question about the rule in title. Is the following use case also prohibited? int findNameId(StringRef Name) { static StringMap<int> Map = createSomeIDMap(); return Map.lookup(Name); }; It seems it isn't influence startup time and doesn't create initialization order problems. Clang isn't complaining about it with -Wglobal-constructor flag.

On Oct 8, 2010, at 1:37 PM, John Criswell wrote: > On 10/8/10 3:15 PM, Owen Anderson wrote: >> >> On Oct 8, 2010, at 1:05 PM, John Criswell wrote: >> >>> On 10/8/10 1:29 PM, Owen Anderson wrote: >>>> Hello fellow LLVM-ers, >>>> >>>> As those of you who follow llvm-commits have probably noticed, I've been hard at work

On 10/8/10 3:15 PM, Owen Anderson wrote: > > On Oct 8, 2010, at 1:05 PM, John Criswell wrote: > >> On 10/8/10 1:29 PM, Owen Anderson wrote: >>> Hello fellow LLVM-ers, >>> >>> As those of you who follow llvm-commits have probably noticed, I've >>> been hard at work reworking our pass infrastructure to perform pass >>>