Hi, I apologize in advance if this is not the correct place to ask these questions, but I would be very grateful for redirection to the appropriate list/docs if so. I've just started with LLVM in the last week or so, and have worked my way through the Kaleidoscope tutorial, the IR docs & programmers manual, plus a few of the examples; everything makes sense. But there's one thing that has been hard for me to uncover: the how, when & which of deleting/clearing LLVM objects. To elaborate, I'm working on a project in which users may define new expressions and values at runtime, within localized or globalized scope (but crucially, they may also destroy them), which are JIT- compiled to native code. This is not necessarily via a textual language, fwiw. From experiments I've found that the Module and ExecutionEngine appear to prefer to be static globals - is this right? How can I safely limit the scope of user-code definitions & clear them afterwards in this situation? It's been hard to find examples to answer this question, since most assume a global memory space or single task. Likewise, should the lifetime of a PassManager match that of a Module, or is it better to create them and destroy them on-demand? Understanding scope & lifetime issues of the basic LLVM classes would help me to match their granularity to that of the tasks the users may wish to define. Again, apologies if these questions are naive and out of context in this list, or if I've missed something in the documentation that would answer my questions. Thanks again, Graham
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 ----- Original Message -----> Hi, > > I apologize in advance if this is not the correct place to ask these > questions, but I would be very grateful for redirection to the > appropriate list/docs if so. > > I've just started with LLVM in the last week or so, and have worked > my way through the Kaleidoscope tutorial, the IR docs & programmers > manual, plus a few of the examples; everything makes sense. But > there's one thing that has been hard for me to uncover: the how, when > & which of deleting/clearing LLVM objects. > > To elaborate, I'm working on a project in which users may define new > expressions and values at runtime, within localized or globalized > scope (but crucially, they may also destroy them), which are JIT- > compiled to native code. This is not necessarily via a textual > language, fwiw. From experiments I've found that the Module and > ExecutionEngine appear to prefer to be static globals - is this > right? How can I safely limit the scope of user-code definitions & > clear them afterwards in this situation? It's been hard to find > examples to answer this question, since most assume a global memory > space or single task. > > Likewise, should the lifetime of a PassManager match that of a > Module, or is it better to create them and destroy them on-demand? > Understanding scope & lifetime issues of the basic LLVM classes would > help me to match their granularity to that of the tasks the users may > wish to define. > > Again, apologies if these questions are naive and out of context in > this list, or if I've missed something in the documentation that > would answer my questions. > > Thanks again, > > Graham
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 ----- Original Message -----> Hi, > > I apologize in advance if this is not the correct place to ask these > questions, but I would be very grateful for redirection to the > appropriate list/docs if so. > > I've just started with LLVM in the last week or so, and have worked > my way through the Kaleidoscope tutorial, the IR docs & programmers > manual, plus a few of the examples; everything makes sense. But > there's one thing that has been hard for me to uncover: the how, when > & which of deleting/clearing LLVM objects. > > To elaborate, I'm working on a project in which users may define new > expressions and values at runtime, within localized or globalized > scope (but crucially, they may also destroy them), which are JIT- > compiled to native code. This is not necessarily via a textual > language, fwiw. From experiments I've found that the Module and > ExecutionEngine appear to prefer to be static globals - is this > right? How can I safely limit the scope of user-code definitions & > clear them afterwards in this situation? It's been hard to find > examples to answer this question, since most assume a global memory > space or single task. > > Likewise, should the lifetime of a PassManager match that of a > Module, or is it better to create them and destroy them on-demand? > Understanding scope & lifetime issues of the basic LLVM classes would > help me to match their granularity to that of the tasks the users may > wish to define. > > Again, apologies if these questions are naive and out of context in > this list, or if I've missed something in the documentation that > would answer my questions. > > Thanks again, > > GrahamBe seeing you grrr waaa www.grahamwakefield.net -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20081106/aa60a97c/attachment.html>