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

Tue Nov 1 09:28:48 PDT 2016

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