Hi, 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?: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/thread.html#59387 Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140803/e7dd5227/attachment.html>
I'm very interested in this myself. Basically every single frontend has to plug in the same code to make this work, which seems to indicate to me that we need a place to put it to share amongst the frontends. On Mon, Aug 4, 2014 at 12:24 AM, Vadim Chugunov <vadimcn at gmail.com> wrote:> Hi, > 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?: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/thread.html#59387 > > Vadim > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >
On 4 Aug 2014, at 05:24, Vadim Chugunov <vadimcn at gmail.com> wrote:> Hi, > 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?: http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/thread.html#59387This 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. 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. 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. 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. David
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: 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. Vadim On Mon, Aug 4, 2014 at 1:23 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:> On 4 Aug 2014, at 05:24, Vadim Chugunov <vadimcn at gmail.com> wrote: > > > Hi, > > 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?: > http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-February/thread.html#59387 > > 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. > > 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. > > 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. > > 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. > > David > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140804/dfd56375/attachment.html>
On Tue, Aug 5, 2014 at 11:47 AM, Jonas Maebe <jonas.maebe at elis.ugent.be> wrote:> On 04/08/14 21:27, Vadim Chugunov wrote: > >> 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: >> 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. >> > > That's not the case. For example, many ABIs specify a specific way to pass > and return values of the "complex" type, which at the LLVM level just looks > like a struct with two float or double fields. >Huh, I didn't know that. So who treats "complex" differently than struct { float re, im; }? Fortran? Would any of the following be feasible then?: - if this special case is widespread, add a special attribute for "complex" to LLVM IR, - ignore this issue, and have Fortran compilers do manual lowering of "complex" arguments, but at least all "sane" languages could enjoy automatic lowering. Vadim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140805/9ea99498/attachment.html>
2014-08-05 17:22 GMT-07:00 Vadim Chugunov <vadimcn at gmail.com>:> On Tue, Aug 5, 2014 at 11:47 AM, Jonas Maebe <jonas.maebe at elis.ugent.be> > wrote: > >> On 04/08/14 21:27, Vadim Chugunov wrote: >> >>> 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: >>> 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. >>> >> >> That's not the case. For example, many ABIs specify a specific way to >> pass and return values of the "complex" type, which at the LLVM level just >> looks like a struct with two float or double fields. >> > > Huh, I didn't know that. So who treats "complex" differently than struct > { float re, im; }? Fortran? >Not just Fortran. For example, for X86_64 clang returns complex<float> as a vector, but complex<double> as a structure. For X86 I think it returns them using an extra pointer argument.> > Would any of the following be feasible then?: > - if this special case is widespread, add a special attribute for > "complex" to LLVM IR, > - ignore this issue, and have Fortran compilers do manual lowering of > "complex" arguments, but at least all "sane" languages could enjoy > automatic lowering. > > Vadim > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140805/fe3a98e3/attachment.html>
On 06 Aug 2014, at 02:22, Vadim Chugunov wrote:> On Tue, Aug 5, 2014 at 11:47 AM, Jonas Maebe <jonas.maebe at elis.ugent.be> > wrote: > >> That's not the case. For example, many ABIs specify a specific way to pass >> and return values of the "complex" type, which at the LLVM level just looks >> like a struct with two float or double fields. > Huh, I didn't know that. So who treats "complex" differently than struct { > float re, im; }? Fortran?It's not about languages, but about ABIs. Jonas
Seemingly Similar Threads
- [LLVMdev] [lldb-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>
- [LLVMdev] Emit code for 'unreachable'
- [LLVMdev] Emit code for 'unreachable'
- [LLVMdev] [lldb-dev] RFC: LLVM should require a working C++11 <thread>, <mutex>, and <atomic>
- [LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR