[LLVMdev] EH and C++ intergation

Žiga Osolin ziga.osolin at gimb.org
Tue Nov 21 10:45:46 PST 2006


Chris Lattner pravi:
> On Tue, 21 Nov 2006, [ISO-8859-2] Žiga Osolin wrote:
>> I was going through documentation and source lately, and I decided 
>> how to
>> make llvm bytecode more compatible to C++:
>> 1) thiscall sould be introduced, which would take N arguments and the
>> first argument would always be the C++ "this" argument. This would
>> abstract llvm compiler dependant C++ code emittion.
>
> Sure.  Anton can give you ideas for this.
>
I think it should not be too difficult because you allow custom call 
conversions and this is quite easy to add, we only have to garantee that 
the backend will emit it.
>> 2) the ret instruction should be able to return structs (as Chris has
>> already written on his page).
>
> This won't help C++ or C.
I don't agree. For example:

struct SmartPtr { void* px; shared* py; }

Now, if I write the following method signature in C++:
SmartPtr foo(int whatever);

When I return, the llvm cannot return value in registers what is 
required by Visual C++ (or at least I think it is). I am posing
this issue because I really need this feature in llvm for my project.
>
>> 3) the EH could be done at code emission and would leave bytecodes
>> portable. Each backend would emit code compatible (if possible) with the
>> compiler it is compiled with; if llvm is compiled with VC8, it would 
>> emit
>> code compatible with VC8.
>
> I agree for unwind tables, this is what the invoke/unwind abstraction 
> are for.  For RTTI, there is nothing the compiler can do to shield you 
> from front-end dependencies.
>
> -Chris
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>   




More information about the llvm-dev mailing list