(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  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
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.)