[LLVMdev] Proposal: intp type

[Chris Lattner]

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.

> If we assume that i64 is the upper limit, then intptr constants can  
> be converted to i64 until needed.
>
> Some constant folding can occur if the folding wouldn't change the  
> final result. Specifically, for any function f(x, y) where (i32)f(x,  
> y) is the same as (i32)f((i32)x, (i32)y), it's safe to apply that  
> function before the final size of the integer is chosen. Thus,  
> adding two numbers (ignoring overflow), or shifting to the left  
> should be safe to fold.
>
> That being said, I am perfectly fine with simply disabling folding,  
> and leaving the partial folding as a future optimization.

How should immediates be formed?  Is it valid for a ConstantInt to  
have intptr type?  How wide would the contained APInt be?  I think it  
would be safe to represent all constants as (signed_int_to_intptr  
(constantint 42)) or something.

>
> There is also the question of whether intptrs should be allowed as  
> *members* of vectors. I have no opinion on this, except to say that  
> it probably only makes sense in situations where you can also have  
> vectors of pointers.

Vectors of pointers are not allowed.  I think disallowing intptr in  
vectors makes perfect sense.
> 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.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091112/d11bdd0f/attachment.html>