similar to: 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

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

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

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.

On Sun, Mar 15, 2015 at 4:34 PM Olivier Sallenave <ol.sall at gmail.com> wrote: > Hi Daniel, > > Thanks for your feedback. I would prefer not to write a new AA. Can't we > directly implement that traversal in BasicAA? > Can I ask why? Outside of the "well, it's another pass", i mean? BasicAA is stateless, so you can't cache, and you really don't

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 =

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

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 with -O0, there are only 1048

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

Hello Chandler, > ``` > void f(int *arr1, int *arr2, int length) { > intptr_t rel_offset = arr2 - arr1; > int *arr1_end = arr1 + length; > for (int *p = arr1; p < arr1_end; p += sizeof(int)) { > do_something(p, p + rel_offset); > } > } > ``` > > For example, a common loop optimization technique is something like the following in *pseudocode* (note

On 16 Nov 2016, at 21:56, Daniel Berlin <dberlin at dberlin.org> wrote: > > You keep talking about platforms, but llvm ir itself is not platform dependent. > Can you give a reference in the language reference that says that this is not legal? Nothing in the LangRef (apart from the note about non-integral pointers, which was added recently) makes any claim about the representation

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

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]

Hello Chandler, > First and foremost - how do you address correctness issues here? Because the subtraction `A - B` can escape/capture more things. Specifically, if one of `A` or `B` is escaped/captured, the > subtraction can be used to escape or capture the other pointer. So *some* of the conservative treatment is necessary. What is the plan to update all the analyses to remain correct?

Dan Gohman wrote: > On Nov 4, 2009, at 6:43 AM, Hans Wennborg wrote: > >> Here is another change I'd like to suggest to the BasicAliasAnalysis. >> >> LLVM fails to remove the dead store in the following code: >> >> %t = type { i32 } >> >> define void @f(%t* noalias nocapture %stuff ) { >> %p = getelementptr inbounds %t* %stuff, i32 0,

On Mon, Jan 14, 2019 at 9:36 AM Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > While I'm very interested in the end result here, I have some questions > that don't seem well answered yet around pointer subtraction... > > First and foremost - how do you address correctness issues here? Because > the subtraction `A - B` can escape/capture more

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.

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

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

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