search for: intoptr

...ep 13, 2012, at 12:00 PM, Mon Ping Wang <monping at apple.com> wrote: >>> In C, integer to point conversions are implementation defined and >>> depends on what the addressing structure of the execution environment >>> is. Given the current definition of ptrtoint and intoptr, I feel that >>> the addressing structure feels like a flat memory model starting from 0 >>> and the value "b" should be 65529. In your example where we know the >>> largest pointer is 64b, I would expect the final result to be the same >>> as doing a...

...at 12:00 PM, Mon Ping Wang <monping at apple.com> wrote: >>>> In C, integer to point conversions are implementation defined and >>>> depends on what the addressing structure of the execution environment >>>> is. Given the current definition of ptrtoint and intoptr, I feel that >>>> the addressing structure feels like a flat memory model starting from 0 >>>> and the value "b" should be 65529. In your example where we know the >>>> largest pointer is 64b, I would expect the final result to be the same >>>...

...4* %r30, align 8 Outgoing, I have this: %r30 = getelementptr [71 x i64]* %"t$3", i32 0, i32 0 ; <i64*> [#uses=1] store i64 72057594037927936, i64* %r30, align 16 I believe the alignment on the outgoing store is wrong, but my question concerns the optimization of the ptrtoint / intoptr to a gep. Is this optimization allowed to pun the pointer type like this or should there be a bitcast to i64* in there somewhere? -Dave

...o all targets can use that? In other words, pointers > 64 doesn't make any sense in terms of the address space? (A pointer to be > 64 if clients want to use some upper bits to track some state I guess). > > In terms of the three new instructions, one could argue that ptrtoint and intoptr has the same issue or those can also explode in a similar way. To use them, this seems target dependent so unless we really want to support all the various addressing structures, I rather not have them. My point is that any producer of this sort of pointer cast is already necessarily target speci...

...n use that? In other words, pointers > 64 doesn't make any sense in terms of the address space? (A pointer to be > 64 if clients want to use some upper bits to track some state I guess). >>> >>> In terms of the three new instructions, one could argue that ptrtoint and intoptr has the same issue or those can also explode in a similar way. To use them, this seems target dependent so unless we really want to support all the various addressing structures, I rather not have them. >> >> My point is that any producer of this sort of pointer cast is already necess...

...rgets can use that? In other words, pointers > 64 doesn't make any sense in terms of the address space? (A pointer to be > 64 if clients want to use some upper bits to track some state I guess). >> >> In terms of the three new instructions, one could argue that ptrtoint and intoptr has the same issue or those can also explode in a similar way. To use them, this seems target dependent so unless we really want to support all the various addressing structures, I rather not have them. > > My point is that any producer of this sort of pointer cast is already necessarily ta...

...ords, pointers > 64 doesn't make any sense in terms of > the address space? (A pointer to be > 64 if clients want to use some > upper bits to track some state I guess). > >>> > >>> In terms of the three new instructions, one could argue that > ptrtoint and intoptr has the same issue or those can also explode in a > similar way. To use them, this seems target dependent so unless we > really want to support all the various addressing structures, I rather > not have them. > >> > >> My point is that any producer of this sort of pointe...

...(A pointer to be > > > > > > 64 if clients want to use some upper bits to track some state I > guess). > > > > > >>> > > > > > >>> In terms of the three new instructions, one could argue that > > > > > ptrtoint and intoptr has the same issue or those can also > > > > > explode in a similar way. To use them, this seems target > > > > > dependent so unless we really want to support all the various > > > > > addressing structures, I rather not have them. > > > >...

...I would expect the same result if I wrote > int(1) *a = 0x0FFF9; > int(2) *b = *a; > > In C, integer to point conversions are implementation defined and > depends on what the addressing structure of the execution environment > is. Given the current definition of ptrtoint and intoptr, I feel that > the addressing structure feels like a flat memory model starting from 0 > and the value "b" should be 65529. In your example where we know the > largest pointer is 64b, I would expect the final result to be the same > as doing a ptrtoint from int(1) to i64 and...

...me result if I wrote >> int(1) *a = 0x0FFF9; >> int(2) *b = *a; >> >> In C, integer to point conversions are implementation defined and >> depends on what the addressing structure of the execution environment >> is. Given the current definition of ptrtoint and intoptr, I feel that >> the addressing structure feels like a flat memory model starting from 0 >> and the value "b" should be 65529. In your example where we know the >> largest pointer is 64b, I would expect the final result to be the same >> as doing a ptrtoint from in...

...t;> > > > > I > >> guess). > >> > > > > >>> > >> > > > > >>> In terms of the three new instructions, one could argue > >> > > > > >>> that > >> > > > > ptrtoint and intoptr has the same issue or those can also > >> > > > > explode in a similar way. To use them, this seems target > >> > > > > dependent so unless we really want to support all the various > >> > > > > addressing structures, I rather not have...

