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

[John Criswell]

On 10/29/12 1:07 PM, Bob Wilson wrote:
>
> On Oct 28, 2012, at 12:48 PM, Chris Lattner <clattner at apple.com 
> <mailto:clattner at apple.com>> wrote:
>
>>
>> On Oct 26, 2012, at 7:27 AM, Duncan Sands <baldrick at free.fr 
>> <mailto: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?

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.

If there's no reliable way to tell if the code generator added a memory 
allocation and, if so, where the memory is and what size it is, then 
parts of SAFECode would have to work at the MachineInstr level and might 
have to be platform dependent.  We'd like to avoid that if possible.
:)

-- John T.

P.S. We still care about i386, but that's mainly because one of our 
funding agencies still does (they evaluate SAFECode on i386).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20121029/3b99c8b8/attachment.html>