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

Rafael EspĂ­ndola rafael.espindola at gmail.com
Mon Jun 18 13:15:05 PDT 2012


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.

> -cary

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm.patch
Type: application/octet-stream
Size: 11843 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120618/884aa58d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang.patch
Type: application/octet-stream
Size: 7336 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120618/884aa58d/attachment-0001.obj>


More information about the llvm-commits mailing list