<div dir="ltr">Might be worth CC'ing any already interested parties from previous discussions & linking to those threads (& maybe linking to this thread from those ones).<br><br>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?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 22, 2021 at 6:06 PM Arthur Eubanks via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div><br></div><div><font face="monospace">declare void <a class="gmail_plusreply" id="gmail-m_5458548558939611053plusReplyChip-0">@f(i32* byval(i32))</a></font></div><div><a class="gmail_plusreply">d</a><font face="monospace">efine void @g() {</font></div><div><font face="monospace"> %a = alloca i32</font></div><div><font face="monospace"> call void @f(i32* %a) ; missing the byval(i32) attribute</font></div><div><font face="monospace"> ret void</font><a class="gmail_plusreply"><br></a></div><div><font face="monospace">}</font></div><div><br></div>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.<div><div><br></div><div>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.</div><div><br></div><div>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 <a href="https://llvm.org/docs/LangRef.html#id327" target="_blank">ABI attributes match on a musttail call</a>.</div><div></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>