search for: inttoptr

...6/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're ar...

Hi, I am observing some incorrect behavior in basicaa, wherein two pointers that basicaa should determine to be MustAlias are ending up NoAlias - the other extreme :( I am blaming this on basicaa not handling inttoptr. Here is the relevant IR snippet. -------------------- %sunkaddr36 = ptrtoint %struct.BitParams* %bs to i32 %sunkaddr37 = add i32 %sunkaddr36, 16 %sunkaddr38 = inttoptr i32 %sunkaddr37 to i32* %sunkaddr39 = ptrtoint %struct.BitParams* %bs to i32 %sunkaddr40 = add i32 %sunkaddr39, 16 %...

LLVM 2.7's ScalarEvolution.cpp has this scary comment: // It's tempting to handle inttoptr and ptrtoint as no-ops, however this can // lead to pointer expressions which cannot safely be expanded to GEPs, // because ScalarEvolution doesn't respect the GEP aliasing rules when // simplifying integer expressions. I think I understand what the comment is saying. If a GEP has inbou...

Hi again. I have a complex type system in my custom language that isn't easily representable as LLVM IR types, so I figured I could mostly get along with treating my types as i8* and doing the appropriate bitcasts and inttoptr instructions, and doing pointer arithmetic myself (by casting the pointers to ints, adding the appropriate byte offsets, and then casting back to pointers). However, I've found some oddities. While I have no problems generating IR, when I run it through the optimizer (opt -O3), it generates w...

...ndefined behavior, so it isn't safe in any sense. In practice, I can't think of a common transformation that would cause a crash, but it's best not to depend on that. > Then it comes to my another question. The base-on relation has 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 &...

...the result from 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, b...

RFC: GEP as canonical form for pointer addressing I would like to propose that we designate GEPs as the canonical form for pointer addressing in LLVM IR before CodeGenPrepare. Corollaries 1) It is legal for an optimizer to convert inttoptr+arithmetic+inttoptr sequences to GEPs, but not vice versa. 2) Input IR which does not contain inttoptr instructions will never contain inttoptr instructions (before CodeGenPrepare.) I've spoken with Nick Lewycky & Owen Anderson offline at the last social. On first reflection, both were...

...=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 ; <i32*> [#uses=1] %10 = load i32* %9, align 8 ; <i32> [#uses=1] %11 = inttoptr i32 %10 to i8* ; <i8*> [#uses=1] %12 = ptrtoint i8* %7 to i64 ; <i64> [#uses=1] %13 = ptrtoint i8* %11 to i64 ; <i64> [#uses=1] %14 = add i64 %12, %13 ; <i64> [#uses=1] %15 = inttoptr i64...

...load >   http://llvm.org/docs/LangRef.html#i_store > I looked into the alias-rule to find answers. That doesn't really have anything to do with aliasing, but it's definitely undefined. Don't know off the top of my head where that is stated in LangRef. > 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 > obj...

Thank you for the hint. I adjusted the code and it works: The code after replacing inttoptr with getelementptr: define { i32, i32, i8* } @test(i32 %foo, i32 %bar, i8* %sp) { entry: ; push foo (On "stack") %sp_1 = getelementptr i8, i8* %sp, i32 -4 %sp_1_ptr = bitcast i8* %sp_1 to i32* store i32 %foo, i32* %sp_1_ptr, align 4 ; push bar %sp_2 = getelementptr i8, i8* %...

...; [#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 >>> Reducing the unnecessary casts of converting to integers and then back? >>> Thanks, >>> Arushi >>> > See http://llvm.org/docs/LangRef.htm...

...label %12 > > ; <label>:12: ; preds = %12, %10 > %13 = phi i64 [ %25, %12 ], [ %11, %10 ] > %14 = phi i32* [ %24, %12 ], [ %0, %10 ] > %15 = phi i32* [ %23, %12 ], [ %2, %10 ] > %16 = phi i64 [ %22, %12 ], [ %6, %10 ] > %17 = inttoptr i64 %16 to i32* > %18 = load i32, i32* %17, align 4, !tbaa !1 > %19 = load i32, i32* %15, align 4, !tbaa !1 > %20 = add nsw i32 %19, %18 > store i32 %20, i32* %14, align 4, !tbaa !1 > %21 = getelementptr inbounds i32, i32* %17, i64 1 > %22 = ptrtoint i32* %21 to i64 &g...

...nter 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 inttoptr instr...

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

...s/LangRef.html#i_store >> I looked into the alias-rule to find answers. > > That doesn't really have anything to do with aliasing, but it's > definitely undefined.  Don't know off the top of my head where that is > stated in LangRef. > >> 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 al...

Hi again, So I finally gave up on trying to get through the converting (x86' push pop mov add) because it deals a lot with crazy pointer arithmetics and sonce inttoptr and ptrtoint doesn't provide any alias analysis information. Daniel, you said it doesn't make much sense to provide it but in my cases it is actually very much needed, you didn't say it wasn't possible to provide it but it is possible right? Could you guide me through where I should...

..., Pranav Bhandarkar <pranavb at codeaurora.org> wrote: > Hi, > > I am observing some incorrect behavior in basicaa, wherein two pointers that > basicaa should determine to be MustAlias are ending up NoAlias - the other > extreme :( > I am blaming this on basicaa not handling inttoptr. Here is the relevant IR > snippet. > -------------------- > %sunkaddr36 = ptrtoint %struct.BitParams* %bs to i32 > %sunkaddr37 = add i32 %sunkaddr36, 16 > %sunkaddr38 = inttoptr i32 %sunkaddr37 to i32* > > > > %sunkaddr39 = ptrtoint %struct.BitParams* %bs to i32 &...

...herwise the behavior is undefined." So this means the conversion discussed here is still safe in terms of memory safety, but its meaning after conversion could be weird. Am I correct? Then it comes to my another question. The base-on relation has 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...

On Sep 9, 2010, at 1:48 PM, David Greene wrote: > LLVM 2.7's ScalarEvolution.cpp has this scary comment: > > // It's tempting to handle inttoptr and ptrtoint as no-ops, however this can > // lead to pointer expressions which cannot safely be expanded to GEPs, > // because ScalarEvolution doesn't respect the GEP aliasing rules when > // simplifying integer expressions. > > I think I understand what the comment is sayin...

...e "stack" as like on x86 when using push/pop so afterwards I can use LLVM's optimizer passes to simplify (reduce junk) the code. The LLVM IR code: define { i32, i32, i32 } @test(i32 %foo, i32 %bar, i32 %sp) { ; push foo (On "stack") %sp_1 = sub i32 %sp, 4 %sp_1_ptr = inttoptr i32 %sp_1 to i32* store i32 %foo, i32* %sp_1_ptr, align 4 ; push bar %sp_2 = sub i32 %sp_1, 4 %sp_2_ptr = inttoptr i32 %sp_2 to i32* store i32 %bar, i32* %sp_2_ptr, align 4 ; val1 = pop (val1 = bar) %sp_3_ptr = inttoptr i32 %sp_2 to i32* %val1 = load i32, i32* %sp_3_ptr, align 4...