[LLVMdev] Calling Conventions Cont'd

[Gordon Henriksen]

On Apr 14, 2008, at 14:25, Jon Sargeant wrote:

> Duncan Sands wrote:
>>
>
>>> What is the correct procedure for translating a function signature  
>>> from  a high-order language to LLVM?
>>
>> you have to do it carefully so that LLVM will end up producing  
>> object code that conforms to the platform ABI.  For example,  
>> suppose you are using cdecl with a small struct (a pair of ints,  
>> say).  Then your function should get two integer parameters, which  
>> LLVM will assign to registers.  If using a large struct then use  
>> byval which will pass it on the stack.
>>
>> I know this is painful, hopefully LLVM will get some helpers for  
>> this one day.  The reason is that some ABIs make distinctions that  
>> don't exist at the LLVM level.  For example at least one ABI says  
>> that "complex" ( { double, double } ) should be passed differently  
>> to a struct containing a pair of doubles.
>
> Ugh, this isn't what I wanted to hear.  Passing "complex"  
> differently than a structure containing two doubles is a bad design,  
> but alas, calling conventions are beyond our control.  How many  
> special cases like this are there?

llvm-gcc is probably your best reference on this matter.

> If "complex" is the only special case, LLVM could provide a complex  
> type, which behaves like {double,double} in all respects except for  
> calls.  I recommend handling calling conventions entirely in the  
> back end.

This would be convenient, but is unfortunately not realistic. Consider  
that platform calling conventions are generally defined in terms of C  
data types. Since LLVM's data types are by design lower-level than C,  
they are insufficient to specify platform calling conventions.  
Therefore, the LLVM IR needs to be annotated. This is done through a  
variety of mechanisms:

'cc'
'byval'
'sret'
aggregate return
breaking up structs into multiple parameters
merging structs fields into single parameters
probably more.

On the other hand, you need only consider this complexity when  
interoperating with C/C++; your language's own functions need only be  
self-consistent.

— Gordon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080414/8c4e5acf/attachment.html>