[llvm-dev] ABI attributes on arguments vs parameters

[Arthur Eubanks via llvm-dev]

Currently ABI attributes are weirdly handled if an argument to a function
is missing an ABI attribute that is present on the called
function's corresponding parameter. e.g.

declare void @f(i32* byval(i32))
define void @g() {
 %a = alloca i32
 call void @f(i32* %a) ; missing the byval(i32) attribute
 ret void
}

CallBase::isByValArgument(unsigned ArgNo) forwards to
CallBase::paramHasAttr(), which first checks the argument attributes, then
if the call is a direct call, checks the called function's parameter
attributes. The existing implementation of CallBase::paramHasAttr() makes
sense for optimization attributes like nocapture, but doesn't really make
sense for ABI attributes like byval. It's weird that lowering a call may be
different depending on whether or not the call is direct.

I attempted to only have lowering inspect the ABI attributes on the
argument and not look through at a potentially direct callee, but there
were cases where LLVM was generating direct calls to functions with ABI
attributes but without properly setting the ABI attributes on the
arguments. I fixed a couple of these but ended up reverting everything
since it was still unclear if we wanted to go in this direction.

Should we go down the path of ignoring ABI attributes on direct callees and
only looking at the attributes on the arguments? And in that case we may
generate code that crashes at runtime if ABI attributes don't properly
match. Otherwise we should document the existing behavior in the LangRef.
The LangRef only mandates that ABI attributes match on a musttail call
<https://llvm.org/docs/LangRef.html#id327>.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210622/959dea5c/attachment.html>