[llvm-commits] [LLVMdev] ABI: how to let the backend know that an aggregate should be allocated on stack

[Bob Wilson]

On Oct 28, 2012, at 12:48 PM, Chris Lattner <clattner at apple.com> wrote:

> 
> On Oct 26, 2012, at 7:27 AM, Duncan Sands <baldrick at free.fr> wrote:
> 
>>>> That is a strange byval implementation. Maybe the llvm ARM backend
>>>> should be changed to always pass byval on the stack? Clang can create
>>>> regular (integer, fp) arguments for the registers.
>>> 
>>> The current definition of the byval attribute in LangRef says nothing about requiring passing the argument on the stack.  It just says it "should really be passed by value".  When discussing the alignment, it does refer to a stack slot, but it isn't at all clear that it is required to be on the stack.
>> 
>> it needs to be addressable.  The "byval" parameter is a pointer, and that
>> pointer can be passed to any old routine as an ordinary pointer, and they
>> may read or write the memory it points to.  So while you could pass in
> 
> Right, this is my gripe with "byval".  It makes a lot of sense for large things that need to be passed on the stack, but very little sense for small things that need to be passed that way.  Clang on i386 suffers a number of code quality issues because it can't express this "I don't need it to be addressable, but I do need it passed on the stack" concept.  An "onstack" attribute seems the perfect analog to "inreg" to fix this.  That is, if anyone still cares about i386 :-)

I agree that an "onstack" attribute would make sense.

After we have that, we should also clarify the behavior of "byval".  It currently is interpreted differently for different targets.  Duncan is right about byval arguments needing to be addressable, but some targets pass byval arguments in registers (or at least partially in registers) and then store the values to the stack.  A separate "onstack" attribute might allow us to come up with a more consistent definition of "byval".
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121029/6f3327b7/attachment.html>