search for: linkinmodules

<div>Hello!</div><div>I created a new llvm module (<strong>A</strong>) - to create a 'glue' code.</div><div>I want to call some functions from another module (<strong>B</strong>);</div><div>I load module <strong>B</strong> withing the same LLVMContext, and create a function declaration in module A

I'm migrating from 3.3 to 3.8 and am having a few problems. `CreateStructGEP` requires a type parameter now. I'm not sure what type it's expecting, so I converted `CreateStructGEP( valuePtr, index )` to `CreateStructGEP( valuePtr->getType(), valuePtr, index )`... would that be correct? `arg_iterator` no longer converst to Value*, I have a lot of this now: &*(args++) This

If I create a function in a module with: auto f = module->getOrInsertFunction( "eval_expr", ...) //create function Then later I link this with other modules: Linker link; link.LinkInModule( base_module ); link.LinkInModule( module ); Then I create an execution engine something like: auto ee = EngineBuilder( link.getModule() )...create(); If I attempt to run the function

Hello. I have an .bc, which defines @foo(%type* arg1, %type* arg2, %type* arg3). Firstly, i do this: runtimeModule = getLazyIRFileModule("runtime.bc", smd, llctx); then this: fooFunction = runtimeModule->getFunction("foo"); myType = runtimeModule->getTypeByName("type"); After that, i'm creating another module: myModule = new Module("My

Hello, While trying ThinLTO, I ran into an assertion failure in IRMover: https://llvm.org/bugs/show_bug.cgi?id=28180. I found that the assertion failure is happening because IRMover tries to map the metadata that already mapped in the destination module, and it seems that this happens because two different IRMovers are used for the same destination (or composite) module. During LTO, an IRMover

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

On Fri, May 15, 2015 at 12:02 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > > > On 2015-May-15, at 07:30, Teresa Johnson <tejohnson at google.com> wrote: > > > >>> a. Lazy Debug Metadata Linking: > >>> > >>> The prototype implementation included lazy importing of module-level > >>> metadata during the

So it looks like the verifier doesn't catch this condition - I think it should. The attached program reproduces the problem - verification succeeds, but the linker fails with a type assertion. BTW, if no one has the bandwidth to work on this I'm willing to attempt a fix, assuming that you agree that the verifier should discover this condition. Michael Muller wrote: > >

Hi, when I try to build libprofile with r80670 (both llvm and llvm-gcc) I get this error: make[1]: Entering directory `.../llvm-svn-debug-obj/runtime/libprofile' llvm[1]: Building Debug Bytecode Archive libprofile_rt.bca (internalize) llvm[1]: Installing Debug Shared Library /nfs/a5/astifter/astifter/llvm/llvm-svn-debug-obj/../llvm-svn-debug-install/lib/libprofile_rt.so 0 llvm-ld

=?ISO-8859-1?Q?Rafael_=C1vila_de_Esp=EDndola?= wrote: > > I can reproduce this consistently, but only under an extremely large pile of > > code :-) I haven't tried to strip it down to minimal a test case yet, but I > > will. One salient difference with the code you've provided is that in my > > code, @a is a struct type. However, changing the example to use a

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, Going ahead, the llvm-ld seems to segfault (build on Linux with llvm-ld v3.0svn build): make[2]: Entering directory `/root/code/vmkit/mmtk/mmtk-j3' llvm[2]: Building Debug+Asserts Bytecode Module MMTKRuntime.bc 0 llvm-ld 0x0884c66e 1 llvm-ld 0x0884c3fb 2 0xb7891400 __kernel_sigreturn + 0 3 llvm-ld 0x083be9e9 llvm::isa_impl<llvm::Constant,

> On 2014 Dec 10, at 08:40, Tom Stellard <tom at stellard.net> wrote: > > On Tue, Dec 09, 2014 at 09:22:16PM -0800, Duncan P. N. Exon Smith wrote: >> The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the >> C++ side of it. This was a rocky day, but I suppose that's what I get >> for failing to stage the change in smaller pieces. >>

Yes, I have the repro, though I can’t publish it externally. It would be great if you can upstream the patch so I can try it. Thank you for your explanation as well! -- Taewook From: <mehdi.amini at apple.com> on behalf of Mehdi Amini <mehdi.amini at apple.com> Date: Friday, July 22, 2016 at 2:16 PM To: Taewook Oh <twoh at fb.com> Cc: via llvm-dev <llvm-dev at

Hi everybody I am having a hard time figuring out the following problem: I am porting a library that uses LLVM 2.5 from Linux to Windows (LLVM compiled with cmake/MSVC, llvm-g++ pre-built binaries). Compilation works fine, but at runtime, I encounter the following assertion: Assertion failed: FunctionType::isValidReturnType(getReturnType()) && !isa<OpaqueType>(getReturnType ())

On Fri, Nov 11, 2011 at 12:18 AM, arrowdodger <6yearold at gmail.com> wrote: > Hello. I have an .bc, which defines @foo(%type* arg1, %type* arg2, %type* > arg3). > Firstly, i do this: > > runtimeModule = getLazyIRFileModule("runtime.bc", smd, llctx); > > then this: > > fooFunction = runtimeModule->getFunction("foo"); > myType =

Hi Akshat, > Going ahead, the llvm-ld seems to segfault (build on Linux with llvm-ld v3.0svn > build): try updating to latest LLVM from svn - this was fixed a day or two ago. Ciao, Duncan. > > make[2]: Entering directory `/root/code/vmkit/mmtk/mmtk-j3' > llvm[2]: Building Debug+Asserts Bytecode Module MMTKRuntime.bc > 0 llvm-ld 0x0884c66e > 1 llvm-ld 0x0884c3fb

Hi David, Thanks for your quick response! I now understand the reason that inlining cannot be done on functions with different target-attributes. Thanks for your explanation! However, I think I didn't fully understand your solution; it would be nice if you would like to elaborate a bit more. Here's a bit more info on my current workflow: (1) The clang++ compiler builds C++ source file

Hi, I tried building again with the latest llvm. I am getting another seg fault: make[2]: Entering directory `/root/code/vmkit/mmtk/java' Buildfile: /root/code/vmkit/mmtk/java/build.xml main: [javac] /root/code/vmkit/mmtk/java/build.xml:4: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [javac] Compiling 1

The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the C++ side of it. This was a rocky day, but I suppose that's what I get for failing to stage the change in smaller pieces. As of r223916 (lldb), I'm not aware of any remaining (in-tree) breakage, so if I've missed some problem in the sea of buildbot errors, please flag me down. I'll follow up soon with