<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Chiming in from the LLILC project:</p>
<p><br>
</p>
<p>Overall, the idea of an ABI support library sounds great. It'd certainly save us a fair amount of duplicated effort in our frontend, as the CoreCLR ABI (mostly) corresonds to the native C ABI of its host platform. What we have today[1, 2] is largely inspired
by Clang, and so looks pretty similar to Stephen's existing work in llvm-abi.<span style="font-size:12pt"></span></p>
<div><br>
</div>
<div>> <span style="font-size:12pt">I like the idea of frontends using the library as a convenient API and</span></div>
> the library's implementation using code from Clang.
<div><br>
</div>
<div>Although I understand the motivations behind wrapping the Clang implementation, I'm a bit leery of this as a long-term direction. Admittedly, this is selfishly motivated: LLILC currently has no Clang dependency, and I think we'd prefer to avoid taking
one if possible. A reasonable compromise would be the refactoring Stephen suggested below (i.e. moving ABI-related code into its own library within Clang): </div>
<div><br>
</div>
<div>> <span style="font-size: 12pt;">My approach would be to just refactor the code to separate classes</span></div>
> within CodeGen and add the necessary headers to<br>
> include/clang/CodeGen/. It might make sense to create a separate<br>
> library directory (e.g. lib/ABI) but I expect there will be circular<br>
> dependency issues to overcome.
<div><br>
</div>
<div>Although the refactoring could be tricky, this would at least let external users limit their dependency to the new library rather than pulling in libCodeGen.</div>
<div><br>
</div>
Thanks,
<div>- Pat<br>
<br>
[1] <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dotnet_llilc_blob_master_include_Reader_abi.h&d=AwMFAw&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=T5mVTMCpHk4j_jHdY5vcY8284Hg-RKWdrdNMkjXFJW0&s=k1kn8KptRXB3_virdyZf3Cwiqbz3vClW2oVyctTXEYc&e=" id="LPlnk52522" title="https://github.com/dotnet/llilc/blob/master/include/Reader/abi.h
Ctrl+Click or tap to follow the link">https://github.com/dotnet/llilc/blob/master/include/Reader/abi.h</a><br>
[2] <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dotnet_llilc_blob_master_lib_Reader_abi.cpp&d=AwMFAw&c=8hUWFZcy2Z-Za5rBPlktOQ&r=CnzuN65ENJ1H9py9XLiRvC_UQz6u3oG6GUNn7_wosSM&m=T5mVTMCpHk4j_jHdY5vcY8284Hg-RKWdrdNMkjXFJW0&s=MgjtGRkT7TQIDInhowC9Fl4BzcRqfT4JV34HO2EAMFA&e=" id="LPlnk979396" title="https://github.com/dotnet/llilc/blob/master/lib/Reader/abi.cpp
Ctrl+Click or tap to follow the link">https://github.com/dotnet/llilc/blob/master/lib/Reader/abi.cpp</a><br>
<div><br>
<div style="color:rgb(0,0,0)">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> llvmdev-bounces@cs.uiuc.edu <llvmdev-bounces@cs.uiuc.edu> on behalf of Andrew Wilkins <axwalk@gmail.com><br>
<b>Sent:</b> Tuesday, June 30, 2015 6:24 PM<br>
<b>To:</b> Stephen Cross; Hal Finkel<br>
<b>Cc:</b> Clang Developers List; LLVM Developers Mailing List<br>
<b>Subject:</b> Re: [LLVMdev] [cfe-dev] llvm-abi: A library for generating ABI-compliant LLVM IR</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">On Wed, 1 Jul 2015 at 08:19 Stephen Cross <<a href="mailto:scross@scross.co.uk">scross@scross.co.uk</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
Hi everyone,<br>
<br>
I was wondering if anyone could answer the questions in my first<br>
email. These were:<br>
<br>
* Why does Clang generate 8 byte alignment for 16+ byte arrays on<br>
x86-64, even though the AMD64 ABI seems to require 16 byte alignment?<br>
* Clang has some logic in lib/Basic/Targets.cpp to determine CPU<br>
features, but LLVM also does the same task in its backend. Would it be<br>
possible to modify LLVM to expose this logic and modify Clang to use<br>
that?<br>
* (Slightly modified) Clang has some logic in lib/Driver/Tools.cpp<br>
('getCPUName') for selecting a generic CPU. Would it be sensible to<br>
expose this in a header in include/clang/Driver/?<br>
<br>
> Refactor the logic in Clang's lib/CodeGen/TargetInfo.cpp so that it can be used by external clients (just as Clang's AST headers are available to external clients).<br>
<br>
Yes, this sounds like a good approach. While I'm not entirely<br>
convinced this is where we want to end up (it doesn't seem right to<br>
split the ABI implementation between the frontend and the backend), I<br>
definitely agree this is a sensible starting point. Unless anyone is<br>
against this I'll start working out the changes needed under the<br>
assumption this is how I should proceed.<br>
<br>
My approach would be to just refactor the code to separate classes<br>
within CodeGen and add the necessary headers to<br>
include/clang/CodeGen/. It might make sense to create a separate<br>
library directory (e.g. lib/ABI) but I expect there will be circular<br>
dependency issues to overcome. The very first thing is probably to<br>
split each target's code out of TargetInfo.cpp; I'd suggest that the<br>
structure of CodeGen could mirror <llvm>/lib/Target/ so we'd have<br>
directories for ARM, PowerPC, X86 etc. What do you think?<br>
<br>
Note that there's also functionality in CGCall.cpp (and a few other<br>
files) which would need to be separated out to be usable for other<br>
frontends.<br>
<br>
> Write your library as a wrapper around that logic so that simple cases can be handled without burdening other frontends with the subtleties of Clang's AST data structures.<br>
<br>
This will be how it ends up, but while the modifications to Clang are<br>
ongoing llvm-abi is and will continue to be an entirely separate<br>
ABI-implementing codebase. This is just because the Loci frontend<br>
needs this functionality right now. I'm also expecting there will be<br>
functionality going into llvm-abi that for good reason won't be found<br>
in Clang. There's some duplication of effort here but it's<br>
unavoidable.<br>
<br>
I like the idea of frontends using the library as a convenient API and<br>
the library's implementation using code from Clang. I know that some<br>
frontends (including the Loci frontend) are designed to be able to be<br>
built on systems that could have slightly older versions of LLVM/Clang<br>
(for Loci, it's LLVM 3.3+), so this factor will have to be considered<br>
when integrating the code from Clang.<br>
<br>
> At the moment we have support for x86-64 only: <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_klaus_llgo_blob_master_irgen_cabi.go&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=-Iirv3ocYjaPGb9zIT82vHWpazIJhUFv6POGu334YXo&s=-HKcBselyiXmmBPOX9tN1pnpOIt82rdZWUAuus7TW4w&e=" rel="noreferrer" target="_blank">
http://llvm.org/klaus/llgo/blob/master/irgen/cabi.go</a>.<br>
<br>
I'll add other architectures to llvm-abi soon (it's largely a fairly<br>
trivial process of moving code from Clang and replacing its in-tree<br>
dependencies) so hopefully this will be useful. I can see from other<br>
non-Clang frontends that non-X86 support does tend to be at least<br>
quite incomplete.<br>
<br>
> It would be nice to have a simplified API to TargetInfo, ideally with a C API that other languages to can easily bind to.<br>
<br>
Absolutely, I agree. I appear to be in the rare situation of having a<br>
frontend written in C++ (i.e. not self-hosting) but I know most<br>
frontends rely on having a C API.<br>
<br>
It seems like the approach to this should be to have a C API in<br>
llvm-abi that wraps around its C++ API. Unfortunately my time is<br>
currently fairly thin-spread; would you be able to contribute to this<br>
effort?<br>
</blockquote>
<div><br>
</div>
<div>Sounds good. My time is likewise thinly spread, but I'll be happy to contribute to the effort when I can.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Andrew</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
Thanks,<br>
Stephen<br>
<br>
On Tue, Jun 30, 2015 at 12:47 AM, Andrew Wilkins <<a href="mailto:axwalk@gmail.com" target="_blank">axwalk@gmail.com</a>> wrote:<br>
> On Tue, 30 Jun 2015 at 06:02 Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br>
>><br>
>> ----- Original Message -----<br>
>> > From: "Stephen Cross" <<a href="mailto:scross@scross.co.uk" target="_blank">scross@scross.co.uk</a>><br>
>> > To: "Reid Kleckner" <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>><br>
>> > Cc: "Clang Developers List" <<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a>>, "LLVM Developers<br>
>> > Mailing List" <<a href="mailto:llvmdev@cs.uiuc.edu" target="_blank">llvmdev@cs.uiuc.edu</a>><br>
>> > Sent: Monday, June 29, 2015 3:03:40 PM<br>
>> > Subject: Re: [cfe-dev] llvm-abi: A library for generating ABI-compliant<br>
>> > LLVM IR<br>
>> ><br>
>> > Hi Reid,<br>
>> ><br>
>> > Thanks for your response.<br>
>> ><br>
>> > The issue is that every LLVM frontend needing ABI compliance has to<br>
>> > re-implement the same target-dependent logic, which is a significant<br>
>> > burden; the ABI compliance code inside Clang isn't really usable for<br>
>> > other frontends as-is. We haven't got many good options here :-). I<br>
>> > think a lot of people would've hoped that LLVM would provide the<br>
>> > means<br>
>> > for achieving ABI compliance (at least for C), though I'm well aware<br>
>> > of the complexity involved and understand the decisions taken thus<br>
>> > far.<br>
>> ><br>
>> > Within this context, llvm-abi is an immediately actionable way of<br>
>> > sharing code between frontends, that should lead to a higher quality<br>
>> > codebase for a significantly reduced effort on everyone's part. It<br>
>> > seems like this would further build on LLVM's success because I think<br>
>> > many people would like to generate code that can interact with C<br>
>> > APIs.<br>
>> ><br>
>> > Ultimately it would be great to see this functionality be provided in<br>
>> > an accessible form inside LLVM and hence for Clang to use that<br>
>> > functionality. This would move much of the target-dependent logic out<br>
>> > of Clang while at the same time making this functionality available<br>
>> > to<br>
>> > other LLVM-based tools.<br>
>> ><br>
>> > I am sure this is a substantial and complex long term project, but I<br>
>> > think it is a worthwhile aim. Do you (and the LLVM community as a<br>
>> > whole) agree? (Acknowledging that some of the details would need to<br>
>> > be<br>
>> > worked out.)<br>
>> ><br>
>> > I have a long term and substantial interest in this (as I expect do<br>
>> > other frontend developers), so I'm willing to contribute significant<br>
>> > effort to move this forward. Hopefully the llvm-abi library can<br>
>> > provide a better understanding of what needs to be represented and<br>
>> > help non-Clang frontends :-).<br>
>> ><br>
>> > Implementation-wise the changes to LLVM could involve encoding ABI<br>
>> > information into LLVM IR or simply providing C++ APIs for generating<br>
>> > ABI-compliant code inside LLVM (much like llvm-abi). Each solution<br>
>> > has<br>
>> > advantages and disadvantages and I'm planning to make a proposal<br>
>> > about<br>
>> > this on the mailing list later (hence I'd suggest leaving that<br>
>> > discussion until I make the proposal).<br>
>> ><br>
>> > In terms of the mentioned deficiencies of the Type structure, these<br>
>> > are all problems that I intend to address (it would be great if you<br>
>> > could provide details on any of the more difficult areas).<br>
>><br>
>> First, let me say that I also think this is an incredibly important area<br>
>> in definite need of a solution. However, I also think that we really need to<br>
>> work from Clang's logic here: We don't want to have two different<br>
>> implementations of the ABI rules. They're complicated (and subtle), and it<br>
>> is hard enough to have one correct implementation in our C/C++ compiler.<br>
>> Given that we're talking about the C/C++ ABI, this is a perfectly<br>
>> appropriate place for the logic to live. The issue, as you well know, is<br>
>> that other languages need to interact with C/C++ functions, and so need to<br>
>> understand the C/C++ ABI. My recommended strategy is this:<br>
>><br>
>> 1. Refactor the logic in Clang's lib/CodeGen/TargetInfo.cpp so that it<br>
>> can be used by external clients (just as Clang's AST headers are available<br>
>> to external clients).<br>
>><br>
>> 2. Write your library as a wrapper around that logic so that simple cases<br>
>> can be handled without burdening other frontends with the subtleties of<br>
>> Clang's AST data structures.<br>
><br>
><br>
> This is what I was thinking of doing for llgo in the long term. At the<br>
> moment we have support for x86-64 only:<br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_klaus_llgo_blob_master_irgen_cabi.go&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=-Iirv3ocYjaPGb9zIT82vHWpazIJhUFv6POGu334YXo&s=-HKcBselyiXmmBPOX9tN1pnpOIt82rdZWUAuus7TW4w&e=" rel="noreferrer" target="_blank" title="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_klaus_llgo_blob_master_irgen_cabi.go&amp;d=AwMFaQ&amp;c=8hUWFZcy2Z-Za5rBPlktOQ&amp;r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&amp;m=-Iirv3ocYjaPGb9zIT82vHWpazIJhUFv6POGu334YXo&amp;s=-HKcBselyiXmmBPOX9tN1pnpOIt82rdZWUAuus7TW4w&amp;e=
Ctrl+Click or tap to follow the link">
http://llvm.org/klaus/llgo/blob/master/irgen/cabi.go</a>. It would be nice to<br>
> have a simplified API to TargetInfo, ideally with a C API that other<br>
> languages to can easily bind to. Stephen, if you do go down that route, I'd<br>
> be keen to hear about it.<br>
><br>
> Cheers,<br>
> Andrew<br>
><br>
>> -Hal<br>
>><br>
>> ><br>
>> > Thanks again,<br>
>> > Stephen<br>
>> ><br>
>> > On Mon, Jun 29, 2015 at 7:32 PM, Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>><br>
>> > wrote:<br>
>> > > I agree it would be really nice to build a library for ABI<br>
>> > > lowering, but any<br>
>> > > solution that isn't clang or isn't ultimately picked up by clang<br>
>> > > will<br>
>> > > necessarily be incomplete. Perhaps that is OK for your frontend's<br>
>> > > uses, but<br>
>> > > I think it's the main reason that we haven't done something like<br>
>> > > this in<br>
>> > > LLVM already.<br>
>> > ><br>
>> > > Any solution that doesn't involve actual Clang ASTs is unlikely to<br>
>> > > be able<br>
>> > > to represent all C-with-extensions types (unions, bitfields,<br>
>> > > alignment<br>
>> > > attributes, transparent_union attribute). I took a look at Type.hpp<br>
>> > > in your<br>
>> > > project, and it seems to be missing some of these things. Keeping<br>
>> > > such a<br>
>> > > library up to date with new extensions is going to be a maintenance<br>
>> > > burden.<br>
>> > ><br>
>> > > That said, I wish you luck, and I hope the project eases some of<br>
>> > > the<br>
>> > > difficulties for new frontends. It is very possible that the corner<br>
>> > > cases<br>
>> > > that keep me up at night are not the problems that users actually<br>
>> > > face. :)<br>
>> > ><br>
>> > > On Sun, Jun 28, 2015 at 3:22 PM, Stephen Cross<br>
>> > > <<a href="mailto:scross@scross.co.uk" target="_blank">scross@scross.co.uk</a>> wrote:<br>
>> > >><br>
>> > >> Hi everyone,<br>
>> > >><br>
>> > >> (Also CC'ed cfe-dev since this seems relevant to Clang,<br>
>> > >> particularly<br>
>> > >> the questions at the end.)<br>
>> > >><br>
>> > >> I've been working on a library to generate LLVM IR that complies<br>
>> > >> with<br>
>> > >> platform ABIs (the current focus is on C but I'm also interested<br>
>> > >> in<br>
>> > >> ABIs for other languages).<br>
>> > >><br>
>> > >> You can find it here: <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_scross99_llvm-2Dabi&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=-Iirv3ocYjaPGb9zIT82vHWpazIJhUFv6POGu334YXo&s=hV2-aaQYIMI-S0TwecPz9lEQSKeHNzTLe0H6uDJ7rHU&e=" rel="noreferrer" target="_blank" title="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_scross99_llvm-2Dabi&amp;d=AwMFaQ&amp;c=8hUWFZcy2Z-Za5rBPlktOQ&amp;r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&amp;m=-Iirv3ocYjaPGb9zIT82vHWpazIJhUFv6POGu334YXo&amp;s=hV2-aaQYIMI-S0TwecPz9lEQSKeHNzTLe0H6uDJ7rHU&amp;e=
Ctrl+Click or tap to follow the link">
https://github.com/scross99/llvm-abi</a><br>
>> > >><br>
>> > >> To explain further (for those who are unfamiliar), LLVM frontends<br>
>> > >> have<br>
>> > >> to modify function argument types, attributes etc. in order to<br>
>> > >> ensure<br>
>> > >> the backend generates code that satisfies the ABI; this is needed<br>
>> > >> because LLVM's type system can't encode all the necessary<br>
>> > >> information.<br>
>> > >> This is a complex task and involves substantial amounts of<br>
>> > >> target-dependent logic. Clang performs this encoding and indeed<br>
>> > >> much<br>
>> > >> of the current functionality is derived from Clang's source.<br>
>> > >><br>
>> > >> This project originated as a necessary piece of functionality for<br>
>> > >> the<br>
>> > >> Loci compiler frontend [1] and is now an external dependency; my<br>
>> > >> aim<br>
>> > >> is to make this usable for other LLVM frontends that also need to<br>
>> > >> generate ABI-compliant IR (I assume this is a fairly large subset<br>
>> > >> of<br>
>> > >> the frontends).<br>
>> > >><br>
>> > >> I'd be very interested in any suggestions/queries/comments.<br>
>> > >><br>
>> > >> I made a few interesting discoveries while working on this:<br>
>> > >><br>
>> > >> * Clang generates 8 byte alignment for 16+ byte arrays on x86-64,<br>
>> > >> even<br>
>> > >> though the AMD64 ABI seems to require that arrays of 16+ bytes are<br>
>> > >> aligned to 16 bytes. Is this a bug or am I missing something<br>
>> > >> obvious?<br>
>> > >><br>
>> > >> * Clang determines the features for a CPU (e.g. whether we have<br>
>> > >> AVX<br>
>> > >> support on x86-64 CPUs), even though this functionality is already<br>
>> > >> available in LLVM (but appears to be very difficult to query).<br>
>> > >> Would<br>
>> > >> it be possible to expose the information from LLVM and hence<br>
>> > >> eliminate<br>
>> > >> the duplication in Clang?<br>
>> > >><br>
>> > >> * Clang determines a 'generic CPU' if the user doesn't specify a<br>
>> > >> CPU.<br>
>> > >> My understanding is that we don't usually generate code for the<br>
>> > >> native<br>
>> > >> CPU because it may have features unavailable on other similar<br>
>> > >> CPUs.<br>
>> > >> LLVM can provide full details of the native CPU but can't<br>
>> > >> determine a<br>
>> > >> generic CPU; could this functionality be added to LLVM?<br>
>> > >><br>
>> > >> (Separately I've also been considering a proposal to add ABI<br>
>> > >> information directly inside LLVM IR in a language-independent way<br>
>> > >> and<br>
>> > >> I'll discuss this in a later email.)<br>
>> > >><br>
>> > >> Thanks,<br>
>> > >> Stephen<br>
>> > >><br>
>> > >> [1] <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_scross99_locic&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=-Iirv3ocYjaPGb9zIT82vHWpazIJhUFv6POGu334YXo&s=AYIqYKlv0AVTlDWgGXreFzgK6cUAfCWlBmV24CfMtsA&e=" rel="noreferrer" target="_blank">
https://github.com/scross99/locic</a><br>
>> > >> _______________________________________________<br>
>> > >> cfe-dev mailing list<br>
>> > >> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
>> > >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>> > ><br>
>> > ><br>
>> > _______________________________________________<br>
>> > cfe-dev mailing list<br>
>> > <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
>> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>> ><br>
>><br>
>> --<br>
>> Hal Finkel<br>
>> Assistant Computational Scientist<br>
>> Leadership Computing Facility<br>
>> Argonne National Laboratory<br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>