[LLVMdev] Proposal: intp type

[Jim Grosbach]

On Nov 12, 2009, at 11:29 PM, John McCall wrote:

> Chris Lattner wrote:
>> On Nov 12, 2009, at 7:35 PM, Talin wrote:
>>> On Thu, Nov 12, 2009 at 5:58 PM, Chris Lattner  
>>> <clattner at apple.com> wrote:
>>>
>>> There is also the issue of how constants should be represented.
>>>
>>> For all current processors that I know of, an intptr will be  
>>> either 32 or 64 bits. However, there may be some future processor  
>>> which supports 128-bit pointers (although a system containing that  
>>> much RAM or even virtual address space is hard to imagine.)
>>
>> 8, 16, and 24-bit address spaces are also popular.
>
> To be really pedantic, a single platform may have multiple pointer  
> widths;  I assume intptr would correspond to the width of a generic  
> pointer, but non-generic address spaces are not constrained in any  
> direction by the size of the generic address space.  Of course, non- 
> generic address spaces have no place in portable bitcode anyway, but  
> I wanted to insert a note of pedantry into the conversation. :)
>

That's not all that uncommon a situation in the embedded world.  
Definitely something to keep in mind.

-Jim


>>> Almost *all* constant folding would have to be deferred, which  
>>> means you'd get big chains of constant exprs.  This isn't a  
>>> problem per-say, but something to be aware of.
>>>
>>> I don't like reusing existing sext/trunc/zext/inttoptr/ptrtoint  
>>> casts for intptr.  I think we should introduce new operations  
>>> (hopefully with better names):
>>>
>>> ptr to intptr
>>> intptr to ptr
>>> intptr to signed int
>>> signed int to intptr
>>> intptr to unsigned int
>>> unsigned int to intptr
>>>
>>> Does that seem reasonable?
>>>
>>> Sure. Another option is to do away with sext/trunc/etc. and just  
>>> have two cast operations for ints: sicast and uicast. sicast  
>>> converts any int size to any other (with sign extension if the  
>>> destination type is bigger), and uicast is the same but with zero  
>>> extension.
>>
>> sext/zext/trunc are very nice for the optimizer, we should keep  
>> them.  It means that the optimizer doesn't have to check that the  
>> input to a sext is bigger or smaller than the result, for example.   
>> Code that cares (e.g. instcombine) really likes this.
>
> We could just say that code has undefined behavior or is invalid if  
> the 'sext', 'zext', or 'trunc' is inappropriate for the actual size  
> of intptr.  I think this is reasonable;  if the frontend emits a  
> zext intptr to i32, and the pointer side is i64, that *should* be  
> invalid.  This way the optimizer gets to keep its assumptions and it  
> becomes the client's responsibility to ensure that its "target- 
> neutral" bitcode really is neutral for the range of platforms it  
> actually cares about.  Portable code can't be truncating arbitrary  
> pointers to some smaller type anyway;  if the client just wants to  
> munge the bottom bits, it can zext and trunc to and from i8/i12/ 
> whatever.
>
> John.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev