[LLVMdev] How to handle size_t in front ends?

[Gordon Henriksen]

On 2008-05-07, at 03:05, Chris Lattner wrote:

> On May 6, 2008, at 11:49 PM, Jonathan S. Shapiro wrote:
>
>> There are other languages that specify a "word" type along these  
>> lines. Would it be worth considering adding such a type to the IR,  
>> or is there a reason not to do so that I am failing to see?
>
> 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:

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

On 2008-05-07, at 12:51, Mike Stump wrote:

> The word opaque comes to mind.  The basic question is, do you want  
> people to be able to understand this stuff, or is it more like the  
> bitcode file, you don't care that it is unreadable?

I think this is unworkable. You can't assign an opaque value to a vreg  
(what if it became an struct type?)—only a pointer to an opaque can be  
used as a vreg. Never mind the horror of calling a runtime function to  
perform integer arithmetic.

— Gordon