[LLVMdev] Proposal: intp type

[Nick Lewycky]

Kenneth Uildriks wrote:
> On Tue, Nov 10, 2009 at 6:10 PM, Talin <viridia at gmail.com> wrote:
>> In my case, I've been attempting to build a target-neutral frontend. In my
>> tool chain, the target is specified at link time, not at compile time. Among
>> other things, that means that the same IR file can be used for multiple
>> targets.
> 
> That's the direction I'm going in too.
> 
>> What strikes me is how tantalizingly close LLVM comes to being able to do
>> this. I am surprised, for example, that I can general all of the DWARF
>> debugging structures without ever having to choose a target machine. Most
>> things can be done quite easily without knowing the exact size of a pointer.
>> When it comes to being able to "generate once, run anywhere", LLVM is like
>> 99.5% of the way there. Which makes that last remaining .5% particularly
>> vexing.
>>
>> There's only a tiny handful of fairly esoteric cases which require selecting
>> a target before you generate IR. Unfortunately, the "pointer the same size
>> as an int" is one of these rare cases -  it is something that is very
>> painful to try and work around. (A similar esoteric use case is: "which of
>> the following two types is larger, 3 x int32 or 2 x {}*? -- i.e. the union
>> problem.)
> 
> I'm willing to spend some time on adding intp to LLVM... my
> front-end's standard libraries would be cleaner and more portable that
> way.

Sorry, but I'm still opposed. From your description of 'intp' it sounds 
like it's a strict subset of pointers. You can't sext it, zext it or 
trunc it, like you can with integers. You can bitcast it, but only to 
another pointer.

The use case you mentioned was that some native system APIs want 
integers that are the same size as pointers. So why not just declare 
those arguments or fields with a pointer type in LLVM? Then you've got a 
field with the right size.

Nick