llvm dev - Aug 2014 - [LLVMdev] Argument Lowering Redux

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#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

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