<p dir="ltr">On Sep 11, 2015 4:23 AM, "Evgeny Astigeevich via cfe-commits" <<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>> wrote:<br>
><br>
> eastig added a comment.<br>
><br>
> In <a href="http://reviews.llvm.org/D12689#243592">http://reviews.llvm.org/D12689#243592</a>, @rsmith wrote:<br>
><br>
> > Can we instead fix this in Clang by ensuring that libc++ is put at the right position in the static link order so that its initializers run first? libc++'s avoidance of running iostreams init code from every translation unit is a significant startup performance feature, and we shouldn't abandon it unless we really have to.<br>
><br>
><br>
> Let me give more details about the problem we have.<br>
><br>
> Clang generates a `__cxx_global_var_init<X>` function for each global variable that needs to be set-up (initialized) before firing the main routine of the user program. Those initializer functions are then grouped under a parent initializer function named after the corresponding translation unit: `_GLOBAL__sub_I_<translation_unit>`.  Those `_GLOBAL__sub_I_<translation_unit>` entries then get stuffed into the `.init_array` tables of individual object files.<br>
><br>
> In ARM compiler toolchains `armlink` is used for linking, not `GNU ld`. `libc++` is a part of the toolchain static system libraries. So `armlink` logic should be updated to change the order in which the `.init_array` entries from system libraries are added to the final image's `.init_array` table. This can be a problem because of an assumption that there are no dependencies among initializers from different translation units.<br>
><br>
> IMHO if the programming language has a means of resolving such problems it's better to use it instead of hacking a linker.<br>
><br>
> About impact on startup performance, I don't see why it will be significant. Initialization is done once. Other times it is simply a call to increase a counter. To be significant there should be millions of calls.</p>
<p dir="ltr">Short-lived programs can spend significant amounts of their runtime in initialization. There is also a binary size cost.</p>
<p dir="ltr">> Why does `gnu libc++` use a similar way if it hurts performance?</p>
<p dir="ltr">I'm sure they would prefer not to.</p>
<p dir="ltr">> In the patch the `__APPLE__` macro is used to have the old behaviour. Maybe instead of it another macro, e.g. `__STATIC_BUILD__`, can be use when we want to build a static library.<br>
><br>
><br>
> <a href="http://reviews.llvm.org/D12689">http://reviews.llvm.org/D12689</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> cfe-commits mailing list<br>
> <a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits</a><br>
</p>