similar to: [LLVMdev] Problems with lazy linking change

On Fri, Nov 4, 2011 at 10:46 AM, Matt Pharr <matt.pharr at gmail.com> wrote: > r143524 changed ModuleLinker such that when linking a Module B into a Module A, any internal/private/... functions in B are only linked into A if there is a use of them in A.  This is problematic for my usage of module linking, where I'm basically linking a few modules together (some of which include

I looked at an earlier version. NamedMDNodes were linked after global values. Current trunk version links NamedMDNodes before that, though the comment says otherwise: "We do this after linking GlobalValues so that MDNodes that reference GlobalValues are properly remapped". see ModuleLinker::run in lib/Linker/LinkModules.cpp. If I move the call to linkNamedMDNodes in ModuleLinker::run

On Apr 24, 2012, at 5:36 AM, Renato Golin wrote: > On 24 April 2012 16:04, Matt Pharr <matt.pharr at gmail.com> wrote: >> When I generate debug information for a source file that has a number of static functions that are unused, all of the debugging metadata that I generated for them during initial compilation remains even after the source function definitions have been stripped

I'm seeing some behavior that surprised me in writing an <8 x i1> vector to memory and reading it back. (Specifically, the surprise is that I didn't get the original value back!). This happens both with TOT and 2.9. This program illustrates the issue: define i32 @foo() { %c = alloca <8 x i1> store <8 x i1> <i1 true, i1 false, i1 false, i1 false, i1 false, i1

On Tue, Sep 6, 2011 at 4:37 PM, Matt Pharr <matt.pharr at gmail.com> wrote: > I'm seeing some behavior that surprised me in writing an <8 x i1> vector to memory and reading it back.  (Specifically, the surprise is that I didn't get the original value back!).  This happens both with TOT and 2.9.  This program illustrates the issue: > > define i32 @foo() { >  %c =

On Aug 4, 2011, at 11:30 AM, Xi Wang wrote: > I looked at an earlier version. NamedMDNodes were linked after global > values. Current trunk version links NamedMDNodes before that, though > the comment says otherwise: "We do this after linking GlobalValues so > that MDNodes that reference GlobalValues are properly remapped". see > ModuleLinker::run in

When I generate debug information for a source file that has a number of static functions that are unused, all of the debugging metadata that I generated for them during initial compilation remains even after the source function definitions have been stripped out of the IR. (e.g. in the MD for DW_TAG_compile_unit's list of subprograms, each of those functions' info is still in the list,

On Aug 4, 2011, at 8:21 AM, Xi Wang wrote: > Hi, > > It seems that current linker "drops" updated llvm::Value * references > in metadata. Here goes an example. We have a two-line source file > a.c: > > static int x; > void foo() { x = 1; } > > and a similar b.c: > > static int x; > void bar() { x = 1; } > > They both have an internal

Hi, It seems that current linker "drops" updated llvm::Value * references in metadata. Here goes an example. We have a two-line source file a.c: static int x; void foo() { x = 1; } and a similar b.c: static int x; void bar() { x = 1; } They both have an internal variable x; one of them will be renamed (to x1) during linking. clang -emit-llvm -c -g a.c clang -emit-llvm -c -g b.c

On 24 April 2012 16:04, Matt Pharr <matt.pharr at gmail.com> wrote: > When I generate debug information for a source file that has a number of static functions that are unused, all of the debugging metadata that I generated for them during initial compilation remains even after the source function definitions have been stripped out of the IR.  (e.g. in the MD for DW_TAG_compile_unit's

I've included below an RFC for implementing ThinLTO in LLVM, looking forward to feedback and questions. Thanks! Teresa RFC to discuss plans for implementing ThinLTO upstream. Background can be found in slides from EuroLLVM 2015: https://drive.google.com/open?id=0B036uwnWM6RWWER1ZEl5SUNENjQ&authuser=0) As described in the talk, we have a prototype implementation, and would like to

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

I'm trying to wire up some code to use the MC-based JIT; my understanding is that it should be able to JIT AVX code (and that the regular JIT cannot). However, I'm getting the error "Target does not support MC emission!" when I call EngineBuilder::create(). I assume that I'm just not doing something necessary for initialization, but I'm not sure what it would be--I am

It seems that one of the optimization passes (it seems to be SROA) sometimes transforms computations on vectors of ints to computations on wide integer types; for example, I'm seeing code like the following after optimizations(*): %0 = bitcast <16 x i8> %float2uint to i128 %1 = shl i128 %0, 8 %ins = or i128 %1, 255 %2 = bitcast i128 %ins to <16 x i8> The back end I'm

Hi all, I was looking at the ValueMapper code this morning and I notice that it doesn't do type mapping for GlobalValues. Is this correct? I ask because I am seeing a case where I'm failing type assertions from ModuleLinker::linkGlobalInits() when an array initializer references an external global. It looks like the external global is being mapped directly and this causes an element

Filed as http://llvm.org/bugs/show_bug.cgi?id=12678. On Apr 23, 2012, at 2:03 PM, llvmdev-request at cs.uiuc.edu wrote: > I'm seeing some strange behavior with generating debugging information from a simple program. (LLVM top of tree, minus a couple of days.) > > I suspect that there is a bug in LLVM, but thought I'd check in here to see if perhaps I'm doing something

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 Ralf, FYI, old JIT doesn't support AVX at all, no encoding info, etc... The only way to use AVX+JIT is using MCJIT, which contains the correct encoding, but unfortunately the framework isn't good yet as the old one is. On Thu, Aug 25, 2011 at 10:12 AM, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi Matt, > > I am unsure about MCJIT, but I guess the problem is the same.

Following along from lli code, if you add a call to InitializeNativeTargetAsmPrinter() during setup, it gets a bit farther and crashes rather than issuing that error. (Rebuilding with debugging symbols now to dig into it further…) -matt Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x000000010000349e in

I'm writing a compiler where I'd like to be able to (sometimes) represent lvalues of vectors (e.g. <4xfloat>) with vectors of pointers (e.g. <4xfloat *>). In this case, I'd like to be generating these vectors of pointers early on and later converting operations on them to a series of individual loads/stores with a later pass. (Note, though, that ISAs with