<div dir="ltr"><div><div>I am not pretending to understand all corner cases in this, but as I was reading that old thread, a question popped up in my mind: <br>Couldn't LLVM provide an early IR transform pass that lowers "high-level" argument definitions into the current target-dependent form, converting by-value structs into sret arguments as needed?   It seems to me that, at least for structs, all information that such a pass would require, is representable in the current LLVM IR.  Of course, under this proposal, unions would need to be re-introduced into IR in some form (perhaps as structs tagged with a "union" flag?).  However, if they are immediately lowered into structs, the rest of optimization pipeline would not need to change.<br>
<br></div></div>Vadim<br><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 4, 2014 at 1:23 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 4 Aug 2014, at 05:24, Vadim Chugunov <<a href="mailto:vadimcn@gmail.com">vadimcn@gmail.com</a>> wrote:<br>

<br>
> Hi,<br>
> Having just found an ABI conformance bug in a compiler front-end, I am curious: is the state of target-independent argument lowering in LLVM still the same as when this thread was taking place?: <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/thread.html#59387" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/thread.html#59387</a><br>

<br>
</div>This comes up periodically.  The consensus last time was that LLVM should have some sort of ABIBuilder class that would take C types (as most ABIs are defined in terms of C types) and allow building function definitions and calls from them.  Inside the function, you'd get an alloca containing each C parameter.  Unfortunately, no one has had the combination of time, inclination, and expertise to do it.<br>

<br>
Each back end would then be responsible for maintaining its corresponding ABIBuilder, to ensure that it expected in the IR is what the ABIBuilder produces.<br>
<br>
The other problem is that the current approach in LLVM IR complicates optimisations.  It's bad enough that clang and the x86 back end both have to somehow know that an i64 return value is returned in two integer registers and so is the correct thing to use (on some platforms) for a struct of two i32s.  It's even worse that an optimisation has to know that the i64 that a function is returning might actually be a structure.<br>

<br>
It is probably the ugliest bit of LLVM IR currently, that we have front ends that all either consume C or know how to map their values to C types, and have back ends that must implement ABIs defined in specifications in terms of C types, but we insist on mapping this knowledge to something different in the middle.<br>

<span class="HOEnZb"><font color="#888888"><br>
David<br>
<br>
</font></span></blockquote></div><br></div>