[LLVMdev] LLVM code emittion and C++ compiler compatibily

[Žiga Osolin]

Chris Lattner pravi:
> On Mon, 6 Nov 2006, [ISO-8859-2] Žiga Osolin wrote:
>> The problem is this is not possible, because what I would compile to JIT
>> are actual classes. The integration of C++ and JIT code is very
>> important; for example we would create our own vtbls with JIT-ed code
>> addresses as the function call target.
>
> Ok.  Realize that this ties you to a specific compiler version though.
As I am aware, the compiler is either GCC or VC++. Each of them has 
specific code generation (hopefully not too specific) that must be 
analyzed and act upon accordingly. The compiler versions do not change 
the output format, or at least I hope they do not (the binaries of VC6, 
VC7.1 and VC8 can be combined as much as you wish, I don't  know how 
this is handled by GCC).
>
>> There is one quite simple approach that I might take (I just came up 
>> with it). I could create special really small wrappers for each of 
>> these JIT-ed function, that would make the conversion to the common 
>> format (being either GCC or VC++). This wrapper could also extract 
>> all return values correctly and pass them to native C++ code as 
>> required. I think this would be the neatest solution, but would 
>> require a speed penalty. The actual wrapper code could be OS dependant:)
>
> Seems feasible.
>
>> Is there any interest for llvm to have such features, such as
>> integration directly to GCC compiled code, or VC++ compiled code (at the
>> same time)? Because maybe it could be the part of llvm instead of
>> baadengine, if you wish of course.
>
> It depends on precisely how it integrates with llvm and how separated 
> it is from other components.
>
>
I was thinking of providing an optional module to handle integration 
into C++. This module would only provide some sort of void* pointer for 
JIT-ed method. This
would actually be a small method that would pack the this pointer 
somehow and then call the actual underlaying method. It would of course 
need to be provided for
any type of JIT arhitecture ... But I don't know if this should be the 
part of llvm.

Žiga
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>