llvm dev - Mar 2016 - C returning struct by value

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>

On Mon, Mar 28, 2016 at 5:14 PM, Michael Nicolella via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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?
>
Yes, it is target specific. You should check
clang/lib/CodeGen/TargetInfo.cpp for details of how calls are lowered from
C for various targets. For some targets (e.g. x86-64), it's decidedly
non-trivial. You can also run clang -emit-llvm to see what actually gets
emitted for particular functions. If you stay away from passing
structs/unions by value, it becomes a *lot* simpler, though...

Some people have tried to make libraries for doing the ABI lowering
available in a way that's not tied to clang. Here's one: <
https://github.com/scross99/llvm-abi> (I have no idea how well, or if, it
works).

I think I've also seen mention of someone constructing the proper classes
to pass to clang to have it emit the C ABI calls from their non-C language,
although I'm not sure where I saw that.

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?
>
I don't know of anybody working on changing the way this works. I'd
personally love to work on cleaning it up, someday...but that's a wish, not
a plan.


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.
>>
>
>
> _______________________________________________
> 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/20160329/4a6b92d8/attachment.html>

On 29 March 2016 at 09:17, James Y Knight <jyknight at google.com>
wrote:
> I think I've also seen mention of someone constructing the proper
classes to
> pass to clang to have it emit the C ABI calls from their non-C language,
> although I'm not sure where I saw that.
I think this is what Swift does, so a poke around their repository
could be interesting.

Tim.

On Tue, Mar 29, 2016 at 9:17 AM, James Y Knight via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On Mon, Mar 28, 2016 at 5:14 PM, Michael Nicolella via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>> 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?
>
>
> Yes, it is target specific. You should check
> clang/lib/CodeGen/TargetInfo.cpp for details of how calls are lowered from
C
> for various targets. For some targets (e.g. x86-64), it's decidedly
> non-trivial. You can also run clang -emit-llvm to see what actually gets
> emitted for particular functions. If you stay away from passing
> structs/unions by value, it becomes a *lot* simpler, though...
>
> Some people have tried to make libraries for doing the ABI lowering
> available in a way that's not tied to clang. Here's one:
> <https://github.com/scross99/llvm-abi> (I have no idea how well, or
if, it
> works).
>
> I think I've also seen mention of someone constructing the proper
classes to
> pass to clang to have it emit the C ABI calls from their non-C language,
> although I'm not sure where I saw that.
There was an interesting talk a couple years ago about how Swift embeds clang:
  http://llvm.org/devmtg/2014-10/Slides/Skip%20the%20FFI.pdf
Now that it's open-source the code might be of interest.

-Ahmed
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>