[LLVMdev] Structure returns to-do or not-to-do?

Roger roger83 at hotmail.co.uk
Wed Oct 20 16:53:40 PDT 2010


On 20/10/2010 23:25, John McCall wrote:
> On Oct 20, 2010, at 2:56 PM, roger roger wrote:
>> I notice that using the online demo, functions which return 
>> structures are converted to be void, and instead take an extra 
>> argument which is the a pointer to the returned structure, and the 
>> allocation is made by the caller.
>> Even declared, but undefined functions are converted like this, 
>> presumably this doesn't cause a problem during linking?
>
> Right now, conformance with the platform ABI calling convention is an 
> intricate dance between the frontend (i.e. that which emits the IR) 
> and the backend.  So if the ABI says that a particular structure 
> return is implemented by passing a buffer pointer as an implicit first 
> argument to the function, then the front-end is responsible for 
> generating IR that follows that pattern if it wants ABI conformance. 
>  The optimization pass you point out is potentially breaking ABI 
> conformance, which means it (hopefully) only fires for functions with 
> internal linkage.
>
> If you're writing a frontend that doesn't care about conformance with 
> the platform ABI --- generally because your functions aren't going to 
> be called from C --- then you're limited only by what the backends 
> you're targeting actually support.  Unfortunately, LLVM provides 
> pretty limited promises here, and I wouldn't want to mis-state them.
>
> John.

Thanks, I thought this might be the case. At the moment I don't care 
about ABI compatibility, but eventually I might. I was more concerned 
that the backends might not correctly handle the case of returning large 
structures, which as Kenneth points out, is partially true. I think I'll 
just follow by example for now.

Roger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101021/93928284/attachment.html>


More information about the llvm-dev mailing list