<div dir="ltr">Thanks David. To be more specific with my question, two things I'd like to know are:<div><br></div><div>- Is there any significance in the naming <span style="font-size:12.8px">_GLOBAL__sub_I_ vs </span><span style="font-size:12.8px">__cxx_global_var_init or is this just an artefact of the way clang generates the code?</span></div><div><span style="font-size:12.8px">- Can I assume that the order the functions appear in @llvm.global_ctors is always the order that they should be called in (assuming there's actually any dependencies)?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This is significant to me as I'm performing manipulations on the IR to alter the static ctrs and then recompiling (you may shudder should you wish to do so :) ).</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 7, 2016 at 5:44 PM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 7 Jan 2016, at 09:36, Andrew Parker via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> I'd just like to understand what the logic is behind the generation of these functions. It looks to me like there's implicit constructor priority however the priority member of the @llvm.global_ctors array is never used (well, it's always 65535).<br>
><br>
> Does anyone know the secrets behind this?<br>
<br>
</span>It’s fairly simple.  Doing it this way makes it easy to emit the constructors one at a time (the ctors array is an appending global, but it’s still immutable after creation - you can’t add fields to it) and lets the inliner condense the constructors into a single function where appropriate (and allows the same code to be used to generate the static constructor initialisation paths as global initialisation).<br>
<br>
The inliner priorities might want tweaking a bit here though, as we’ve seen cases where, after inlining, you end up with truly massive basic blocks that end up causing the register allocator to spent 5+ minutes at compile time, to save a few nanoseconds of run time.<br>
<span class="HOEnZb"><font color="#888888"><br>
David<br>
<br>
</font></span></blockquote></div><br></div>