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, > RogerThe 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>