[LLVMdev] Argument Lowering Redux

[Vadim Chugunov]

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>