[llvm-dev] What was the IR made for precisely?
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Mon Oct 31 10:53:46 PDT 2016
----- Original Message -----
> From: "Reid Kleckner" <rnk at google.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Chris Lattner" <clattner at apple.com>, "llvm-dev" <llvm-dev at lists.llvm.org>, "ジョウェットジェームス"
> <b3i4zz1gu1 at docomo.ne.jp>
> Sent: Monday, October 31, 2016 11:39:04 AM
> Subject: Re: [llvm-dev] What was the IR made for precisely?
>
>
> 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.
>
I think this is certainly possible. The question is: Is Clang going to use this representation? If not, who will want to maintain this separately from Clang?
To a large extent, this seems like factoring out the logic in Clang's lib/CodeGen/TargetInfo* (as well as lib/Basic/Target* and a few other places) into a reusable form.
-Hal
>
> 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
>
>
--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev
mailing list