Question about returning a large struct

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about returning a large struct

Rodney M. Bates

In working on generating llvm IR from a different language frontend,
I am looking at clang-produced IR.  When a C function returns a
large struct, I see it gets encoded as a function returning void,
with an added, leftmost parameter, which is the address of a result
area, passed by the caller.

The clang-generated code for the return statement in the function
copies the result twice, once from an alloca for an explicitly
declared (in the C code) local variable to an internally generated
alloca, then again to the result area passed by the caller.

Is this necessary? optional? optimized out later?  It would be
easier for me to leave out the extra alloca and copy, if that
is workable IR code.

---
Rodney Bates
[hidden email]
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Question about returning a large struct

Philip Reames-4
On 01/20/2015 09:10 AM, Rodney M. Bates wrote:

>
> In working on generating llvm IR from a different language frontend,
> I am looking at clang-produced IR.  When a C function returns a
> large struct, I see it gets encoded as a function returning void,
> with an added, leftmost parameter, which is the address of a result
> area, passed by the caller.
>
> The clang-generated code for the return statement in the function
> copies the result twice, once from an alloca for an explicitly
> declared (in the C code) local variable to an internally generated
> alloca, then again to the result area passed by the caller.
>
> Is this necessary? optional? optimized out later?  It would be
> easier for me to leave out the extra alloca and copy, if that
> is workable IR code.
The second copy shouldn't be required.  However, the optimizer will
almost certainly remove (at least) one of them, so I'd suggest doing
whatever is easy to generate.

(Mind you, I'd write both examples by hand, run them through opt/llc,
and check just to be sure.  It's always possible there's a missed
cornercase somewhere.)

Philip
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev