Thanks, that helps. I saw the possibility to redefine function bodies in the Kaleidoscope tutorial. What's not so clear to me yet, is how to support multiple Modules, but it's getting clearer now. Can I run a potential case past you just to be sure that it is/isn't possible? I'd like to support users dynamically adding and using functions (plus structs, globals etc) to a Module, JIT compiling to an ExecutionEngine, in an interleaved fashion. That is, declare & define a function, run it through a FunctionPassManager, add it to an ExecutionEngine, use it, go ahead and repeat for a different function with the same Module, FunctionPassManager & ExecutionEngine, etc. Also, does there need to be a 1-1-1 correspondence between Module, FunctionPassManager and ExecutionEngine, or can it be 1-many(1-1)? Thanks again, and once again sorry if this info is available in existing docs; I haven't been able to find it yet. On Nov 6, 2008, at 8:36 AM, Nuno Lopes wrote:> Hi, > > The JIT engine currently uses a single memory block for all > functions that you JIT-compile (and global variables, constants, > etc..). Still, you can easily create and delete machine code. > You can use the following functions: > engine->freeMachineCodeForFunction(function); // clean the JITed code > function->eraseFromParent(); // clean a function's IR > > About the lifetime of the classes, its better to create them only > once, for eficiency sake. Allocating PassManagers each time you > compile a given piece of code is slow (and probably not useful as > you can reuse it). > > Nuno
> I'd like to support users dynamically adding and using functions > (plus structs, globals etc) to a Module, JIT compiling to an > ExecutionEngine, in an interleaved fashion. That is, declare & define > a function, run it through a FunctionPassManager, add it to an > ExecutionEngine, use it, go ahead and repeat for a different function > with the same Module, FunctionPassManager & ExecutionEngine, etc.that should work without much trouble. You can also redefine a function body and recompile it. The only catch is with inling. If you do any inling you'll have to recompile the other functions that inlined the redefined function.> Also, does there need to be a 1-1-1 correspondence between Module, > FunctionPassManager and ExecutionEngine, or can it be 1-many(1-1)?You can do the combinations you want, although I don't see any point in doing such a thing. It's just a waste of memory :)> Thanks again, and once again sorry if this info is available in > existing docs; I haven't been able to find it yet.I think you'll find the doxygen docs helpful: http://llvm.org/doxygen/classes.html Nuno
On Nov 9, 2008, at 3:46 AM, Nuno Lopes wrote:>> I'd like to support users dynamically adding and using functions >> (plus structs, globals etc) to a Module, JIT compiling to an >> ExecutionEngine, in an interleaved fashion. That is, declare & define >> a function, run it through a FunctionPassManager, add it to an >> ExecutionEngine, use it, go ahead and repeat for a different function >> with the same Module, FunctionPassManager & ExecutionEngine, etc. > > that should work without much trouble.Great.> You can also redefine a function body > and recompile it. The only catch is with inling. If you do any > inling you'll > have to recompile the other functions that inlined the redefined > function.Got it. nice.>> Also, does there need to be a 1-1-1 correspondence between Module, >> FunctionPassManager and ExecutionEngine, or can it be 1-many(1-1)? > > You can do the combinations you want, although I don't see any > point in > doing such a thing. It's just a waste of memory :)The reason is that I may have users needing to run very similar code concurrently and somewhat sandboxed. I was thinking to save memory by using the same Module for each concurrent instance.> >> Thanks again, and once again sorry if this info is available in >> existing docs; I haven't been able to find it yet. > > I think you'll find the doxygen docs helpful: > http://llvm.org/doxygen/classes.htmlYes I saw the doxy ... this line put me off: "This documentation describes the internal software that makes up LLVM, not the external use of LLVM. There are no instructions here on how to use LLVM, only the APIs that make up the software. For usage instructions, please see the programmer's guide or reference manual." (Which I have read.) ;-) I'm at an early stage with LLVM, trying to put together a design/ implementation strategy for some specific use-cases. Having a broad top-level view of LLVM's potentials, limits/points of possible failure, and implementation idioms is essential to getting a good strategy for using it. It's understandably difficult to attain given that LLVM could be used in *so many* different and powerful ways! I think some of this understanding will emerge through practice and test projects, and the various presentations (mov, pdf) on the site have also helped tremendously. Thanks for all your help. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081109/59f85cae/attachment.html>