search for: ptrtoint

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

[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] and have poin...

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 the IR level, use of inttoptr is highly > discouraged. Our aliasing analysis, for example, does not look through > them, and so you'll generally see a lot of missed optimizations when > they&...

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

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

...1 main () 22 { 23 struct my_struct stack_abc; 24 p_ptr ((unsigned long) &abc); 25 struct_ptr ( &abc ); 26 p_ptr ((unsigned long) &stack_abc); 27 struct_ptr ( &stack_abc ); 28 return 0; 29 } 24 p_ptr ((unsigned long) &abc); call void @p_ptr(i64 ptrtoint (%struct.my_struct* @abc to i64)) nounwind, !dbg !31 Q.1 At line no 24 I try to read the address of global variable abc. The address is type casted from struct * to int * for which ptrtoint. I read the operands of the call instruction and there descriptions. I do not see among...

...hnique is something like the following in *pseudocode* (note that this is > not necessarily valid C but we might reasonably want to express this kind of optimization within LLVM: When LLVM need to insert subtraction between two pointers, like the example you wrote, I believe we can use 'sub(ptrtoint p, ptrtoint q)' as before. This addresses concerns regarding correctness of existing pointer analysis. So you don't lose expressiveness, while you gain precision when possible. A concrete suggestion is to add a parameter like 'bool use_psub' to IRBuilder::CreatePtrDiff. When Clang...

...llvm op_zip_iterator.cpp -std=c++11 -o - -fno-vectorize > ; Function Attrs: norecurse uwtable > define void @_Z11op_distancePi16add_zip_iteratorS0_(i32* nocapture, i32*, i32* nocapture readonly, i32*, i32* nocapture readnone) local_unnamed_addr #0 { > ; This one is vectorized! > %6 = ptrtoint i32* %1 to i64 > %7 = ptrtoint i32* %3 to i64 > %8 = sub i64 %7, %6 > %9 = icmp sgt i64 %8, 0 > br i1 %9, label %10, label %26 > > ; <label>:10: ; preds = %5 > %11 = lshr exact i64 %8, 2 > br label %12 > > ; <l...

...all of them. On 09/29/2014 03:11 PM, Duncan P. N. Exon Smith wrote: >> On Sep 29, 2014, at 2:29 PM, reed kotler <rkotler at mips.com> wrote: >> >> 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 >> } > Intuitively, this looks like: > > void ptrtoint_i1(char *p, bool *q) { *q = (bool)p; } > > However, `q` needs to be addressable in C/C++, so it'...

...; preds = %entry unreachable post: ; preds = %var1, %var0 %1 = phi i32 [ 0, %var0 ], [ 1, %var1 ] ret i32 %1 } This example is impossible because a `switch` cannot have pointer operands. So I tried with `ptrtoint`, turning the `switch` into this: %1 = ptrtoint i32* %0 to i64 switch i64 %1, label %unreachable [ i64 ptrtoint (i32* @var0 to i64), label %var0 i64 ptrtoint (i32* @var1 to i64), label %var1 ] I'm a bit baffled by that one. According to the documentation...

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

...rs as pointer typed in instcombine. Likely just a missing case in > the code I added/touched there. > > On Mon, Jan 14, 2019 at 3:23 AM Juneyoung Lee via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hello all, >> >> This is a proposal for reducing # of ptrtoint/inttoptr casts which are not >> written by programmers but rather generated by LLVM passes. >> Currently the majority of ptrtoint/inttoptr casts are generated by LLVM; >> when compiling SPEC 2017 with LLVM r348082 (Dec 2 2018) with -O3, >> the output IR contains 22,771 intto...

Hello all, This is a proposal for reducing # of ptrtoint/inttoptr casts which are not written by programmers but rather generated by LLVM passes. Currently the majority of ptrtoint/inttoptr casts are generated by LLVM; when compiling SPEC 2017 with LLVM r348082 (Dec 2 2018) with -O3, the output IR contains 22,771 inttoptr instructions. However, when comp...

...inter value formed by an inttoptr is based on all pointer values > that contribute (directly or indirectly) to the computation of the > pointer's value." > > Suppose an int value 'i'  is computed by a lot of int variables that > are converted from ptr (p1,p2...pn) by ptrtoint, then if we inttoptr i > to a point p, how should I decide which pointer value the 'p' forms? > > If those p_j are ptrtoint to a i_j, and the computation for i is i = > i_0 + i_1 + ... i_n, does it mean >  we can take either p_j as a base pointer, and other int variables >...

...t it. > > My initial thought is that the pattern below can be optimized > > but I haven't spend too much time on it. > > > ~ Johannes > > > On 7/2/20 11:26 AM, Alexey Zhikhartsev via llvm-dev wrote: >> 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.no...

...rom alloca is definitely smaller than 42. Since the LLVM IR does not state that load/store-ing out-of-bound address is undefined http://llvm.org/docs/LangRef.html#i_load http://llvm.org/docs/LangRef.html#i_store I looked into the alias-rule to find answers. Now, come back to the inttoptr and ptrtoint questions. When we consider a memory access via pointers from int is defined, do we mean 1) the value of the pointer happens to equal to an address within a range of an allocated object, or 2) the value of the pointer happens to be based on some allocated objects per these rules, but it is fine...

...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 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 this rule: "A pointer value formed by an inttoptr is based on all pointer values that contribute (directly or indirectly) to the computation of the pointer's value." Suppose an int value 'i' is computed by a lot of int variables that are converted from ptr (p1,p2...pn) by ptrtoint, then if we inttoptr i to a point p, how should I decide which pointer value the 'p' forms? If those p_j are ptrtoint to a i_j, and the computation for i is i = i_0 + i_1 + ... i_n, does it mean we can take either p_j as a base pointer, and other int variables its offset, say we take p_2...

...;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] >>> %199 = add i64 %198, %197 ;<i64> [#uses=1] >>> %200 = inttoptr i64 %199 to i8* ;<i8*> [#uses=1] >>> into >>> %200 = getelementptr %193, %196 >...