<div dir="ltr"><div dir="ltr">Re-adding llvm-dev -- silly phones not defaulting to reply-all...<div><br></div><div>There are several things here. The first one is -fno-omit-frame-pointer is causing the generation of "push %rbp ; mov %rsp, %rbp". This would be required for accurate stack traces, so we can't simplify to just "call / ret" as you suggest, without changing the option.</div><div><br></div><div>The less obvious one is the spilling of RDI to stack memory and reloading it into RAX, which is what I was raising. The Sys V ABI requires that the address of a struct returned by pointer be returned in RAX, and LLVM complies. It looks like I misremembered. We've always returned RDI in RAX for sret functions, since 2008 / r<span style="color:rgb(0,0,0)">50075</span>. However, we never did the right thing in 32-bit. I fixed that in <a href="https://bugs.llvm.org/show_bug.cgi?id=23491">https://bugs.llvm.org/show_bug.cgi?id=23491</a> / <span style="color:rgb(0,0,0);white-space:pre-wrap">r237639</span>. We don't yet implement the general optimization of avoiding such spills by reusing the value returned in RAX, which is why we don't get the simple "call / ret" code you suggest.</div><div><br></div><div>Finally, we miss the tail call opportunity because today we just give up if sret is present on either the caller of the callee. I think we could refine that to check for, do they agree, does the sret parameter match.</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Nov 24, 2018 at 9:20 AM Andrew Kelley <<a href="mailto:superjoe30@gmail.com">superjoe30@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Nov 24, 2018 at 12:11 PM Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<br>
><br>
> Llvm is trying to return RDI in RAX. It doesn't trust the callee to do it, because that was a bug that we fixed long ago.<br>
<br>
You're saying these extra instructions are working around a bug that<br>
no longer exists? Can they be removed now?<br>
<br>
What was the bug? Why can't the callee be trusted?<br>
<br>
><br>
> On Fri, Nov 23, 2018, 11:49 AM Andrew Kelley via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> wrote:<br>
>><br>
>> When compiling this LLVM IR with -O0 (no optimizations)<br>
>><br>
>> define internal fastcc void @bar2(%Bar* nonnull sret) unnamed_addr #2 !dbg !74 {<br>
>> Entry:<br>
>>   call fastcc void @bar(%Bar* sret %0), !dbg !79<br>
>>   ret void, !dbg !81<br>
>> }<br>
>><br>
>> why does this generate this?<br>
>><br>
>> 0000000000000090 <bar2>:<br>
>>   90:    55                       push   %rbp<br>
>>   91:    48 89 e5                 mov    %rsp,%rbp<br>
>>   94:    48 83 ec 10              sub    $0x10,%rsp<br>
>>   98:    48 89 f8                 mov    %rdi,%rax<br>
>>   9b:    48 89 45 f8              mov    %rax,-0x8(%rbp)<br>
>>   9f:    e8 0c 00 00 00           callq  b0 <bar><br>
>>   a4:    48 8b 45 f8              mov    -0x8(%rbp),%rax<br>
>>   a8:    48 83 c4 10              add    $0x10,%rsp<br>
>>   ac:    5d                       pop    %rbp<br>
>>   ad:    c3                       retq<br>
>>   ae:    66 90                    xchg   %ax,%ax<br>
>><br>
>><br>
>> instead of something like this?<br>
>><br>
>> 0000000000000090 <bar2>:<br>
>>   9f:    e8 0c 00 00 00           callq  b0 <bar><br>
>>   ad:    c3                       retq<br>
>><br>
>> when I add `musttail` to the IR it gives me this assembly:<br>
>><br>
>> 00000000000000a0 <bar2>:<br>
>>   a0:    55                       push   %rbp<br>
>>   a1:    48 89 e5                 mov    %rsp,%rbp<br>
>>   a4:    48 83 ec 10              sub    $0x10,%rsp<br>
>>   a8:    48 89 f8                 mov    %rdi,%rax<br>
>>   ab:    48 89 45 f8              mov    %rax,-0x8(%rbp)<br>
>>   af:    48 83 c4 10              add    $0x10,%rsp<br>
>>   b3:    5d                       pop    %rbp<br>
>>   b4:    e9 07 00 00 00           jmpq   c0 <bar><br>
>>   b9:    0f 1f 80 00 00 00 00     nopl   0x0(%rax)<br>
>><br>
>> which does not have a call instruction but it has prologue that I<br>
>> would not expect.<br>
>><br>
>> What's going on here? Is this something that can not really be<br>
>> improved without optimization passes?<br>
>> _______________________________________________<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>