search for: ptrtoints

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.

[AMD Official Use Only - Internal Distribution Only] Hi everyone, Asan instrumentation introduces a ptrtoint instruction which is used as an argument to a number of runtime functions. Every instrumented load/store ends up having at least one ptrtoint attached to its address. However, the community has now raised a number of concerns about the use of LLVM generated ptrtoint & inttoptr [1]

Thanks. So what about a fragment like this: (taken from fast-isel.ll in X86 ) define void @ptrtoint_i1(i8* %p, i1* %q) nounwind { %t = ptrtoint i8* %p to i1 store i1 %t, i1* %q ret void } TIA. On 09/29/2014 02:16 PM, Duncan P. N. Exon Smith wrote: >> On Sep 29, 2014, at 1:51 PM, reed kotler <rkotler at mips.com> wrote: >> >> What kind of C or C++ code will emit

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

On Sep 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

What kind of C or C++ code will emit a "ptrtoint" op? Also, what causes i1 to be emitted? Tia. Reed

Hi, I am trying to figure out how to read arguments of a call instruction. I had few questions based on that I have the following C Code 1 #include <stdio.h> 2 3 struct my_struct 4 { 5 int a; 6 int b; 7 }; 8 9 struct my_struct abc; 10 void p_ptr ( unsigned long j) 11 { 12 printf ( "%lx \n", j ); 13 } 14 15 void struct_ptr ( struct my_struct *

...add a parameter like 'bool use_psub' to IRBuilder::CreatePtrDiff. When Clang inserts a pointer subtraction, use_psub is set to true. When LLVM inserts it, it is set as false. Default value of use_psub is false, so existing LLVM passes will still insert sub (ptrtoint, ptrtoint) but most of ptrtoints are inserted from Clang, so # of ptrtoint will significantly decrease as well. Adding an "inbounds" flag to psub doesn't seem necessary since you can achieve the same thing with sub(ptrtoint, ptrtoint). > This doesn't make a lot of sense to me... the pointer subtractions sema...

Hello all, There is a missing vectorization opportunity issue with clang 4.0 with the file attached. Indeed, when compiled with -O2, the "op_distance" function get vectorized, but not the "op" one. For information, this test case has been reduced from a file generated by the Pythran compiler (https://github.com/serge-sans-paille/pythran). If we take a look at the generated

Technically I don't need C/C++ code for it. I'm not really very good at writing LLVM assembly code by hand (but I should be - lol ). I'm working on fast-isel and I want to have executable tests for all of this and not just make check tests. It's easier for me to do that in C/C++ and then save the .ll and morph it into a make check test. I'm going through the fast-isel

Hi. First of all, some context. I'm trying to implement a new functionality in an LLVM-based compiler and I need to take various actions based on the value of a given pointer, the possible values being the addresses of various global constants. I tried to use a `switch` instruction but I encountered several problems. The "ideal switch" I'd like to have would look

Hi, all When I read the document of IR on llvm.org, I found two instructions, "ptrtoint" and load. Load, I think, is : when after allocating some bytes in memory and storing some data into it, we could use load to get the data, like this: %0 = alloca i32 store i32 5, i32* %0 %1 = load i32* %0 so, the type of %1 is i32, and the value is 5, right? And "ptrtoint" is:we cast it

...ell. When compiling >> SPEC 2017 >> with -O0, there are 23,208 ptrtoint instructions, but among them 22,016 >> (94.8%) >> are generated by Clang frontend to represent pointer subtraction. >> They aren't effectively optimized out because there are even more >> ptrtoints (31,721) after -O3. >> This is bad for performance because existence of ptrtoint makes analysis >> return conservative >> result as a pointer can be escaped through the cast. >> Memory accesses to a pointer came from inttoptr is assumed >> to possibly access anywhere,...

...s. This trend is similar in ptrtoint instruction as well. When compiling SPEC 2017 with -O0, there are 23,208 ptrtoint instructions, but among them 22,016 (94.8%) are generated by Clang frontend to represent pointer subtraction. They aren't effectively optimized out because there are even more ptrtoints (31,721) after -O3. This is bad for performance because existence of ptrtoint makes analysis return conservative result as a pointer can be escaped through the cast. Memory accesses to a pointer came from inttoptr is assumed to possibly access anywhere, therefore it may block store-to-load forwardi...

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

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

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

On Sep 13, 2012, at 2:23 PM, Chris Lattner <clattner at apple.com> wrote: > On Sep 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

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

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 =