[LLVMdev] How to handle size_t in front ends?

[Chris Lattner]

On Wed, 7 May 2008, Gordon Henriksen wrote:
>> What would this be used for?  How is it defined?  How does
>> arithmetic work on it?
>
> Looking up the intptr type via TargetData is not a significant issue
> for me, but I can see the appeal, and how its absence could constitute
> a significant barrier to generating portable IR (provided, of course,
> a portable language). Regardless, it would allow me to hardcode a good
> deal more codegen if the LLVM IR had an intptr type. The semantics I
> would imagine for an intptr type are:

Querying TargetData only works if you know the size of the pointer. :)

> • Lowered to i32 or i64 for code generation.

Ok

> • 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?

> • Can be the operand to ptrtoint, but not the result.
> • Can be the result of inttoptr, but not the operand.

I assume these are backwards.  intptr_t is an integer, not a pointer.

> • Can be bitcast to an actual pointer type.

No. int <-> ptr is done with inttoptr and ptrtoint.

> • Whether sext, zext, and trunc are applicable, I could be convinced
> either way. It muddies the semantics of these operations.

Right.

-Chris

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