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

[Bob Wilson]

On Oct 29, 2012, at 12:06 PM, John Criswell <criswell at illinois.edu> wrote:

> On 10/29/12 1:40 PM, Eli Friedman wrote:
>> On Mon, Oct 29, 2012 at 11:30 AM, John Criswell <criswell at illinois.edu> wrote:
>>> On 10/29/12 1:07 PM, Bob Wilson wrote:
>>> 
>>> 
>>> 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".
>>> 
>>> 
>>> So, if I understand what you're proposing, "onstack" means that something
>>> should be passed on the stack, and "byval" means that the compiler inserts
>>> an invisible copy of the data when performing the function call.  That would
>>> then mean that something that is both "byval" and "onstack" means that
>>> something has been copied and is located on the stack.  Is this correct?
>> Yes.
> 
> Okay, so, in other words, something that is labeled as byval now would be marked both byval and onstack in the new design.  Is this correct, or does byval maintain its current meaning (i.e., a pointer points to an addressable copy of an argument)?

I am not proposing anything specific with regard to "byval" at this point.

But, there are two changes I think may come from this:

1) Some uses of "byval" would be replaced by "onstack".  This would address the i386 code quality issues that Chris mentioned.  

2) Doc changes to clarify the meaning of "byval".  Part of that should involve specifying whether it can be used in combination with other attributes like "inreg" or "onstack".

I don't expect any of this would affect SAFECode, since "byval" would continue to mean pretty much what it does now.

> 
>> 
>>> Tools like SAFECode (and maybe ASan) rely on being able to identify memory
>>> allocations at the LLVM IR level; this includes things like byval arguments
>>> where the only information about the memory allocation is the byval argument
>>> itself.  For example, SAFECode instruments functions with byval arguments to
>>> record the size and location of the byval argument.
>> SAFECode doesn't care about onstack in the same way it doesn't care
>> about stack slots allocated to spills: SAFECode only affects memory
>> which is exposed in the IR.  And I don't think anyone in this thread
>> is suggesting changing the IR semantics of byval.
> 
> Just to make sure we're on the same page, you are correct that SAFECode does not care about stack spill slots because those are not valid addresses for LLVM load/store instructions.  However, it is concerned with byval arguments because they create an implicit memory allocation (on the stack, at present, for x86) and provide a pointer to that memory which is a valid address for LLVM load/store instructions.
> 
> -- John T.
> 
>> 
>> -Eli
>