[LLVMdev] How to handle size_t in front ends?

[Jonathan S. Shapiro]

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

Yes. For BitC purposes, querying TargetData would be sufficient as long
as we don't care whether the emitted IR is neutral w.r.t. pointer size.
Given this, I think that introducing an iWord type is not yet
sufficiently well motivated from the BitC perspective.

But it would sure be convenient if we could query TargetData at compile
time to determine the target pointer size. Not essential, by any means,
but it seems unnecessary to encode the knowledge redundantly (in both
the IR layer and the front end).

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.

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

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.

Perhaps Mike and I are thinking about unrelated things.

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

I agree, but Mike was consistent enough here that I wondered if I had
failed to understand what he was after properly.

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

These seem important in order to allow explicit conversions to the
normal integer types.


shap