search for: global_ctor

Hi, I'd like to fix PR19590, which is about llvm.global_ctors containing functions that end up being empty after optimization (which causes the linker to add useless init_array entries to the output binary). globalopt removes empty functions from llvm.global_ctors, but by the time the function becomes empty globalopt has already run and it doesn't run ag...

Can anyone explain how llc translates "appending linkage" global variables like llvm.global_ctors into assembly? In the case I am examining, the global_ctor variables are in multiple bitcode object modules produced by the llvm compiler as arrays of pointers. As documented, the arrays seem to be combined when the different bitcode object modules are linked into one, so now there is one llvm.glo...

...Hi Reid, > > On 26/08/13 23:43, Reid Kleckner wrote: > > To implement http://llvm.org/PR16959 > <http://llvm.org/bugs/show___bug.cgi?id=16959 > <http://llvm.org/bugs/show_bug.cgi?id=16959>>, I need to add a new field to > > global_ctors. > > Static data members of class template instantiations can have > initializers that > must only run once on program startup. Itanium solves this with guard > variables > and the emission of multiple initializers, only one of which actua...

....fr> wrote: > Hi Reid, > > On 26/08/13 23:43, Reid Kleckner wrote: > >> To implement http://llvm.org/PR16959 >> <http://llvm.org/bugs/show_**bug.cgi?id=16959<http://llvm.org/bugs/show_bug.cgi?id=16959>>, >> I need to add a new field to >> >> global_ctors. >> >> Static data members of class template instantiations can have >> initializers that >> must only run once on program startup. Itanium solves this with guard >> variables >> and the emission of multiple initializers, only one of which actually >> ini...

Hello, A strange problem appears when upgrading from release_34 to testing. Some transformations to bitcode files cause registered global_ctors to not be called. Here's an example (I've also attached the complete example and pasted it below): This works: clang -fsanitize=address -flto -c -o sum.o sum.c clang -fsanitize=address -o sum sum.o This doesn't work: clang -fsanitize=address -flto -c -o sum.o sum.c...

...he two-field version. >>>> >>>> - Despite the field being optional (and the API defaulting to the >>>> short version), the BitcodeReader auto-upgrades to the 3-element >>>> version. >>>> >>>> It looks to me like `@llvm.global_ctors` and `@llvm.global_dtors` are in >>>> an inconsistent state here. In particular, with the same version of the >>>> tool, if you generate the arrays you get one type, then if you write to >>>> bitcode and read it back you get another type. >>>> >...

...result. Maybe we should run it twice. On Thu, May 1, 2014 at 11:01 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > On 30 April 2014 19:48, Nico Weber <thakis at chromium.org> wrote: > > Hi, > > > > I'd like to fix PR19590, which is about llvm.global_ctors containing > > functions that end up being empty after optimization (which causes the > > linker to add useless init_array entries to the output binary). > > globalopt removes empty functions from llvm.global_ctors, but by the > > time the function becomes empty globalopt h...

...>> >> Maybe we should run it twice. > > That is probably fine, we just have to make sure compile time doesn't > surfer too much. Looking at GlobalOpt, it seems to do full symbolic evaluation of all constructors, which is more than what's needed here. Just walking llvm.global_ctors and removing calls to functions that are just "ret" is all that's needed. Unless folks think that's a terrible idea, I'll try to write a lightweight pass for doing just that.

Hi all, Recently I do some jobs based on llvm-link tool. I wonder why link '@llvm.global_ctors' into dest file, even it's not used in dest file? And how can I remove it? Thank you all in advance! Fangqing Xilinx Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190102/283cdd91/attachment.h...

When you link two modules each of which contains a global_ctors array, is there a guarantee as to what order they'll run in?

To implement http://llvm.org/PR16959<http://llvm.org/bugs/show_bug.cgi?id=16959>, I need to add a new field to global_ctors. Static data members of class template instantiations can have initializers that must only run once on program startup. Itanium solves this with guard variables and the emission of multiple initializers, only one of which actually initializes the data at runtime. Microsoft solves this by using...

