[LLVMdev] EH and C++ intergation

Žiga Osolin
Tue, 21 Nov 2006 18:45:46 -0000

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
>