[LLVMdev] EH and C++ intergation

Žiga Osolin ziga.osolin at gimb.org
Tue Nov 21 12:05:01 PST 2006


Chris Lattner pravi:
> On Tue, 21 Nov 2006, [ISO-8859-2] Žiga Osolin wrote:
>>> 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.
>
> Right.
>
>>>> 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.
>
> You're missing one piece: LLVM types are not C/C++ types, they have to 
> be lowered.  This lowering discards some information, which can affect 
> the ABI (e.g. some ABIs treat a 'complex double' differently than a 
> struct with two doubles).  LLVM types are not sufficient for making 
> ABI decisions, at least some part of the abi decision currently needs 
> to be made by the front-end.
>
>
But you can (as I am aware) define struct in llvm, such as struct 
smart_ptr { void* px; void* py; } and if you want to return such struct 
in the llvm, you must pass it as a pointer to the struct in order to 
return in correctly. You could actually return such struct as:
ret void* px, void* py
and enable the backend to either return it by struct (if not enough 
registers) or return it in registers. This is requered in order to call 
methods that return non-native types. I need this because we use boost 
smart pointers (which are basically struct of 2 pointers) and we must be 
able to return them.

Otherwise, we have no problem with modifying frontend, because we will 
actually write our own (BSF scripts) but we need JIT / C++ engine code 
compatibility (in all ways; EH, calls etc.).

Žiga



More information about the llvm-dev mailing list