<div dir="ltr"><div dir="ltr">On Tue, Jan 15, 2019 at 9:24 AM David Greene via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">David Chisnall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> writes:<br>
<br>
> I'm not opposed to this in principle, and actually I'd quite like to<br>
> move in this direction and remove our reliance on undocumented and<br>
> inconsistent conventions between the back end and the front end for<br>
> conveying information about ABIs.  For example, returning two 32-bit<br>
> integers or a pair of pointers on x86-32 requires returning the result<br>
> in a single i64 in LLVM IR (on platforms where small structs are<br>
> returned in registers, not on Linux), which is not particularly<br>
> helpful for analysis or consistent with any other architecture.  Given<br>
> that front ends have to be aware of calling conventions, it would be<br>
> nice if they could express them in the same way that the ABI<br>
> references do...<br>
<br>
+1.  Coordinating ABI semantics between the frontend and LLVM is tricky.<br>
It would be super helpful to have a formal way of expressing ABI<br>
semantics in the IR.<br></blockquote><div><br></div><div>I agree with that, but I think most users want LLVM to go the other way from what the OP is suggesting. I think non-clang frontends would prefer it if we pushed more calling convention details down into LLVM, not the other way around.</div><div><br></div><div>Regarding the original proposal, sure, we could probably support a calling convention that explicitly assigns arguments to same-sized registers. But I doubt that it will ever be expressive enough to handle the corner cases of HVA and struct passing. Those are the areas where other frontends typically run into ABI compatibility problems. So, we can definitely add a convention that explicitly assigns registers, but we should document that it's really only going to handle the easy cases of assigning register-sized arguments to appropriately sized registers. </div><div><br></div><div>I suggest that the convention use string attributes, instead of attributes that point to metadata. We don't have any facilities to allow attributes to point to metadata, but we already support string attributes on functions, and it should be easy to extend the IR parsing to support an argument attribute that looks like `hwreg("rax,rdx")`. I don't think it will impact bitcode serialization, but I could be wrong. For the list of CSRs, you can add an attribute like `"calleesavedregs"="rbx,rcx"` to the function's attribute set. That won't require any bitcode or IR parser modifications.</div><div><br></div><div>Hope that helps!</div></div></div>