[llvm-dev] What was the IR made for precisely?

[Reid Kleckner via llvm-dev]

I think it would be possible to build a stripped-down
C-with-extensions-only type representation that represents only the types
that have interesting ABI implications. This includes several things not
present in LLVM IR types: _Complex, union, flexible array members,
alignment attributes, etc. We could either then use that library to
generate LLVM IR, or embed it in the IR for use at call sites.

You can exclude C++ because, for the most part, C++ types are either passed
indirectly or as the analogous C struct would be passed. Some work would be
needed to support packing fields into base tail padding, but that's not too
bad.

On Fri, Oct 28, 2016 at 1:25 PM, Hal Finkel via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> ----- Original Message -----
> > From: "Chris Lattner via llvm-dev" <llvm-dev at lists.llvm.org>
> > To: "David Chisnall" <David.Chisnall at cl.cam.ac.uk>
> > Cc: llvm-dev at lists.llvm.org, "ジョウェットジェームス" <b3i4zz1gu1 at docomo.ne.jp>
> > Sent: Friday, October 28, 2016 2:13:06 PM
> > Subject: Re: [llvm-dev] What was the IR made for precisely?
> >
> >
> > > On Oct 28, 2016, at 1:21 AM, David Chisnall
> > > <David.Chisnall at cl.cam.ac.uk> wrote:
> > >
> > > On 28 Oct 2016, at 02:43, ジョウェットジェームス <b3i4zz1gu1 at docomo.ne.jp>
> > > wrote:
> > >>
> > >> I would need to sum up all the rules and ABIs and sizes for all
> > >> the targets I need and generate different IR for each, am I
> > >> correct?
> > >
> > > This is a long-known limitation of LLVM IR and there are a lot of
> > > proposals to fix it.  It would be great if the LLVM Foundation
> > > would fund someone to do the work, as it isn’t a sufficiently high
> > > priority for any of the large LLVM consumers and would make a huge
> > > difference to the utility of LLVM for a lot of people.
> > …
> > > I think it would be difficult to do it within the timescale of the
> > > GSoC unless the student was already an experienced LLVM developer.
> > >  It would likely involve designing some good APIs (difficult!),
> > > refactoring a bunch of Clang code, and creating a new LLVM
> > > library.  I’ve not seen a GSoC project on this scale succeed in
> > > any of the open source projects that I’ve been involved with.  If
> > > we had a good design doc and a couple of engaged mentors then it
> > > might stand a chance.
> >
> > Is there a specific design that you think would work?  One of the
> > major problems with this sort of proposal is that you need the
> > entire clang type system to do this, which means it depends on a
> > huge chunk of the Clang AST.  At that point, this isn’t a small
> > library that clang uses, this is a library layered on top of Clang
> > itself.
>
> Given that ABIs are defined in terms of C (and sometimes now C++) language
> constructs, I think that something like this is the best of all bad
> options. Really, however, it depends only on the AST and CodeGen, and maybe
> those (along with 'Basic', etc.) could be made into a separately-compilable
> library. Along with an easy ASTBuilder for C types and function
> declarations we should be able to satisfy this use case.
>
>  -Hal
>
> >
> > -Chris
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161031/b97419c9/attachment.html>