[LLVMdev] How to handle size_t in front ends?

[Jonathan S. Shapiro]

On Wed, 2008-05-07 at 15:20 -0400, Gordon Henriksen wrote:
> 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:
> 
> • Lowered to i32 or i64 for code generation.
> • Treated an ordinary integer for all operations except casts.
> • Can be the operand to ptrtoint, but not the result.
> • Can be the result of inttoptr, but not the operand.
> • Can be bitcast to an actual pointer type.
> • Whether sext, zext, and trunc are applicable, I could be convinced  
> either way. It muddies the semantics of these operations.

This doesn't seem like what we are after for BitC. In the BitC case,
WORD is not an integer type that contains a pointer value. It is an
integer type that is guaranteed to describe an arbitrary vector index.
The size dependency is a consequence of the fact that not all address
spaces are the same.

We allow Word <-> integer conversion through explicit conversion
operators, but the language spec does not allow Word to be intermixed
with other integral types for arithmetic operations.

shap