<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 9, 2016 at 4:04 PM, James Y Knight <span dir="ltr"><<a href="mailto:jyknight@google.com" target="_blank">jyknight@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="auto"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>IMO, the LLVM function definitions should be a straightforward transformation from the C function signatures, and clang should stop mangling the function signatures with its own intimate knowledge of the calling convention rules.</div><div><br></div><div>Instead, clang could emit (still ABI-specific!) annotations on the arguments that communicates the *properties* of the source-language types which affect the ABI. LLVM, then, would use that information to implement the complete calling convention. No counting of numbers of registers in Clang to put "inreg" markers in the right places, or byval, or any of that sort of stuff it has to do today.</div></div></div></div></div></blockquote><div><br></div><div>Clang's ABI lowering is part of why I don't want to pattern match alloca+store in LLVM. Today here is how we pass 'struct P { double x, y; }' on x86_64-linux:</div><div><div><br></div><div>define void @f(double %p.coerce0, double %p.coerce1) #0 {</div><div>entry:</div><div>  %p = alloca %struct.P, align 8</div><div>  %0 = bitcast %struct.P* %p to { double, double }*</div><div>  %1 = getelementptr inbounds { double, double }, { double, double }* %0, i32 0, i32 0</div><div>  store double %p.coerce0, double* %1, align 8</div><div>  %2 = getelementptr inbounds { double, double }, { double, double }* %0, i32 0, i32 1</div><div>  store double %p.coerce1, double* %2, align 8</div><div>  ret void</div><div>}</div></div><div><br></div><div>My proposal doesn't make this any better so long as we split these things in the frontend, so let's assume we go the direction you propose, so that we receive just one %struct.P value. I'm pretty sure full FCA stores are non-canonical, so after optimizations, this is what we'd have to pattern match in the backend:</div><div><br></div><div><div>define void @f(%struct.P %p) #0 {</div><div>  %p.addr = alloca %struct.P, align 8</div><div>  %x.addr = getelementptr inbounds %struct.P, %struct.P* %0, i32 0, i32 0</div><div>  %x = extractvalue %struct.P %p, 0</div><div>  store double %x, double* %x.addr, align 8</div><div>  %y.addr = getelementptr inbounds %struct.P, %struct.P* %0, i32 0, i32 1</div><div>  %y = extractvalue %struct.P %p, 1<br></div><div>  store double %y, double* %y.addr, align 8</div><div>  ret void</div><div>}</div></div><div><br></div><div>This is doable, but I don't like it.</div><div><br></div><div>It's not clear if we have consensus to stop splitting structs in clang, but that is the direction I'd like to go in the future. It would also be a bit of a bitcode ABI break, similar to the way the byval change.</div></div></div></div>