[LLVMdev] How to handle size_t in front ends?

[Chris Lattner]

On Wed, 7 May 2008, Jonathan S. Shapiro wrote:

>> On Wed, 2008-05-07 at 13:24 -0700, Chris Lattner wrote:
>> Querying TargetData only works if you know the size of the pointer. :)

> In the end, the use case that concerns me is things like character
> vectors, because of the fact that the index spans depend on the address
> space size. I'm not clear whether it is a goal to have an IR that is
> capable of being a neutral representation w.r.t. address space size. If
> it *is* a goal, then I don't see how to do it without some form of
> iIntPtr or iWord type, but I'm still very new to all this.

i64 should be big enough for this.  Just use i64.

>> > ÿÿ Treated an ordinary integer for all operations except casts.
>> 
>> Ok.  What does this mean for add?  This basically means that an intptr add 
>> cannot have usefully defined semantics.  Can you give an example of when 
>> it is useful?

>I had the same reaction. If it is lowered, then it should work normally
>for add. It is not quite as useless as you suggest, because things of
>the form add iIntPtr x iIntPtr -> iIntPtr will still work correctly
>after lowering is performed. I also see no reason why casts should be
>excluded at the IR level. That seems to me like a front end issue. At
>the IR level iIntPtr is just an late-bound integral type like any other.

i64 is available now.  When you inttoptr and i64 to a pointer on a 32-bit 
system, it takes the low bits.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/