llvm dev - Oct 2010 - [LLVMdev] Structure returns to-do or not-to-do?

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?

I had a look back through the previous releases and saw that this was required
before version 2.3 because return types could not be structures (structures
weren't considered first class). However, since then it is legal to return a
structure, and that there is an optimization pass which looks specifically for
the type of functions which have an 'sret' argument and tries to return
the structure in registers if it fits.
I can imagine that the above behavior could be an artifact of the old system,
but obviously, when the structure is too large, it's going to have to be
return via pointer anyway.

So my question is, should I be following the demo's example for IR
generation or just generate IR which returns structures, even if they could be
too large to fit in registers?

Thanks,
Roger
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101020/b6ac08e2/attachment.html>

On Wed, Oct 20, 2010 at 4:56 PM, roger roger <roger83 at hotmail.co.uk>
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?
>
> I had a look back through the previous releases and saw that this was
> required before version 2.3 because return types could not be structures
> (structures weren't considered first class). However, since then it is
legal
> to return a structure, and that there is an optimization pass which looks
> specifically for the type of functions which have an 'sret'
argument and
> tries to return the structure in registers if it fits.
> I can imagine that the above behavior could be an artifact of the old
> system, but obviously, when the structure is too large, it's going to
have
> to be return via pointer anyway.
>
> So my question is, should I be following the demo's example for IR
> generation or just generate IR which returns structures, even if they could
> be too large to fit in registers?
>
> Thanks,
> Roger
The X86 platform should handle structure returns that don't fit in
registers (by converting it to an sret argument at codegen time), but
as far as I know, that hasn't been implemented on any other platform.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20101020/30735089/attachment.html>

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>