[LLVMdev] llvm "iword" type

[Kenneth Uildriks]

On Mon, Aug 9, 2010 at 4:08 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote:
> On Mon, Aug 9, 2010 at 4:02 PM, Joshua Warner <joshuawarner32 at gmail.com> wrote:
>>
>>
>> On Mon, Aug 9, 2010 at 1:51 PM, Kenneth Uildriks <kennethuil at gmail.com>
>> wrote:
>>>
>>> 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*.
>>
>> For a platform-dependent .bc file, are you suggesting something like a
>> defining a i8* @mask_lower_bits(i8*), one per platform, in different .bc
>> files (linked in just before final code generation)?
>> Then, I would just declare that function in each module I emit, call it
>> whenever appropriate, and trust llvm to inline it?  ...I kind of like that
>> idea.  That would allow my front-end (until it invokes the optimizer, at
>> least) not to worry about sizes of pointers, etc.  I have no need of unions
>> or va_arg, and the code I'm generating already has a layer of insulation
>> between it and all external APIs anyway.
>>
>> Thanks!
>>
>> Joshua
>>
>>
> Yes, something like that would work.  I have a bunch of platform
> dependent stuff I'm trying to insulate, so I'm creating a tool that
> runs when building my front-end that uses the LLVM libraries to
> generate a .bc file full of that stuff for me, but that might be
> overill for your case.
>