similar to: 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

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

Here's a version that doesn't try to do block deletion on it's own. If you use -adce then -simplifycfg, you get what you want. It passes all tests except one, which is that we delete an invoke of a pure function, IE Transforms/ADCE/dce_pure_invoke.ll - I'm not sure why that's bad. The reason we delete it is because it returns false to I.mayHaveSideEffects(), and in particular,

From: Philip Reames <listmail at philipreames.com<mailto:listmail at philipreames.com>> Date: mardi 8 septembre 2015 12:50 To: Benoit Belley <benoit.belley at autodesk.com<mailto:benoit.belley at autodesk.com>>, "llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>" <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Subject:

Hi everyone, We have noticed that the SROA pass will only eliminate 'alloca' instructions if those are located in the entry basic block of a function. As a general recommendation, should the LLVM IR emitted by our compiler always place 'alloca' instructions in the entry basic block ? (I couldn't find any recommendations concerning this matter.) In addition, we have noticed

Hi everyone, I just reported the following issue: https://llvm.org/bugs/show_bug.cgi?id=24927 Using the Xcode 7 linker, one gets messages such as the following when linking objects generated using llvm: ld: warning: object file (foo.o) was built for newer OS X version (14.5) than being linked (10.9) The issue is the following: a) In lib/Support/Unix/Host.inc, sys::getDefaultTargetTriple()

Hi everyone, I am wondering what¹s stopping the LLVM optimizer (opt -O3) from eliminating the apparently useless « icmp sgt » instruction in the following piece of LLVM IR. > ; ModuleID = 'lambda-opt.bc' > target datalayout = "e-m:o-i64:64-f80:128-n8:16:32:64-S128" > target triple = "x86_64-apple-macosx10.10.0" > > ; Function

Hi Everyone, I have uploaded a patch that allows one to successfully gather gcov/gcda coverage information on programs which unload shared libraries. It¹s a simple fix, just adding a few COMPILER_RT_VISIBILITY (i.e. __attribute__((visibility("hidden")))) in GCDAProfiling.c. Now, I¹d like to include a test program to demonstrate the fix. AFAICT, there seems to be a single test for

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:

Hi Lang, > MCJIT does not compile lazily (though it sounds like that's not an issue here?) That is not an issue here since the code JIT's once (a few secs) and then run the generated machine code for hours. > Morten - Can you share any test cases that demonstrate the slowdown. I'd love to take a look at this. The code is massive so not practical. However I will try and

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

+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

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

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

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>

> 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

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 >

TL;DR - when linking from a lazily loaded module and using Linker::LinkOnlyNeeded, bodies of used functions aren't being copied during linking. Previously on one of our products, we would lazily load our runtime module (around 9000 functions), and link some user module into this (which is in all practical use cases much smaller). Then, post linking, we have a pass that runs over the