[LLVMdev] Fwd: Basic questions

Graham Wakefield mail at grahamwakefield.net
Sun Nov 9 11:47:15 PST 2008


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.html

Yes 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>


More information about the llvm-dev mailing list