llvm dev - Mar 2016 - C returning struct by value

I'm new to using LLVM and I've started work on a compiler for a language
that can interface with C. One thing that caught me off guard was returning a
struct from a function by value. It seems that when calling a C function I need
to emit llvm ir that, in the caller, emits an alloca for the returned structure,
and the C function signature should return void and take a first argument with
the pointer annotated with the "sret" attribute.

Can someone help me understand why this detail needs to be understood by the
frontend, and isn't handled by maybe annotating the C function with some
attribute that says it should conform to a certain calling convention - then
just having the signature be to naturally return the struct by value, but the
backend knows how to transform it to what it should be?

Cheers
-Mike

Unfortunately, the understanding of the C calling convention is split
between LLVM and Clang in a rather difficult to understand (and poorly
documented) manner. Needing to put the struct return value in an 'sret'
argument is but one of the many ways in which you need to adjust your LLVM
function definition from the "obvious" lowering of a C function.

I don't think anyone feels it ideal, but it's what we have. There are a
number of reasons why this is not completely trivial to fix.

On Mon, Mar 28, 2016 at 12:48 AM, Michael Nicolella via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I'm new to using LLVM and I've started work on a compiler for a
language
> that can interface with C. One thing that caught me off guard was returning
> a struct from a function by value. It seems that when calling a C function
> I need to emit llvm ir that, in the caller, emits an alloca for the
> returned structure, and the C function signature should return void and
> take a first argument with the pointer annotated with the "sret"
attribute.
>
> Can someone help me understand why this detail needs to be understood by
> the frontend, and isn't handled by maybe annotating the C function with
> some attribute that says it should conform to a certain calling convention
> - then just having the signature be to naturally return the struct by
> value, but the backend knows how to transform it to what it should be?
>
> Cheers
> -Mike
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160328/0f1282aa/attachment.html>

On 27 March 2016 at 21:48, Michael Nicolella via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Can someone help me understand why this detail needs to be understood by
the frontend,
Many of the backends can do automatic demotion to sret, but the
front-end still needs to be aware of the issues (particularly around
unions, since whether demotion is necessary can depend on more than
just the size of the type).

I'd also expect marginally better code in some cases by using sret
explicitly: the demotion occurs pretty late on and a "%type *sret"
parameter better represents what will actually be happening later on.

Cheers.

Tim.

Thanks for the explanation. It's good to hear the situation isn't felt
to
be ideal.

The details here are going to be sensitive to the OS + target that I'm
compiling for, right? So the effort here will be to understand and get
right the calling convention details for each supported target, yes?

Is there any current plan to change the way this works, or is it more of a
dreamy cleanup item that maybe will get addressed some day?

Appreciate the tip.

On Mon, Mar 28, 2016 at 9:28 AM, Tim Northover <t.p.northover at
gmail.com>
wrote:
> On 27 March 2016 at 21:48, Michael Nicolella via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Can someone help me understand why this detail needs to be understood
by
> the frontend,
>
> Many of the backends can do automatic demotion to sret, but the
> front-end still needs to be aware of the issues (particularly around
> unions, since whether demotion is necessary can depend on more than
> just the size of the type).
>
> I'd also expect marginally better code in some cases by using sret
> explicitly: the demotion occurs pretty late on and a "%type
*sret"
> parameter better represents what will actually be happening later on.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160328/01db01b7/attachment.html>