similar to: [LLVMdev] FunctionPassManager Issue

Hi, I'm a cs326 student that uses LLVM for our MP. While some of the COOL program can be run seamlessly, I get the following assertion error for many of them. lli: Pass.cpp:95: bool llvm::FunctionPassManager::run(llvm::Function&): >> Assertion `(&F == mF) && "ModuleProvider does not contain this >> function!"' failed. >> >> It seems

Thanks for the reply. I actually managed to resolve this problem mostly to my satisfaction. I suspect based on your description of materializeFunction I may be best served by subclassing the ModuleProvider to do what I want. Thanks again. --- On Mon, 7/6/09, Chris Lattner <clattner at apple.com> wrote: > From: Chris Lattner <clattner at apple.com> > Subject: Re: [LLVMdev]

Hi Christophe, So this is a pain, but we are dealing with a pre-release. Until the 2.7 freeze the source should continue to churn. Regards Garrison On Feb 3, 2010, at 11:34, Christophe de Dinechin wrote: > What guarantees does LLVM try to provide regarding source code compatibility? > > Case in point: rev 94686 (http://llvm.org/viewvc/llvm-project?view=rev&revision=94686) breaks

So, it looks like I mis-read this. You were referring to backward compatibility. Garrison On Feb 3, 2010, at 12:11, Garrison Venn wrote: > Hi Christophe, > > So this is a pain, but we are dealing with a pre-release. Until the 2.7 freeze the source should continue to churn. > > Regards > > Garrison > > On Feb 3, 2010, at 11:34, Christophe de Dinechin wrote: >

On Jul 4, 2009, at 5:59 AM, Carter Cheng wrote: > I have tracing the calls to materializeFunction in the LLVM code in > hopes of determining how to properly utilize this function but from > my explorations I gather it's just a hook which is called by the JIT > system and I would mostly have to do the work myself. ModuleProvider is a very simple concept. You can either load

What guarantees does LLVM try to provide regarding source code compatibility? Case in point: rev 94686 (http://llvm.org/viewvc/llvm-project?view=rev&revision=94686) breaks any code that creates a JIT. For example, we used to construct a FunctionPassManager with a ModuleProvider, it's now to be done with a Module. I cannot ship source code for my own project that is compatible with both

Carter Cheng wrote: > I have tracing the calls to materializeFunction in the LLVM code in hopes of determining how to properly utilize this function but from my explorations I gather it's just a hook which is called by the JIT system and I would mostly have to do the work myself. > > What is the preferred way to inject a llvm:Function which contains basic blocks into the Module +

On Jun 21, 2007, at 4:13 PM, Dan Gohman wrote: > Right now, addPassesToEmitFile requires a FunctionPassManager. If I'm > working with code that uses a plain PassManager and want it to > generate > code, are there any options better than doing this: That's what FPPassManager does (include/llvm/PassManagers.h) . Function pass manager itself is a module level pass.

Right now, addPassesToEmitFile requires a FunctionPassManager. If I'm working with code that uses a plain PassManager and want it to generate code, are there any options better than doing this: /** * Wrapper class to run a FunctionPassManager as a ModulePass so that it * can be added to a plain PassManager. */ class FunctionPassManagerModulePass : public ModulePass { FunctionPassManager

On Thu, Jun 21, 2007 at 04:37:14PM -0700, Devang Patel wrote: > > On Jun 21, 2007, at 4:13 PM, Dan Gohman wrote: > > > Right now, addPassesToEmitFile requires a FunctionPassManager. If I'm > > working with code that uses a plain PassManager and want it to > > generate > > code, are there any options better than doing this: > > That's what

Thanks. The reason I ask is because I'm looking at some code that does just that. A single FunctionPassManager is constructed with a dummy Module and createStandardFunctionPasses is called on it. The FunctionPassManager cached and run on Functions in other Modules. So far I haven't noticed any problems but I guess that is because the passes added by createStandardFunctionPasses don't

On Sun, 15 Jul 2007, Paolo Invernizzi wrote: > First, I'm not sure if deleting the ExecutionEngine is all I need to > clean-up... so I started with a minimal test just to check Is this llvm 2.0 or llvm svn head? Several minor memory leaks have been fixed since llvm 2.0. -Chris > int main( int argc, char **argv ){ > while( true ){ > Module *M = new

I have tracing the calls to materializeFunction in the LLVM code in hopes of determining how to properly utilize this function but from my explorations I gather it's just a hook which is called by the JIT system and I would mostly have to do the work myself. What is the preferred way to inject a llvm:Function which contains basic blocks into the Module + JIT? My understanding (perhaps

First, I'm not sure if deleting the ExecutionEngine is all I need to clean-up... so I started with a minimal test just to check int main( int argc, char **argv ){ while( true ){ Module *M = new Module("M"); Function *F = cast<Function>(M->getOrInsertFunction("F", Type::Int32Ty, (Type*)0)); BasicBlock *BB = new

I'm trying to set up some automated testing, and I'd like to have multiple instances of ExecutionEngines, so that the state from the first test doesn't alter the second state. Right now I'm doing something along the lines of: Module *emptyModule = new Module("emptyModule"); ExecutionEngine executionEngine = ExecutionEngine::create(emptyModule);

Hi, Is it generally safe to cache a FunctionPassManager and reuse it on modules other than the one it was constructed with (assuming they have the same target triple)? paul -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110923/cd845b59/attachment.html>

On 09/23/2011 11:28 AM, Redmond, Paul wrote: > Hi, > > Is it generally safe to cache a FunctionPassManager and reuse it on > modules other than the one it was constructed with (assuming they have > the same target triple)? No. FunctionPass has a pair of methods, doInitialization and doFinalization, which take Module& and are allowed to read or modify it outside runOnFunction.

Hi, I am trying to generate LLVM code that calls a "native" function in the parent program (the program hosting the JIT). I think that I have figured out how to do this, but I get the following assertion failure when the LLVM code is executed: ../llvm/lib/Target/PowerPC/PPCJITInfo.cpp:206: failed assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23)

On Thu, 13 Apr 2006 18:07:42 +0200 Oscar Fuentes <oscarfv at telefonica.net> wrote: > > Simon Burton <simon at arrowtheory.com> writes: > > > I'm trying to take assembly and create machine code I can execute. > > How close am I ? > > Your test case is not complete. Besides, which version of llvm are you > using? What are the commands for compiling

I have had great luck in the last couple of months getting llvm to do cool stuff with directly linked modules using llvm-as and llvm-ld. Now, I would like to get some of the same functionality working through an ExecutionEngine; however, I am having trouble making functions call across module boundaries. I know from previous discussions on this list that what I am attempting should be easy. I