Hi Reid, On 26/08/13 23:43, Reid Kleckner wrote: > To implement http://llvm.org/PR16959 > <http://llvm.org/bugs/show_bug.cgi?id=16959>, I need to add a new field to > global_ctors. > > Static data members of class template instantiations can have initializers that > must only run once on program startup. Itanium solves this with guard variables > and the emission of multiple initializers, only one of which actually > initializes the data at runtime. > &gt...

...ntext)); linker.linkInModule(std::move(module), Linker::LinkOnlyNeeded | Linker::InternalizeLinkedSymbol); Our issue is with the Linker::LinkOnlyNeeded flag. Using it has a huge positive impact on link and compilation time :-). But, it causes the @llvm.global_ctors and @llvm.global_dtors references from the linked-in modules to be discarded :-(. AFAICT, the Linker code assumes ThinLTO when the LinkOnlyNeeded flags is specified, and full-LTO otherwise. To resolve this, we have locally patched llvm/lib/Linker/LinkModules.cpp with: bool ModuleLinker::run()...

...u, Jul 31, 2014 at 9:49 AM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: >> Hold on, I'm still not sure what kind of guarantees (restrictions) the C >> API imposes. >> >> If I implement (2), then -verify will fail if someone (e.g.) adds >> `@llvm.global_ctors` with 2 fields. Does C API stability preclude >> making that change? > > Now you have reached the crux of it. Nobody really agrees. The verifier doesn't reject the 2-field form yet, because I thought that would be a C API break. > >> Assuming it does, are there serious...

...e <dblaikie at gmail.com> Date: mardi 20 juin 2017 à 11:12 To: Benoit Belley <benoit.belley at autodesk.com>, llvm-dev <llvm-dev at lists.llvm.org>, Lang Hames <lhames at gmail.com>, Teresa Johnson <tejohnson at google.com> Subject: Re: [llvm-dev] JIT, LTO and @llvm.global_ctors: Looking for advise >+Lang (for JIT) & Teresa (for LTO/ThinLTO). > >Sounds like maybe the LinkOnlyNeeded got reused for a bit more than the >original intent & maybe there should be more than one flag here - not >sure. > >On Mon, Jun 19, 2017 at 9:16 AM Benoit Belley...

Hello, Kenneth > When you link two modules each of which contains a global_ctors array, > is there a guarantee as to what order they'll run in? No, the order to static ctors is undefined. There is special "priority" attribute though. I don't remember whether we honor it or not... -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechani...

Hello, I am still experimenting with the C interface to LLVM, it is going well so far. But I am seeming to have trouble getting access the @llvm.global_ctors variable and add a function that I have created. Any idea how to approach his by only using the LLVM-C interface? Thank you, Filip

...se in the Dest. /// For ThinLTO function importing/exporting the \p ModuleSummaryIndex /// is passed. If \p GlobalsToImport is provided, only the globals that /// are part of the set will be imported from the source module. /// /// Returns true on error. // Don't want to append to global_ctors list, for example, when we // are importing for ThinLTO, otherwise the global ctors and dtors // get executed multiple times for local variables (the latter causing // double frees). // For ThinLTO we don't import more than what was required. // The client has to guarantee that...

...p) will by default > > set up the two-field version. > > > > - Despite the field being optional (and the API defaulting to the > > short version), the BitcodeReader auto-upgrades to the 3-element > > version. > > > > It looks to me like `@llvm.global_ctors` and `@llvm.global_dtors` are in > > an inconsistent state here. In particular, with the same version of the > > tool, if you generate the arrays you get one type, then if you write to > > bitcode and read it back you get another type. > > > > There are a few ways to...

...balCtors()` and `llvm::appendToGlobalDtors()` (in ModuleUtils.cpp) will by default set up the two-field version. - Despite the field being optional (and the API defaulting to the short version), the BitcodeReader auto-upgrades to the 3-element version. It looks to me like `@llvm.global_ctors` and `@llvm.global_dtors` are in an inconsistent state here. In particular, with the same version of the tool, if you generate the arrays you get one type, then if you write to bitcode and read it back you get another type. There are a few ways to move forward: 1. Remove the auto-upgrade from...