[LLVMdev] Proposal: intp type

[Chris Lattner]

On Nov 12, 2009, at 11:29 AM, Talin wrote:
>
> Well, as far as intp goes (or iptr if you prefer - the naming  
> convention in LLVM is i<size>)

How about "intptr".

> here's what I would expect:
> General rule #1: If an instruction accepts both i32 and i64, then it  
> should accept iptr as well. If it only accepts i32, then it can  
> continue to only accept i32.
> General rule #2: It should support operations that are commonly used  
> with size_t and ptrdiff_t.
Ok.  Just realize that obscure optimizations like "constant folding"  
won't be possible without TargetData around. :)
> Operations that should work with iptr:
> Basic math: add, subtract, multiply, divide, mod.
> Bitwise binary operators: shl, ashr, lshr, and, or, xor, etc.
> Comparison operations.
> alloca - currently doesn't work with i64, should it?
Yes, alloca should work with i64.  Recently malloc was detangled from  
alloca, but alloca should definitely support an arbitrary integer  
size.  I don't know anyone planning to do this.  In any case, for the  
first implementation stage of intptr, just converting to an i32 to do  
the alloca should be fine (no worse than what we have today).  When  
alloca gets generalized, if intptr is around it will be handed as well.
> GEP - rules are the same as for using i64 indices.
> memcpy intrinsics
> bit manipulation intrinsics
> overflow arithmetic intrinsics - would be nice
> atomic intrinsics - would be very nice (I assume that atomic iptr  
> works on all platforms that support atomics: That is, on 32-bit  
> platforms where iptr == i32 I expect atomic i32 to work; on 64-bit  
> platforms where iptr == i64 I expect atomic i64 to work).
This all sounds reasonable.
> Operations that don't need to work with iptr - i.e. I don't mind  
> having to convert to some other int type first:
> switch
> extractelement / insertelement / shufflevector
> extractvalue / insertvalue - not sure about these.
> code generator intrinsics (frameaddress, etc.)
insert/extractvalue need to work, as does load/store/phi for it to be  
a useful first class value.  switch should "just work".  I don't have  
an opinion about whether intptr should work with vectors, but it seems  
sensible either way.  I agree about frameaddress.

> Converting to pointer types: inttoptr and ptrtoint should be no-ops,  
> effectively.
> Converting to other integer types: The issue here is that with other  
> integer conversions in LLVM, you are required to know whether or not  
> you are converting to a larger or smaller size - whether to use an  
> ext or a trunc instruction. When converting to pointers, however,  
> the choice of trunc or ext is automatic. Ideally, conversion to iptr  
> would work the same way as conversion to a pointer type. There's  
> also the issue of signed vs. unsigned extension.
> Note that some constant-folding operations would need to be deferred  
> until the target size is established.
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 int
intptr to signed int
signed int to intptr
intptr to unsigned int
unsigned int to intptr

Does that seem reasonable?
> Converting to FP types: Either don't support (i.e. require casting  
> to known-width integer first), or map to i32->FP or i64->FP after  
> the size is known.
I think we should force conversion to a fixed integer type before  
converting to/from FP (for example pointers can't currently be  
converted to FP, they have to go through an intermediate integer  
type).  If it is important, we can always add this as a second (or  
third) extension once the basics work.

I'm going to be away on vacation for two weeks so I won't be able to  
keep up to date with this thread, if you're interested in pursuing  
this work, please write up something in the form of an  
'llvmnote' (e.g. http://nondot.org/sabre/LLVMNotes/IndirectGoto.txt)  
which explains in prose the problem it is trying to solve, the  
tradeoffs, and a proposed implementation approach (like you have  
above).  Whether or not you get time to start implementing it, it is a  
good idea to document the design tradeoffs considered and the effects  
of various decisions (such as neutering constant folding when TD isn't  
around).  This is also a good way to get others to help out,

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