[lld] r289084 - Move Memory.{h, cpp} to lld/Support so that we can use them from COFF.

[Chris Bieneman via llvm-commits]

Ideally eliminating static initializers from LLVM would be great. I tried to make progress on that a few years ago specifically focused on the command line options which are the vast majority of LLVM's static initializers.

There are some difficult challenges that have not been overcome specifically with how non-global options would interoperate with the new pass manager.

Getting rid of static initializers has the potential to significantly speed up process spin-up time for LLVM-based tools, and could result in a speedup of operations like "check".

-Chris

> On Dec 13, 2016, at 12:41 AM, Davide Italiano <davide at freebsd.org> wrote:
> 
> On Mon, Dec 12, 2016 at 10:38 PM, Chris Bieneman via llvm-commits
> <llvm-commits at lists.llvm.org <mailto:llvm-commits at lists.llvm.org>> wrote:
>> 
>> On Dec 12, 2016, at 9:41 PM, Sean Silva <chisophugis at gmail.com> wrote:
>> 
>> 
>> 
>> On Mon, Dec 12, 2016 at 10:46 AM, Chris Bieneman <beanz at apple.com> wrote:
>>> 
>>> Can we maybe wrap the globals from Memory.cpp either in a singleton
>>> pattern with access functions (preferred) or ManagedStatics?
>>> 
>>> Avoiding the static initialization cost is desirable for both libraries
>>> and tools.
>> 
>> 
>> I don't think a singleton pattern really helps here. The main issue is that
>> this is not something appropriate for an llvm-style "lib/" subdirectory
>> (whether you put a singleton pattern around it or not). It needs to be more
>> clearly part of COFF/ELF; I think Rui's suggestion of making this a
>> top-level directory alongside COFF and ELF is a good way to achieve that.
>> 
>> I don't really have an issue with static initializers in a "program".
>> 
>> 
>> I do. Static initializers slow down the launch of the program and using
>> singleton-style lazy initialization ensures that you only run the
>> initializers if you need them. Meaning you don't run all the static
>> initializers in the program just to print the help output. Sadly in LLVM we
>> run a boat load of static initializers just to print help in basically
>> everything LLVM derived.
>> 
> 
> I have a question (just curiosity). I can see your argument, I'm also
> a little sympathetic toward it.
> On the other hand, to play devil's advocate, is this something that
> matters in LLVM (on in a similar class of applications)? i.e. for
> small testcases it ends up being a dominant factor so if this gets
> fixed `ninja check-lld` gets faster?
> 
> -- 
> Davide
> 
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161213/69dba875/attachment.html>