similar to: How to extract functions from Module A and put them into Module B, and generate a new IR file?

Michael Muller wrote: > > Hi all, > > I'm trying to use a function defined in one LLVM module from another module > (in the JIT) but for some reason it's not working out. My sequence of > activity is roughly like this: > > 1) Create moduleA > 2) Create moduleB with "func()" > 3) execEng = ExecutionEngine::create( > new

On Sun, Jan 10, 2010 at 8:58 AM, Michael Muller <mmuller at enduden.com> wrote: > > Michael Muller wrote: >> >> Hi all, >> >> I'm trying to use a function defined in one LLVM module from another module >> (in the JIT) but for some reason it's not working out.  My sequence of >> activity is roughly like this: >> >>   1) Create

Is there a preferred approach for an LLVM-based JIT-compiler to make calls from run-time generated functions in module A to bitcode-loaded functions in module B? A naive CallInst across the boundary fails verification. Calling it as an external function fails to resolve, even if both ModuleA and ModuleB are in the same ExecutionEngine. I can think of two ways around this: 1. Create a

Is there a preferred approach for an LLVM-based JIT-compiler to make calls from run-time generated functions in module A to bitcode-loaded functions in module B? A naive CallInst across the boundary fails verification. Calling it as an external function fails to resolve, even if both ModuleA and ModuleB are in the same ExecutionEngine. I can think of two ways around this: 1. Create a

Won't passing llvm::Function* around vs strings (function names), also work, at code generation time, without the need for a module A dec to module B impl. mapping? Garrison On Jan 10, 2010, at 10:31, Kenneth Uildriks wrote: > On Sun, Jan 10, 2010 at 8:58 AM, Michael Muller <mmuller at enduden.com> wrote: >> >> Michael Muller wrote: >>> >>> Hi all,

Hi all, I'm trying to use a function defined in one LLVM module from another module (in the JIT) but for some reason it's not working out. My sequence of activity is roughly like this: 1) Create moduleA 2) Create moduleB with "func()" 3) execEng = ExecutionEngine::create( new ExistingModuleProvider(moduleB)); 4) execute "func()" (this works fine)

The JIT tries to handle this in some cases (http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/ExecutionEngine/ExecutionEngine.cpp?annotate=92771#l942), but doesn't handle it for functions. There aren't any tests, so I'm not surprised it's broken. The JIT would be simpler if we just dropped multiple-module support and asked people to link their modules together before trying to

Hi James, > This is interesting. I've just implemented dynamic loading of bitcode modules into lli for my project. I did this by hacking lli using the Linker class. Is ExecutionEngine::addGlobalMapping() preferred for this purpose? I'm not sure about the preferred way, but at least for the JIT, here is an email from Jeffrey concerning a previous thread. The issue in that thread was

<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

Every inlinable call in a function that has debug info (F->getSubprogram() returns non-null) must have a DebugLoc associated with it that has a scope chain that ends in that same DISubprogram. https://llvm.org/docs/SourceLevelDebugging.html discusses some of the debug info IR metadata in LLVM. On Fri, Feb 2, 2018 at 1:03 AM Ku Nanashi via llvm-dev < llvm-dev at lists.llvm.org> wrote:

> Every inlinable call in a function that has debug info (F->getSubprogram() returns non-null) must have a DebugLoc associated with it that has a scope chain that ends in that same DISubprogram. Thank you for the comment! I don't know if this is a proper way to fix, but after I add DebugLoc same as inserting position instruction, no error occurs.

Hey Lang, Thank you for your help and your patience – also for your answers in the “ORC JIT - Can modules independently managed with one LLJIT instance? + problems with ExecutionSession.lookup” mail. Both problems have the same origin so I keep writing about it here, to avoid duplication. My big problem is still handling cross references between modules with “our” name scheme. Since our old

Hi, I'm trying to inline function defined in another bitcode module via bitcode modification. I'm linking multiple bitcode modules, setting inline related attributes, applying -always-inline pass, but then debug info error occurs. It seems debug info metadata isn't properly updated on inlining. How can I fix it? I'm using LLVM 3.8.1 on OS X (On below example target is Android but

Hey all, A quick question about the LLVM C-Api and using LinkModules. In a normal situation where I have 2 LLVM modules and 1 depends on the other using LLVMLinkModules2() works perfectly. LLVMLinkModules2() "Links the source module into the destination module. The source module is destroyed." according to the comment of the function. That is all fine when you only have 2 modules. But

Hey Lang, > Do you mean that the object file is produced by another process and is being loaded into your JIT process for execution, or that you want your JIT to produce code for several different processes? These are different problems with different solutions. I'll wait until I understand your use case to answer further. In the current state we don’t have a JIT only an handcrafted object

On Thu, May 31, 2012 at 10:21 PM, Justin Holewinski < justin.holewinski at gmail.com> wrote: > On Thu, May 31, 2012 at 8:06 PM, Chris Lattner <clattner at apple.com> wrote: > >> >> On May 31, 2012, at 2:39 PM, Justin Holewinski wrote: >> >> > The attached patch add the ability to programmatically re-direct >> outs()/errs() to an arbitrary

Hey Lang, Woah! That mail contains a lot of information and things I never tried yet… Actually… the entire MaterializationUnit and MaterializationResponsibility part is… quite… overwhelming >O< With “pop up” I mean… the process which is waiting for Module “Planschi” to “pop up” can not do a thing about it. It just waits until there is an table entry for it, indicating that the object file

On Jun 1, 2012, at 3:48 PM, Justin Holewinski wrote: > This isn't the right approach. Nothing in the library part of the compiler should be hard coding a stream to write to. What are you trying to accomplish? > > There are a lot of places where warning/debug information is passed directly to errs(). For example, take the Linker class. You can tell it to omit errors/warnings, but

Taking one step back, I'm not clear I'm even setting the triple/DataLayout on the module correctly:     module = new llvm::Module( "test", *llvm_context );     module->setTargetTriple( platform::target->triple ); Is that enough to create an appropriate DataLayout for the module?  I don't see anyway to convert a triple to a DataLayout, so I can't call

Hi edaqa, You might need to set your TargetOptions before calling selectTarget. E.g. builder.setTargetOptions(Opts).selectTarget(...); Or you could just let EngineBuilder call selectTarget for you (which is what the no-argument version of EngineBuilder::create does): llvm::ExecutionEngine * ee = builder. setErrorStr( &errStr ). setEngineKind( llvm::EngineKind::JIT ).