Reid Kleckner via llvm-dev
2016-Oct-31 16:39 UTC
[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. 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>
Hal Finkel via llvm-dev
2016-Oct-31 17:53 UTC
[llvm-dev] What was the IR made for precisely?
----- 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
Mehdi Amini via llvm-dev
2016-Nov-01 16:28 UTC
[llvm-dev] What was the IR made for precisely?
> On Oct 31, 2016, at 10:53 AM, Hal Finkel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > ----- Original Message ----- >> From: "Reid Kleckner" <rnk at google.com <mailto:rnk at google.com>> >> To: "Hal Finkel" <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> >> Cc: "Chris Lattner" <clattner at apple.com <mailto:clattner at apple.com>>, "llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>, "ジョウェットジェームス" >> <b3i4zz1gu1 at docomo.ne.jp <mailto: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.I share this view, and I’d like a solution that would be used by clang by default! (Mostly for the reason hinted above in the question: “who will want to maintain this separately from Clang?”) — Mehdi> >> >> 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 > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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/20161101/778da195/attachment.html>