[llvm-commits] [patch][rfc] How to handle static constructors on linux

[Chandler Carruth]

On Mon, Jun 18, 2012 at 1:15 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> On 18 June 2012 14:58, Cary Coutant <ccoutant at google.com> wrote:
> >> But I am still missing something, why is the performance so different?
> >> Code layout putting the constructors' body in the reverse order they
> >> are called?
> >
> > Yes, as I understand it. Cache and TLB prefetching works better when
> > code executes from lower to higher addresses than when executing from
> > higher to lower.
>
> OK, so I think the following items form a valid summary
>
> * The static linker should be able to reorder constructors in both
> .init_array and .ctors. That is not implemented and currently we get
> different orders. There is a proposal to reorder .init_array to match
> the .ctors order.
>
> * The static linker should be able to reorder bodies to match the
> order of .ctors or .init_array if the code is compiled with
> -ffunction-sections or a newer compiler that puts constructors in
> .text.startup. This is not implemented and currently using .init_array
> gives better performance.
>
> * Using .init_array centralizes all initialization handling and is the
> default in newer linux distros.
>
> Given the above, I think best option for clang is to use .init_array
> in systems where gcc does. This lets us keep using gcc's crt files,
> doesn't require a runtime check on the linker version and avoid
> surprising the user with different construction order from gcc. If
> --reverse-init-array (and layout improvements) are implemented, clang
> will also get the benefits.
>
> Assuming this is really the case, I have moved the gcc list and devs
> to bcc so they don't get spammed with llvm code reviews. Thanks for
> all the help!
>
> I have attached updated llvm and clang patches.


The Clang side looks fine, can't speak for the LLVM side though.

And yes, please document this somewhere... =/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120618/30143b35/attachment.html>