similar to: [LLVMdev] llvm.global_ctors

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 Mechanics, Saint

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

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:

+reid, +llvmdev, -llvm-commits > On 2014-Jul-30, at 11:56, Rafael Avila de Espindola <rafael.espindola at gmail.com> wrote: > > >> I think the fix is to upgrade old-style global arrays (or reject >> them?) in the .ll parser. >> > > The .ll format is not stable, so you should be able to just reject it. Looking a little deeper, it's not

On Wed, Jul 30, 2014 at 3:46 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > Looking a little deeper, it's not "old-style" exactly; rejecting this > > isn't trivial. > > > > - According to LangRef, the third field is optional [1]. > > > > [1]: > http://llvm.org/docs/LangRef.html#the-llvm-global-ctors-global-variable

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

I talked about this with Nick in person months ago, and my understanding is that GlobalOpt is also an enabling optimization that needs to run early. For example, if we can eliminate an initializer to an internal global with no other stores to it, we can propagate the result. Maybe we should run it twice. On Thu, May 1, 2014 at 11:01 AM, Rafael Espíndola < rafael.espindola at gmail.com>

Thanks Peter, this is very useful feedback. I did manage to change the behavior of LinkOnlyNeeded to correctly import all variables with AppendingLinkage. In fact, I discovered that there was already something fishy. A variable with AppendingLinkage would get imported correctly from the source module if the destination module already contained a definition for that variable and wouldn't be

> On 2014-Jul-30, at 18:05, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2014-Jul-30, at 17:19, Reid Kleckner <rnk at google.com> wrote: >> >>> On Wed, Jul 30, 2014 at 3:46 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: >>>> Looking a little deeper, it's not "old-style" exactly; rejecting this

Thanks for the hindsight. I am currently working on a patch/potential fix which introduces a new Linker::ImportIntrinsicGlobalVariables flag. The patch includes a unit test reproducing the problem. Hopefully, that will help getting more feedback. Note that it might take a while before I am allowed to upload the patch since I need approval from Autodesk Legal department. Cheers, Benoit Benoit

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 again. I'm wondering what the

Hi Reid, On 03/09/13 20:08, Reid Kleckner wrote: > On Mon, Sep 2, 2013 at 5:18 AM, Duncan Sands <baldrick at free.fr > <mailto:baldrick at free.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 >

On Mon, Sep 2, 2013 at 5:18 AM, Duncan Sands <baldrick at free.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. >> >>

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.

On Thu, May 1, 2014 at 11:12 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 1 May 2014 14:08, Reid Kleckner <rnk at google.com> wrote: >> I talked about this with Nick in person months ago, and my understanding is >> that GlobalOpt is also an enabling optimization that needs to run early. >> For example, if we can eliminate an initializer to an

Hi Everyone, We are looking for advise regarding the proper use of LTO in conjunction with just-in time generated code. Our usage scenario goes as follows. 1. Our front-end generates an LLVM module. 2. A small runtime support library is linked-in. The runtime library is distributed as bitcode. It is generated using "clang++ -emit-llvm' and 'llvm-link'. This allows

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

> On 2014-Jul-31, at 10:07, Reid Kleckner <rnk at google.com> wrote: > >> On Thu, 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 >>

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>

Hello > On Windows, functions from llvm.global_ctors are placed in section .CRT$XCU, > which is automatically called by the MS C Runtime. Only if you link with MS runtime. Mingw follows standard .ctors / .dtors scheme. > My expectation was that the dtors placed in .CRT$XTU which are the C > terminator functions. Maybe there is a way to customize this? Yes. Target (or,rather