similar to: Reducing the number of ptrtoint/inttoptrs that are generated by LLVM

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

On Mon, Jan 14, 2019 at 4:51 PM Chandler Carruth <chandlerc at gmail.com> wrote: > > On Mon, Jan 14, 2019, 15:59 Mehdi AMINI <joker.eph at gmail.com wrote: > >> >> >> 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

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?

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

Hello Sanjoy, Yep, combining it with propagateEquality of pointers may raise problem. :\ However I believe propagateEquality should be fixed properly, and adding psub also suggests a solution for that. :) It is sound to replace a pointer with another if subtraction of them is 0: a = malloc() free(a) b = malloc() // Assume b == a numerically if ((psub inbounds a b) == 0) { // a and b are

> As with many things in the C and C++ specifications, this has very > little relationship to real-world code. The biggest example I've seen > that violates this rule is the way that the FreeBSD kernel implements > per-CPU storage, but in a fairly ad-hoc analysis of existing C/C++ code > we found quite a few cases where subtraction occurred between objects. Hello David, If C

Hi, I try to understand why llvm can't optimize this small piece of code. My expectation is that the IR will be optimized to a " ret i64 2101545. But somehow the alias analysis fails when the pointer is casted to an integer value, so the dead code eliminator can't optimize it away. Could someone explain to me why this is failing and if there is a solution for that ? I can trick the

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

Hi Andy, Andrew Trick wrote: > Sanjoy, > > This looks very close to my understanding of the statepoint design trajectory when you first introduced it. It’s great that you followed through and took the time to formalize the IR semantics. It’s been a couple years since I’ve thought about it so I may ask some obtuse questions. > > I think he subject line is wrong though! Did

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

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

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

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

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

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]

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.