search for: intp

Simply put, it's a pointer-sized integer. I'm blatantly stealing this idea from .NET, where IntPtr (a pointer-sized integer) is a basic type. In my front end, I had considered just using a pointer for intp behind-the-scenes and doing conversion to/from int64 when I wanted to do arithmetic on them, but pointers and integers don't always align the same way. So what I really want is a way t...

2009/11/9 Kenneth Uildriks <kennethuil at gmail.com>: > > 1. Conversions to/from other integer types: right now, integer type > conversions are always explicity specified as either a trunc, a sext, > or a zext.  Since the size of intp is not known at IR generation time, > you can't know whether a conversion to/from intp truncates or extends. > Now that there are arbitrary-sized integers, couldn't you zext to i256 then trunc down again, and later let the folder simplify as appropriate?

...gmail.com> wrote: > 2009/11/9 Kenneth Uildriks <kenneth... at gmail.com>: > > > > > 1. Conversions to/from other integer types: right now, integer type > > conversions are always explicity specified as either a trunc, a sext, > > or a zext.  Since the size of intp is not known at IR generation time, > > you can't know whether a conversion to/from intp truncates or extends. > > Now that there are arbitrary-sized integers, couldn't you zext to i256 > then trunc down again, and later let the folder simplify as > appropriate? This is n...

...of these rare cases - it is something that is very >> painful to try and work around. (A similar esoteric use case is: "which of >> the following two types is larger, 3 x int32 or 2 x {}*? -- i.e. the union >> problem.) > > I'm willing to spend some time on adding intp to LLVM... my > front-end's standard libraries would be cleaner and more portable that > way. Sorry, but I'm still opposed. From your description of 'intp' it sounds like it's a strict subset of pointers. You can't sext it, zext it or trunc it, like you can with int...

...s very >>> painful to try and work around. (A similar esoteric use case is: "which >>> of >>> the following two types is larger, 3 x int32 or 2 x {}*? -- i.e. the >>> union >>> problem.) >> >> I'm willing to spend some time on adding intp to LLVM... my >> front-end's standard libraries would be cleaner and more portable that >> way. > > Sorry, but I'm still opposed. From your description of 'intp' it sounds like > it's a strict subset of pointers. You can't sext it, zext it or trunc it, &...

...e22.ca at gmail.com> wrote: > 2009/11/9 Kenneth Uildriks <kennethuil at gmail.com>: >> >> 1. Conversions to/from other integer types: right now, integer type >> conversions are always explicity specified as either a trunc, a sext, >> or a zext.  Since the size of intp is not known at IR generation time, >> you can't know whether a conversion to/from intp truncates or extends. >> > > Now that there are arbitrary-sized integers, couldn't you zext to i256 > then trunc down again, and later let the folder simplify as > appropriate? I...

...ve 32-bit operations. Clearly this is an ugly hack (especially in the obscurity of the IR code generated), but I haven't come up with anything better so far. Kenneth Uildriks wrote: > Simply put, it's a pointer-sized integer. I'm blatantly stealing this > idea from .NET, where IntPtr (a pointer-sized integer) is a basic > type. > > In my front end, I had considered just using a pointer for intp > behind-the-scenes and doing conversion to/from int64 when I wanted to > do arithmetic on them, but pointers and integers don't always align > the same way. So...

...>> painful to try and work around. (A similar esoteric use case is: "which >>>> of >>>> the following two types is larger, 3 x int32 or 2 x {}*? -- i.e. the >>>> union >>>> problem.) >>> I'm willing to spend some time on adding intp to LLVM... my >>> front-end's standard libraries would be cleaner and more portable that >>> way. >> Sorry, but I'm still opposed. From your description of 'intp' it sounds like >> it's a strict subset of pointers. You can't sext it, zext it or...

...s an int" is one of these rare cases -  it is something that is very > painful to try and work around. (A similar esoteric use case is: "which of > the following two types is larger, 3 x int32 or 2 x {}*? -- i.e. the union > problem.) I'm willing to spend some time on adding intp to LLVM... my front-end's standard libraries would be cleaner and more portable that way.

...rote: > > 2009/11/9 Kenneth Uildriks <kennethuil at gmail.com>: > >> > >> 1. Conversions to/from other integer types: right now, integer type > >> conversions are always explicity specified as either a trunc, a sext, > >> or a zext. Since the size of intp is not known at IR generation time, > >> you can't know whether a conversion to/from intp truncates or extends. > >> > > > > Now that there are arbitrary-sized integers, couldn't you zext to i256 > > then trunc down again, and later let the folder simplif...

On Wed, Nov 11, 2009 at 2:46 PM, Nick Lewycky <nicholas at mxc.ca> wrote: > I'd be happy to permit arithmetic and bitwise operations on pointers. (I > thought we already did. We don't.) That would be very helpful too. > > You still can't create literal values with it (besides null) because you > don't know whether your constant will fit. Or rather, what you

> I mean within a structure or array. I don't know whether any > platforms would pass them any differently as function arguments, but I > do know that the "default" data layout (which I believe is the Sparc > data layout) aligns int32's on 32-bit boundaries and 32-bit pointers > on 64-bit boundaries. Wrap the pointer in a packed struct maybe? Ciao, Duncan.

...gt; > Wrap the pointer in a packed struct maybe? > > Ciao, > > Duncan. > That sets the alignment to 1 unconditionally, which might also be wrong. Now I assume that a one-element regular struct would have the same alignment as the element, right? In that case: 1. A type such as intp will get the following definition: struct { {intAAA, intBBB, intCCC, intDDD, intEEE, intFFF, intGGG, intHHH}*[0]; int32 or int64 }; where AAA, BBB, CCC, DDD, EEE, FFF, GGG, HHH are 16 bit values that combine to form a GUID. Since it's zero-sized, the struct as a whole will align the same wa...

On Tue, Nov 10, 2009 at 6:41 PM, Kenneth Uildriks <kennethuil at gmail.com> wrote: > On Tue, Nov 10, 2009 at 6:10 PM, Talin <viridia at gmail.com> wrote: (A similar esoteric use case is: "which of >> the following two types is larger, 3 x int32 or 2 x {}*? -- i.e. the union >> problem.) The size of a union can be compiled into a ConstantExpr. i.e., (sizeof(T1)

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 > vector...

> 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

...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 >> "ta...

...re probably not critical for most optimizations) or > slowly accumulate duplicate code paths in every pass that looks at zexts > and truncs. > Actually, I take this back; there are definitely common optimizations that are going to be much more complicated if they have to deal with intptrs, most obviously instcombining trunc/zext/sext. John.

...igger 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...

...around. (A similar esoteric use case is: "which > of the following two types is larger, 3 x int32 or 2 x {}*? -- i.e. the > union problem.) > > With this explanation, the idea of adding a union type seems a lot more > compelling to me. For the record, I'm not opposed to an intptr_t type or a > union type, but the semantics have to be clean and well specified. > > -Chris Well, as far as intp goes (or iptr if you prefer - the naming convention in LLVM is i<size>), here's what I would expect: - General rule #1: If an instruction accepts both i32 and...