<div style="font-family: arial, helvetica, sans-serif"><font size="2"><div class="gmail_quote">On Mon, Jun 18, 2012 at 1:15 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 18 June 2012 14:58, Cary Coutant <<a href="mailto:ccoutant@google.com">ccoutant@google.com</a>> wrote:<br>

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