<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 17 October 2014 14:21, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Can we also update the LangRef to spell this out? The "Both markers imply that the callee does not access allocas or varargs from the caller." does not clearly cover byval arguments (in practice they're often implemented similarly to non-entry-block allocas in the caller, but they could be on the callee's stack frame in some ABIs, and regardless, at the IR level they're not allocas). The byval documentation says only, "The attribute implies that a hidden copy of the pointee is made between the caller and the callee, so the callee is unable to modify the value in the caller." so it does not specify in which stack frame the pointer is considered to reside.<br>
<br>
</span>So, with this interpretation what should happen is<br>
<br>
* The tail call is valid with the byval.<br>
* The inliner must drop the tail marker, since it is the thing<br>
converting a byval into an alloca.<br></blockquote><div><br></div><div>The inliner already has to strip off tails from calls in the callee's function body anyways. See the call to setTailCallKind in llvm::InlineFunction.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I can't remember why this was not the preferred reading of the<br>
language reference when PR7272 was first fixed.<br>
<br>
In any case. The test is an end to end check to make sure we pass the<br>
correct value after inlining and cleanups. It seems better to have it<br>
passing first and then figure what we want to change :-)<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>