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

[Davide Italiano via llvm-commits]

On Mon, Dec 12, 2016 at 10:38 PM, Chris Bieneman via llvm-commits
<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