...t; >> > > > > 64 if clients want to use some upper bits to track some state I >> guess). >> > > > > >>> >> > > > > >>> In terms of the three new instructions, one could argue that >> > > > > ptrtoint and intoptr has the same issue or those can also >> > > > > explode in a similar way. To use them, this seems target >> > > > > dependent so unless we really want to support all the various >> > > > > addressing structures, I rather not have them. >>...

...0 PM, Mon Ping Wang <monping at apple.com> wrote: > >>> In C, integer to point conversions are implementation defined and > >>> depends on what the addressing structure of the execution > environment > >>> is. Given the current definition of ptrtoint and intoptr, I feel > that > >>> the addressing structure feels like a flat memory model starting > from 0 > >>> and the value "b" should be 65529. In your example where we know > the > >>> largest pointer is 64b, I would expect the final result to be the...

On Mon, Mar 16, 2015 at 9:56 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > so just using pointer types instead of i64 will help common cases, but > will not address the general issue. Now part of this does some down to > using array parameters as a substitute for byval/direct parameters. As I > recall, this was done because it allowed a natural partial decomposition >

...; > I >> >> guess). >> >> > > > > >>> >> >> > > > > >>> In terms of the three new instructions, one could argue >> >> > > > > >>> that >> >> > > > > ptrtoint and intoptr has the same issue or those can also >> >> > > > > explode in a similar way. To use them, this seems target >> >> > > > > dependent so unless we really want to support all the various >> >> > > > > addressing structures, I rat...

...asting from one address space to another. This > doesn't have to go into TargetData. Well, if the pointers really are differently sized, you couldn't just bitcast between them, since bitcast requires values of equal bitlength? Or is this something that would only be exposed when doing intoptr/ptrtoint and simply assumed to be handled in the backend for pointer-to-pointer bitcasts? > > In this case, finding some text representation for the address space > > relations make sense, so that these relations can be embedded into the > > LLVM IR (possibly inside the "ta...

...5529 (Zext from 16b to 64b)? I would expect the same result if I wrote int(1) *a = 0x0FFF9; int(2) *b = *a; In C, integer to point conversions are implementation defined and depends on what the addressing structure of the execution environment is. Given the current definition of ptrtoint and intoptr, I feel that the addressing structure feels like a flat memory model starting from 0 and the value "b" should be 65529. In your example where we know the largest pointer is 64b, I would expect the final result to be the same as doing a ptrtoint from int(1) to i64 and intotptr to int(2)*....

...t;> guess). > >> >> > > > > >>> > >> >> > > > > >>> In terms of the three new instructions, one could > >> >> > > > > >>> argue that > >> >> > > > > ptrtoint and intoptr has the same issue or those can > >> >> > > > > also explode in a similar way. To use them, this seems > >> >> > > > > target dependent so unless we really want to support > >> >> > > > > all the various addressing st...

On Jul 21, 2008, at 11:58 PM, Matthijs Kooijman wrote: >> >> You probably want to somehow extend TargetData to encode the address >> space descriptions, including pointer sizes and address space >> relationships. > Hmm, you have an excellent point there, pointer sizes could indeed > easily have > different sizes in different address spaces... That would make

Hi Gordon, > TargetData is a concrete class, part of the middle-end. It describes > parts of the the target's ABI. It allows target-independent passes to > do things like decide whether x[1] and ((char *) x)[4] alias. This is > possible without actually linking with the code generator for the > relevant target. TargetData can be encoded in the LLVM IR, e.g. target