[LLVMdev] llvm "iword" type

[Kenneth Uildriks]

On Mon, Aug 9, 2010 at 2:43 PM, Joshua Warner <joshuawarner32 at gmail.com> wrote:
> I looked through the "intp" thread.
>
> I don't really want to start that argument up again, but my immediate
> thought would be to create a new class of "picked-by-the-target" integer
> types (equivelents of size_t, intptr_t, etc...), and two new instructions,
> zcast and scast, which are only valid in the context of casting to / from
> integer types of unknown sizes.  To begin with, most passes could probably
> ignore (or otherwise pass pass over) these instructions.  The resolution of
> these types would only happen in the legalize phase in the SelectionDAG.
>
> Just my two cents...
>
> For now, I'll settle for a little architecture dependence in my front-end.
>
> Joshua

That might be your best bet.  There is more architecture dependence
that isn't trivial to get rid of:

1. The ABI varies from OS to OS on many platforms, and ABI details are
sometimes handled by llvm-gcc/clang rather than llc.  There's also at
least one case where a particular named type is passed/returned
differently from other types with the same structure.
2. Unions aren't really implemented in LLVM, and any front-end
implementations require knowledge of the platform (which union member
is the largest, the integer or the pointer?)
3. va_arg is handled specially be llvm-gcc/clang, because it's not
implemented on all platforms.

You can hide a lot of this in a platform dependent .bc file that you
ship with your front-end, or have your front-end build for you.
Support/TypeBuilder.h has some macros you might find useful for
generating a Module with a platform-independent API that does the
necessary typecasting for you to call platform-dependent stuff.
TypeBuilder takes a compile-type C/C++ type and turns it into an
llvm::Type*.