search for: global_dtors

...nModule(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() { // .... if (...

...e more after all other passes have run? 2. Or should the llvm.global_ctors optimization code in globalopt be moved into a helper function somewhere that's called from both globalopt and a new optimization pass cdtoropt that does nothing but remove empty functions from llvm.global_ctors and llvm.global_dtors? Then only this new pass would be added after all other passes. (This new pass should run very quickly, it doesn't have to do much.) Thanks for any advice, Nico

Hello all! I extended the LDC2 with a pragma to register a funcion in the llvm.global_ctors or llvm.global_dtors list. On Linux, references to these functions are placed in .ctors and .dtors sections and everything runs fine. On Windows, functions from llvm.global_ctors are placed in section .CRT$XCU, which is automatically called by the MS C Runtime. However, functions from llvm.global_dtors are placed...

...), > 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...

...::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 the BitcodeReader, making...

...gt; 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: > > &...

...d. In this way, only one initializer is linked and only one entry is produced in the initializer array (.CRT$XCU). Everyone I've spoken with so far thinks this is basically awesome and is much cleaner than using guard variables. :) I propose changing LangRef to make llvm.global_ctors and llvm.global_dtors be arrays of { i32, void()*, i8* }, where the last field is an optional pointer to a GlobalValue. Old modules containing { i32, void()*} elements will also be accepted, and the missing third field will be assumed to be null. When performing LTO, if there are multiple entries with the same associat...

On Tue, Feb 18, 2020 at 9:42 PM David Blaikie <dblaikie at gmail.com> wrote: > I'm /guessing/ this might be related to the COFF support specifically > (perhaps COFF has no appending linkage support - in some cases LLVM IR > supports the union of all semantics so that different formats can be fully > expressed - but it means when targeting certain formats, some features are

Hi, I would like to create an .init section in the LLVM backend. Can anyone shed me the light on how to do it? Do I have to create it in the clang? Thanks, Jin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161014/4f262397/attachment.html>

...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: >...

...ly one initializer is linked and only one entry is produced in > the initializer array (.CRT$XCU). Everyone I've spoken with so far thinks this > is basically awesome and is much cleaner than using guard variables. :) > > I propose changing LangRef to make llvm.global_ctors and llvm.global_dtors be > arrays of { i32, void()*, i8* }, where the last field is an optional pointer to > a GlobalValue. Old modules containing { i32, void()*} elements will also be > accepted, and the missing third field will be assumed to be null. > > When performing LTO, if there are multiple entrie...

Hi All, The general initializer support patch has landed (see 85fb997659b plus follow up fixes). Some quick background: Until now ORC, like MCJIT, has handled static initializer discovery by searching for llvm.global_ctors and llvm.global_dtors arrays in the IR added to the JIT. This approach suffers from several drawbacks: 1) It provides no built-in support for other program representations: Object files and custom program representations added to the JIT require manual intervention from the user to run their initializers. 2) It requires...

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

...ntry is >> produced in >> the initializer array (.CRT$XCU). Everyone I've spoken with so far thinks >> this >> is basically awesome and is much cleaner than using guard variables. :) >> >> I propose changing LangRef to make llvm.global_ctors and >> llvm.global_dtors be >> arrays of { i32, void()*, i8* }, where the last field is an optional >> pointer to >> a GlobalValue. Old modules containing { i32, void()*} elements will also >> be >> accepted, and the missing third field will be assumed to be null. >> >> When perfor...

...> > 2. Or should the llvm.global_ctors optimization code in globalopt be > > moved into a helper function somewhere that's called from both > > globalopt and a new optimization pass cdtoropt that does nothing but > > remove empty functions from llvm.global_ctors and llvm.global_dtors? > > Then only this new pass would be added after all other passes. (This > > new pass should run very quickly, it doesn't have to do much.) > > How late do you need to move globalopt to get this to work? Do you get > any performance regressions if you just move it there? &...

...week: -- I’ve been working on a generic implementation of the new initialization APIs which I hope to be able to land next week. This will replace the runConstructors/runDestructors API in LLJIT (providing equivalent functionality: initializers will be discovered by scanning llvm.global_ctors/llvm.global_dtors), and will enable the development of platform specific initializer-support implementations. -- There’s a long-ish chat with @drmeister on the discord #llvm channel about RuntimeDyld vs JITLink, and large vs small code model. -- I have added a new LLJIT example program that demonstrates how to use...

...;>>> >>>> - 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 f...

...produced in > the initializer array (.CRT$XCU). Everyone I've spoken with so far > thinks this > is basically awesome and is much cleaner than using guard variables. :) > > I propose changing LangRef to make llvm.global_ctors and > llvm.global_dtors be > arrays of { i32, void()*, i8* }, where the last field is an optional > pointer to > a GlobalValue. Old modules containing { i32, void()*} elements will also be > accepted, and the missing third field will be assumed to be null. > > When...

Thank you Alex, I went and implemented a solution along those lines. It works well. It may be worth mentioning static constructors in the Kaleidoscope tutorial. Cheers, Daniele ________________________________________ From: Alex Denisov [1101.debian at gmail.com] Sent: 15 March 2019 08:07 To: Daniele Vettorel Cc: llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Static constructors with ORC