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
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/
On Wed, 2008-05-07 at 14:25 -0700, Chris Lattner wrote:> 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.On a 32-bit platform, doesn't one want to use i32? That was the point that I was trying to make -- on a 32-bit platform one wants to use i32, while on a 64-bit platform one wants to use i64. If one is trying to generate neutral IR, there really isn't a "right" choice here. shap