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>
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>
On Thursday 12 November 2009 22:48, Chris Lattner 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. > > Vectors of pointers are not allowed. I think disallowing intptr in > vectors makes perfect sense.Then we're going to need to fix this in the IR fairly soon. We won't be able to support architectures like Larrabee nicely until we do. -Dave
On Nov 13, 2009, at 6:46 AM, David Greene wrote:> On Thursday 12 November 2009 22:48, Chris Lattner 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. >> >> Vectors of pointers are not allowed. I think disallowing intptr in >> vectors makes perfect sense. > > Then we're going to need to fix this in the IR fairly soon. We > won't be > able to support architectures like Larrabee nicely until we do.Let me rephrase: I think it is fine to ignore vectors in the first iteration, we can always add support for them later. -Chris
On Nov 12, 2009, at 11:29 PM, John McCall wrote:>> 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.The optimizer assumes that the input and output of (e.g.) zext are both IntegerType's (which intptr won't be) and that the input is smaller (and thus non-equal to) the result type. We really don't want to break these invariants, -Chris
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
> 8, 16, and 24-bit address spaces are also popular.MSP430 can have either 16 or 20 bit pointers :) -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
On Fri, Nov 13, 2009 at 11:09 AM, Anton Korobeynikov < anton at korobeynikov.info> wrote:> > 8, 16, and 24-bit address spaces are also popular. > MSP430 can have either 16 or 20 bit pointers :) >I'm more interested in knowing whether there is an upper bound on pointer width. If there is, then it becomes relatively simple to store intptr constants - just represent them using integers whose size is the upper bound, and then truncate them later when the size becomes known.> -- > With best regards, Anton Korobeynikov > Faculty of Mathematics and Mechanics, Saint Petersburg State University >-- -- Talin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20091113/33fbaff2/attachment.html>