<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 27, 2016 at 12:24 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div class="h5"><div dir="ltr">On Wed, Jul 27, 2016 at 12:15 AM Xinliang David Li <<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 26, 2016 at 11:27 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><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 class="gmail_quote"><span class="m_1274727794887442155m_1181047558039849170gmail-"><div dir="ltr">On Tue, Jul 26, 2016 at 11:19 PM Xinliang David Li <<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.com</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 class="gmail_extra"><div class="gmail_quote">On Tue, Jul 26, 2016 at 11:11 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><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 class="gmail_quote"><span><div dir="ltr">On Tue, Jul 26, 2016 at 11:08 PM Xinliang David Li via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@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">Hmm, why does Clang change the return type from from struct to i64?  Set aside whether it is always beneficial to do it or not, it certainly feels like the wrong place to make such a change.</div></blockquote><div><br></div></span><div>It's necessary to get the right ABI out of LLVM.</div><div><br></div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>what ABI issue and what can be wrong without using i64? I might have missed something obvious here.</div></div></div></div></blockquote><div><br></div></span><div>The ABI specifies that a struct such as this is returned in a single 64-bit integer register.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>yes, at least for system V ABI for x86_64.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </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 class="gmail_quote"><div><br></div><div>Consider this C++ test case:</div><div><div>long long a();</div><div><br></div><div>struct S { int i; float f; };</div><div>S b();</div><div><br></div><div>void f(long long *ptr1, S *ptr2) {</div><div>  *ptr1 = a();</div><div>  *ptr2 = b();</div><div>}</div></div><div><br></div><div>It compiles to:</div><div><div>        callq   _Z1av</div><div>        movq    %rax, (%rbx)</div><div>        callq   _Z1bv</div><div>        movq    %rax, (%r14)</div></div><div><br></div><div>Both need to be in the single register.</div><div><br></div><div>But if you consider the following IR:</div><div><div>declare i64 @a()</div><div>declare {i32, float} @b()</div><div><br></div><div>define void @f(i64* %ptr1, {i32, float}* %ptr2) {</div><div>entry:</div><div>  %calla = call i64 @a()</div><div>  store i64 %calla, i64* %ptr1</div><div>  %callb = call {i32, float} @b()</div><div>  store {i32, float} %callb, {i32, float}* %ptr2</div><div>  ret void</div><div>}</div></div><div><br></div><div>The LLVM lowering of the call to @b isn't what you want:</div><div><div>        callq   a</div><div>        movq    %rax, (%r14)</div><div>        callq   b</div><div>        movl    %eax, (%rbx)</div><div>        movss   %xmm0, 4(%rbx)</div></div><div><br></div><div>In order to get the ABI's semantics, we have to map the type into something that will actually get lowered in that exact manner.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Still, the FE does not seem to be the right place to fix the bug (considering multiple different FEs targeting LLVM). It seems to me this bug is either due to the call return lowering either happens too early or needs to be target dependent.<br></div></div></div></div></blockquote><div><br></div></div></div><div>I'm confused... What do you mean by "fix the bug"?</div><div><br></div><div>The performance bug? I don't think anyone has suggested the frontend -- the advice was to fix the performance issue *later* in the pipeline.</div><div><br></div><div>And I don't see a bug with the ABI lowering though, so I don't understand what you would mean by "fix the bug" in that context...</div></div></div></blockquote><div><br></div><div>As your example shows, if FE does not do target dependent IR generation, the LLVM lowered code would be wrong -- that is a bug in middle end IMO.</div><div><br></div><div>David</div></div><br></div></div>