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>
On Thu, Nov 12, 2009 at 5:58 PM, Chris Lattner <clattner at apple.com> wrote:> 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. :) >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.) 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.> > - 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. >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.> > - 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? >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. That leaves just ptrtoint and inttoptr - which incidentally have the same semantics as sicast and uicast.> > - 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 >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091112/056c9073/attachment.html>
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>
On Thursday 12 November 2009 19:58, Chris Lattner wrote:> 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".I read this as "pointer to integer." iptr is slightly better because it follows the i<size> convention. -Dave
On Thursday 12 November 2009 21:35, Talin wrote:> 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.We definitely want this for gather-scatter. It's going to become much more important shortly. -Dave
Chris Lattner wrote:> 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,Just to let you know what's going on, I communicated privately with Kenneth and he said that he was interested in writing up the llvmnote that you requested. -- Talin
After some experimentation, I've determined that for my own purposes I can get by with storing the integer fields as pointers. Which means that adding this feature to LLVM is now fairly low on my wish list. At this point, I'm more interested in larger first-class structs and unions. Oh, and getting source-level debugging working :) On Thu, Nov 12, 2009 at 5:58 PM, Chris Lattner <clattner at apple.com> wrote:> 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 >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091203/36792b34/attachment.html>