<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, 30 Jun 2015 at 06:02 Hal Finkel <<a href="mailto:hfinkel@anl.gov">hfinkel@anl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">----- 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 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 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 in definite need of a solution. However, I also think that we really need to work from Clang's logic here: We don't want to have two different implementations of the ABI rules. They're complicated (and subtle), and it is hard enough to have one correct implementation in our C/C++ compiler. Given that we're talking about the C/C++ ABI, this is a perfectly appropriate place for the logic to live. The issue, as you well know, is that other languages need to interact with C/C++ functions, and so need to 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 can be used by external clients (just as Clang's AST headers are available to external clients).<br>
<br>
 2. 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></blockquote><div><br></div><div>This is what I was thinking of doing for llgo in the long term. 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=KBp19UM3iITGuqoAd3vLmifO2gD70ChLl1x97nXTNX0&s=gqC0X9GXkUEaxXYrOUgu7WjLcD1I0svET1N3hV08_UE&e=">http://llvm.org/klaus/llgo/blob/master/irgen/cabi.go</a>. It would be nice to have a simplified API to TargetInfo, ideally with a C API that other languages to can easily bind to. Stephen, if you do go down that route, I'd be keen to hear about it.</div><div><br></div><div>Cheers,</div><div>Andrew</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 -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=KBp19UM3iITGuqoAd3vLmifO2gD70ChLl1x97nXTNX0&s=BdBIt7q6A8cN_SAtchCRCbpRo4qcib4Igc2nM3quaRc&e=" rel="noreferrer" target="_blank">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=KBp19UM3iITGuqoAd3vLmifO2gD70ChLl1x97nXTNX0&s=vLXZRg7mX_lhuTaQtNSdKuZhKPnbxCsY4I60FAdFFcc&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>