[LLVMdev] Basic questions

[Nuno Lopes]

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