[cfe-dev] Static constructors: _cxx_global_var_initN vs _GLOBAL__sub_I_XXX
Andrew Parker via cfe-dev
cfe-dev at lists.llvm.org
Thu Jan 7 01:49:42 PST 2016
Thanks David. To be more specific with my question, two things I'd like to
know are:
- Is there any significance in the naming _GLOBAL__sub_I_ vs
__cxx_global_var_init
or is this just an artefact of the way clang generates the code?
- 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)?
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 :) ).
On Thu, Jan 7, 2016 at 5:44 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:
> On 7 Jan 2016, at 09:36, Andrew Parker via cfe-dev <cfe-dev at lists.llvm.org>
> wrote:
> >
> > 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).
> >
> > Does anyone know the secrets behind this?
>
> 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).
>
> 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.
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160107/bea4f4aa/attachment.html>
More information about the cfe-dev
mailing list