[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