[LLVMdev] Proposal: intp type

[John McCall]

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 
>> <mailto: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. :)

>>     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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091112/d7391b64/attachment.html>