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

[Eli Friedman]

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.

> 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.

-Eli