[cfe-dev] llvm-abi: A library for generating ABI-compliant LLVM IR

[Reid Kleckner]

I agree it would be really nice to build a library for ABI lowering, but
any solution that isn't clang or isn't ultimately picked up by clang will
necessarily be incomplete. Perhaps that is OK for your frontend's uses, but
I think it's the main reason that we haven't done something like this in
LLVM already.

Any solution that doesn't involve actual Clang ASTs is unlikely to be able
to represent all C-with-extensions types (unions, bitfields, alignment
attributes, transparent_union attribute). I took a look at Type.hpp in your
project, and it seems to be missing some of these things. Keeping such a
library up to date with new extensions is going to be a maintenance burden.

That said, I wish you luck, and I hope the project eases some of the
difficulties for new frontends. It is very possible that the corner cases
that keep me up at night are not the problems that users actually face. :)

On Sun, Jun 28, 2015 at 3:22 PM, Stephen Cross <scross at scross.co.uk> wrote:

> Hi everyone,
>
> (Also CC'ed cfe-dev since this seems relevant to Clang, particularly
> the questions at the end.)
>
> I've been working on a library to generate LLVM IR that complies with
> platform ABIs (the current focus is on C but I'm also interested in
> ABIs for other languages).
>
> You can find it here: https://github.com/scross99/llvm-abi
>
> To explain further (for those who are unfamiliar), LLVM frontends have
> to modify function argument types, attributes etc. in order to ensure
> the backend generates code that satisfies the ABI; this is needed
> because LLVM's type system can't encode all the necessary information.
> This is a complex task and involves substantial amounts of
> target-dependent logic. Clang performs this encoding and indeed much
> of the current functionality is derived from Clang's source.
>
> This project originated as a necessary piece of functionality for the
> Loci compiler frontend [1] and is now an external dependency; my aim
> is to make this usable for other LLVM frontends that also need to
> generate ABI-compliant IR (I assume this is a fairly large subset of
> the frontends).
>
> I'd be very interested in any suggestions/queries/comments.
>
> I made a few interesting discoveries while working on this:
>
> * Clang generates 8 byte alignment for 16+ byte arrays on x86-64, even
> though the AMD64 ABI seems to require that arrays of 16+ bytes are
> aligned to 16 bytes. Is this a bug or am I missing something obvious?
>
> * Clang determines the features for a CPU (e.g. whether we have AVX
> support on x86-64 CPUs), even though this functionality is already
> available in LLVM (but appears to be very difficult to query). Would
> it be possible to expose the information from LLVM and hence eliminate
> the duplication in Clang?
>
> * Clang determines a 'generic CPU' if the user doesn't specify a CPU.
> My understanding is that we don't usually generate code for the native
> CPU because it may have features unavailable on other similar CPUs.
> LLVM can provide full details of the native CPU but can't determine a
> generic CPU; could this functionality be added to LLVM?
>
> (Separately I've also been considering a proposal to add ABI
> information directly inside LLVM IR in a language-independent way and
> I'll discuss this in a later email.)
>
> Thanks,
> Stephen
>
> [1] https://github.com/scross99/locic
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150629/2be1348d/attachment.html>