similar to: [LLVMdev] Canonicalization of ptrtoint/inttoptr and getelementptr

Displaying 20 results from an estimated 6000 matches similar to: "[LLVMdev] Canonicalization of ptrtoint/inttoptr and getelementptr"

2014 Sep 10
3
[LLVMdev] Canonicalization of ptrtoint/inttoptr and getelementptr
On 09/08/2014 04:22 PM, Dan Gohman wrote: > An object can be allocated at virtual address 5 through extra-VM means > (eg. mmap), and then one can (creatively) interpret the return value > of @f as being associated with whatever %A was associated with *and* > 5. The return value of @g can only be associated with exactly the same > set that %A was associated with. Consequently,
2011 Apr 05
3
[LLVMdev] GEP vs IntToPtr/PtrToInt
On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > > >> Hi, >> Is it correct to convert, >>   %196 = load i32* %195, align 8                  ; <i32> [#uses=1] >>   %197 = zext i32 %196 to i64                     ; <i64> [#uses=1] >>   %198 = ptrtoint i8* %193 to i64                 ; <i64> [#uses=1]
2011 Apr 04
2
[LLVMdev] GEP vs IntToPtr/PtrToInt
On 4/4/2011 6:45 PM, Eli Friedman wrote: > On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com> wrote: >> >>> Hi, >>> Is it correct to convert, >>> %196 = load i32* %195, align 8 ;<i32> [#uses=1] >>> %197 = zext i32 %196 to i64 ;<i64> [#uses=1] >>> %198 =
2011 Apr 05
0
[LLVMdev] GEP vs IntToPtr/PtrToInt
On Mon, Apr 4, 2011 at 7:10 AM, John Criswell <criswell at illinois.edu> wrote: > On 4/4/2011 6:45 PM, Eli Friedman wrote: >> >> On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com> >>  wrote: >>> >>>> Hi, >>>> Is it correct to convert, >>>>   %196 = load i32* %195, align 8                
2011 Apr 20
0
[LLVMdev] GEP vs IntToPtr/PtrToInt
On Wed, Apr 20, 2011 at 8:08 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > I have a question about when we should apply these pointer aliasing > rules. Do the rules tell us when a load/store is safe? > "Any memory access must be done through a pointer value associated > with an address range of the memory access, otherwise the behavior is > undefined." >
2011 Apr 20
0
[LLVMdev] GEP vs IntToPtr/PtrToInt
On Wed, Apr 20, 2011 at 10:21 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: > On Wed, Apr 20, 2011 at 12:20 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Wed, Apr 20, 2011 at 8:08 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >>> I have a question about when we should apply these pointer aliasing >>> rules. Do the rules tell
2011 Apr 20
1
[LLVMdev] GEP vs IntToPtr/PtrToInt
On Wed, Apr 20, 2011 at 2:11 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Apr 20, 2011 at 10:21 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >> On Wed, Apr 20, 2011 at 12:20 PM, Eli Friedman <eli.friedman at gmail.com> wrote: >>> On Wed, Apr 20, 2011 at 8:08 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >>>> I
2011 Apr 20
2
[LLVMdev] GEP vs IntToPtr/PtrToInt
On Wed, Apr 20, 2011 at 12:20 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Wed, Apr 20, 2011 at 8:08 AM, Jianzhou Zhao <jianzhou at seas.upenn.edu> wrote: >> I have a question about when we should apply these pointer aliasing >> rules. Do the rules tell us when a load/store is safe? >> "Any memory access must be done through a pointer value
2011 Apr 20
4
[LLVMdev] GEP vs IntToPtr/PtrToInt
I have a question about when we should apply these pointer aliasing rules. Do the rules tell us when a load/store is safe? "Any memory access must be done through a pointer value associated with an address range of the memory access, otherwise the behavior is undefined." So this means the conversion discussed here is still safe in terms of memory safety, but its meaning after conversion
2014 Sep 09
2
[LLVMdev] Canonicalization of ptrtoint/inttoptr and getelementptr
On Mon, Sep 8, 2014 at 4:22 PM, Dan Gohman <dan433584 at gmail.com> wrote: > It looks a little silly to say this in the case of the integer constant 5, > and there are some semantic gray areas around extra-VM allocation, but the > same thing happens if the add were adding a dynamic integer value, and then > it's difficult to find a way to separate that case from the constant
2011 Apr 05
2
[LLVMdev] GEP vs IntToPtr/PtrToInt
Hi, Is it correct to convert, %196 = load i32* %195, align 8 ; <i32> [#uses=1] %197 = zext i32 %196 to i64 ; <i64> [#uses=1] %198 = ptrtoint i8* %193 to i64 ; <i64> [#uses=1] %199 = add i64 %198, %197 ; <i64> [#uses=1] %200 = inttoptr i64 %199 to i8* ; <i8*>
2011 Apr 05
0
[LLVMdev] GEP vs IntToPtr/PtrToInt
Hi, > > Is it correct to convert, > > %196 = load i32* %195, align 8 ; <i32> [#uses=1] > %197 = zext i32 %196 to i64 ; <i64> [#uses=1] > %198 = ptrtoint i8* %193 to i64 ; <i64> [#uses=1] > %199 = add i64 %198, %197 ; <i64> [#uses=1] > %200 = inttoptr i64 %199 to i8*
2011 Apr 20
0
[LLVMdev] GEP vs IntToPtr/PtrToInt
On 4/20/11 10:08 AM, Jianzhou Zhao wrote: > I have a question about when we should apply these pointer aliasing > rules. Do the rules tell us when a load/store is safe? > "Any memory access must be done through a pointer value associated > with an address range of the memory access, otherwise the behavior is > undefined." I don't think the pointer aliasing rules
2011 Apr 05
0
[LLVMdev] GEP vs IntToPtr/PtrToInt
This code is generated for va_arg. %6 = getelementptr inbounds %struct.__va_list_tag* %5, i32 0, i32 3 ; <i8**> [#uses=1] %7 = load i8** %6, align 8 ; <i8*> [#uses=1] %8 = getelementptr inbounds [1 x %struct.__va_list_tag]* %ap, i64 0, i64 0 ; <%struct.__va_list_tag*> [#uses=1] %9 = getelementptr inbounds %struct.__va_list_tag* %8, i32 0, i32 0 ;
2017 Jun 20
3
LoopVectorize fails to vectorize loops with induction variables with PtrToInt/IntToPtr conversions
On 06/20/2017 03:26 AM, Hal Finkel wrote: > Hi, Adrien, Hello Hal! Thanks for your answer! > Thanks for reporting this. I recommend that you file a bug report at > https://bugs.llvm.org/ Will do! > Whenever I see reports of missed optimization opportunities in the face > of ptrtoint/inttoptr, my first question is: why are these instructions > present in the first place? At
2020 Jul 02
3
Redundant ptrtoint/inttoptr instructions
Hi all, We noticed a lot of unnecessary ptrtoint instructions that stand in way of some of our optimizations; the code pattern looks like this: bb1: %int1 = ptrtoint %struct.s* %ptr1 to i64 bb2: %int2 = ptrtoint %struct.s* %ptr2 to i64 %bb3: %phi.node = phi i64 [ %int1, %bb1 ], [%int2, %bb2 ] %ptr = inttoptr i64 %phi.node to %struct.s* In short, the pattern above arises due to: 1.
2019 Sep 30
2
Proposal for llvm.experimental.gc intrinsics for inttoptr and ptrtoint
Hi All, I'm working on a project converting Dart to llvm. Dart uses a relocating GC but additionally uses pointer tagging. The first bit of a pointer is a tag. For integers a '0' bit is used and for pointers to objects a '1' bit is used. V8 apparently uses a similar technique. Generated code may need to check which bit is used when this information isn't statically known.
2012 Feb 29
2
[LLVMdev] getelementptr being lowered to ptrtoint/.../inttoptr?
Hello, I am working on an application of LLVM where I would strongly prefer that getelementptr not be lowered into pointer arithmetic by any passes other than my own. I'm writing a ModulePass. I am observing a situation where I compile a C++ file with no optimization and I get code as I would expect that uses getelementptr. However, if I enable optimization with -O3, *some* of my
2020 Jul 02
3
Redundant ptrtoint/inttoptr instructions
My general feeling is this: No optimizations should be creating int2ptr/ptr2int. We really need to fix them all. They should use pointer casts and i8* GEPs. This has, unfortunately, been a problem for a long time. As Johannes says, optimizing int2ptr/ptr2int is very tricky. In part, becaue all dependencies, including implicit control dependencies, end up being part of the resulting aliasing
2019 Oct 01
2
Proposal for llvm.experimental.gc intrinsics for inttoptr and ptrtoint
For a datapoint, Julia uses the following function description to implement approximately the capability of those functions. We then also verify that there's no direct inttoptr/ptrtoint into our gc-tracked AddressSpace with a custom verifier pass (among other sanity checks). I can provide additional details and pointers to our gc-root tracking algorithm implementation if desired (I also plan