[llvm-dev] ABI attributes on arguments vs parameters

[Madhur Amilkanthwar via llvm-dev]

Hi Arthur,
As of today, which among parameters and arguments are used for codegen when
there is a mismatch between ABI attributes? I don't think we have a
thorough documentation for that.

My2c:
IMHO, the codegen should honor the argument attributes rather than
parameter ones as it would work for indirect calls too. For indirect calls
to work seamlessly, not inspecting any parameter attributes should be the
way forward. Mismatch on ABI attributes should be UB ideally, but we could
have a compatibility matrix between ABI attributes so that caller can set
compatible argument attributes rather than strictly adhering to parameter
attributes. (Or could even have a call-site mechanism to override)

Nevertheless, we should document this in LangRef once we have consensus.

+Matthew.Arsenault at amd.com <Matthew.Arsenault at amd.com>



On Wed, Jun 23, 2021 at 11:31 AM David Blaikie via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Might be worth CC'ing any already interested parties from previous
> discussions & linking to those threads (& maybe linking to this thread from
> those ones).
>
> It does seem pretty questionable that behavior changes if a function
> becomes indirect - do you have any rough idea of how deep the rabbit hole
> goes if we were to try to finish the work you started of not looking at the
> callee to determine these attributes?
>
> On Tue, Jun 22, 2021 at 6:06 PM Arthur Eubanks via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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>.
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>


-- 
*Disclaimer: Views, concerns, thoughts, questions, ideas expressed in this
mail are of my own and my employer has no take in it. *
Thank You.
Madhur D. Amilkanthwar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210623/907a1808/attachment.html>