similar to: [LLVMdev] Best way to clean up empty global_ctors

Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] Best way to clean up empty global_ctors"

2014 May 01
3
[LLVMdev] Best way to clean up empty global_ctors
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>
2013 Sep 03
2
[LLVMdev] Proposal: Adding an optional association field to llvm.global_ctors
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. >> >>
2014 Jul 31
2
[LLVMdev] Inconsistent third field in global_ctors (was Re: [llvm] r214321 - UseListOrder: Visit global values)
> 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
2017 Jun 19
2
JIT, LTO and @llvm.global_ctors: Looking for advise
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
2013 Sep 04
0
[LLVMdev] Proposal: Adding an optional association field to llvm.global_ctors
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 >
2013 Aug 26
2
[LLVMdev] Proposal: Adding an optional association field to llvm.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.
2017 Jun 20
2
JIT, LTO and @llvm.global_ctors: Looking for advise
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
2014 May 01
2
[LLVMdev] Best way to clean up empty global_ctors
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
2014 Jul 30
2
[LLVMdev] Inconsistent third field in global_ctors (was Re: [llvm] r214321 - UseListOrder: Visit global values)
+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
2017 Jun 20
2
JIT, LTO and @llvm.global_ctors: Looking for advise
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
2014 Jul 31
2
[LLVMdev] Inconsistent third field in global_ctors (was Re: [llvm] r214321 - UseListOrder: Visit global values)
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
2013 Sep 02
0
[LLVMdev] Proposal: Adding an optional association field to llvm.global_ctors
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
2020 Feb 24
4
ORC JIT Weekly #6 -- General initializer support and JITLink optimizations
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:
2014 Sep 05
2
[LLVMdev] [cfe-dev] weak_odr constant versus weak_odr global
> I see. Using two comdats would still cause the same problem for us, > no? So the solution in the end is to emit: > > TU1: > -------------------------------- > @_ZN1UI1SE1kE = weak_odr constant i32 42, align 4, comdat _ZN1UI1SE1kE > @_ZGVN1UI1SE1kE = weak_odr global i64 1, comdat _ZN1UI1SE1kE > -------------------------------- > > TU2: >
2014 Jul 31
2
[LLVMdev] Inconsistent third field in global_ctors (was Re: [llvm] r214321 - UseListOrder: Visit global values)
> 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 >>
2014 Jul 03
5
[LLVMdev] Global constructors "get lost" when transforming bitcode files
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
2012 Sep 10
3
[LLVMdev] Question about ctors, dtors and sections on Windows
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
2011 Nov 21
0
[LLVMdev] [cfe-dev] weak_odr constant versus weak_odr global
> Unfortunately, making the comdat be for the entire function is not > conformant with the ABI, which says that you either put the variable > and its guard in different comdats or you put them in a single comdat > named for the variable.  It also doesn't actually help unless we disable > inlining. I see. Using two comdats would still cause the same problem for us, no? So the
2010 Apr 11
1
[LLVMdev] llvm.global_ctors and other "appending linkage" global variables?
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
2009 Mar 31
2
[LLVMdev] Mutating the elements of a ConstantArray
Hello, I need to append something to the global "llvm.global_ctors". This variable may or may not already be declared within the current module. If I lookup the global variable, I see that it supports a getOperand(i) and setOperand(i,c), but does not support any way that I can enlarge that array to add a new record. Any suggestions? -- Nick Johnson