search for: uglygep

I'm curious why I am seeing this: *%uglygep18.sum = add i32 %lsr_iv8, %tmp45* %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum %scevgep1920 = bitcast i8* %scevgep19 to i16* %tmp78 = load i16* %scevgep1920, align 2 * %uglygep14.sum = add i32 %lsr_iv8, %tmp45* %scevgep15 = getelementptr i8* %extIn_013, i32 %uglygep14_su...

...ndant operations, should it not clean itself up? Or am I mistaken? On Fri, Oct 19, 2012 at 1:29 PM, Andrew Trick <atrick at apple.com> wrote: > > On Oct 17, 2012, at 1:22 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I'm curious why I am seeing this: > > *%uglygep18.sum = add i32 %lsr_iv8, %tmp45* > %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum > %scevgep1920 = bitcast i8* %scevgep19 to i16* > %tmp78 = load i16* %scevgep1920, align 2 > * %uglygep14.sum = add i32 %lsr_iv8, %tmp45* > %scevgep15 = getelementptr i8* %ext...

...h: ; preds = %for.body.4.lr.ph.preheader, %for.cond.cleanup.3 %lsr.iv17 = phi i32 [ %Size, %for.body.4.lr.ph.preheader ], [ %lsr.iv.next18, %for.cond.cleanup.3 ] %lsr.iv10 = phi i32 [ 0, %for.body.4.lr.ph.preheader ], [ %lsr.iv.next11, %for.cond.cleanup.3 ] %uglygep = getelementptr i8, i8* %Src12, i32 %lsr.iv10 %uglygep13 = bitcast i8* %uglygep to i32* %uglygep15 = getelementptr i8, i8* %Dst14, i32 %lsr.iv10 %uglygep1516 = bitcast i8* %uglygep15 to i32* br label %for.body.4 for.body.4: ; preds = %for.body.4, %...

...er: entry: tail call void @fill_array(i32* getelementptr inbounds ([10 x i32], [10 x i32]* @buffer, i32 0, i32 0)) #2 br label %while.body ; Loop: while.body: ; preds = %while.body, %entry %lsr.iv = phi i32 [ %lsr.iv.next, %while.body ], [ 0, %entry ] %uglygep = getelementptr i8, i8* bitcast ([10 x i32]* @buffer to i8*), i32 %lsr.iv %uglygep1 = bitcast i8* %uglygep to i32* %0 = load i32, i32* %uglygep1, align 4, !tbaa !2 %cmp1 = icmp ne i32 %0, -559038737 %cmp11 = icmp eq i32 %lsr.iv, 0 %cmp = or i1 %cmp11, %cmp1 %lsr.iv.next = add nuw i32 %l...

On Wed, Oct 17, 2012 at 1:22 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I'm curious why I am seeing this: > > %uglygep18.sum = add i32 %lsr_iv8, %tmp45 > %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum > %scevgep1920 = bitcast i8* %scevgep19 to i16* > %tmp78 = load i16* %scevgep1920, align 2 > %uglygep14.sum = add i32 %lsr_iv8, %tmp45 > %scevgep15 = getelementptr i8* %extIn_...

On Oct 17, 2012, at 1:22 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I'm curious why I am seeing this: > > %uglygep18.sum = add i32 %lsr_iv8, %tmp45 > %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum > %scevgep1920 = bitcast i8* %scevgep19 to i16* > %tmp78 = load i16* %scevgep1920, align 2 > %uglygep14.sum = add i32 %lsr_iv8, %tmp45 > %scevgep15 = getelementptr i8* %extIn_...

.... As far as I can tell, there is no advantage to what LLVM is doing here (such as re-using pointer arithmetic computations). The 'Often Misunderstood GEP page' makes it sound like optimization always replaces pointer arithmetic with GEP instructions at the end, even if it might be an 'uglygep' (is this an instruction? it isn't in the language reference) instead of a getelementptr. Is the problem that my pass is not at the end of the optimization passes? If this is the case, how can I more effectively guarantee this? Right now I'm adding my pass immediately before MachineMod...

...itself up? Or am I mistaken? > > On Fri, Oct 19, 2012 at 1:29 PM, Andrew Trick <atrick at apple.com> wrote: > >> >> On Oct 17, 2012, at 1:22 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: >> >> I'm curious why I am seeing this: >> >> *%uglygep18.sum = add i32 %lsr_iv8, %tmp45* >> %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum >> %scevgep1920 = bitcast i8* %scevgep19 to i16* >> %tmp78 = load i16* %scevgep1920, align 2 >> * %uglygep14.sum = add i32 %lsr_iv8, %tmp45* >> %scevgep15 = ge...

...t. These tests are failing because the original test file is not in LCSSA form, so running LCSSA before something like -loop-reduce changes the input to LSR. This can be repro'd under the legacy PM by changing the test to also run `-lcssa`. One example is llvm/test/Transforms/LoopStrengthReduce/uglygep.ll (RUN: opt < %s -lcssa -loop-reduce -S | FileCheck %s). Any thoughts on how to fix these 30-35 tests? Manually convert them to LCSSA form and update the CHECK lines? Seems tricky, especially for somebody without much experience with these passes. Some of these do use update_test_checks, but s...

...n opts" (or something similar to this)? Thanks. On Wed, Oct 17, 2012 at 1:44 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > On Wed, Oct 17, 2012 at 1:22 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > I'm curious why I am seeing this: > > > > %uglygep18.sum = add i32 %lsr_iv8, %tmp45 > > %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum > > %scevgep1920 = bitcast i8* %scevgep19 to i16* > > %tmp78 = load i16* %scevgep1920, align 2 > > %uglygep14.sum = add i32 %lsr_iv8, %tmp45 > > %scevgep15 =...

...it not clean itself up? Or am I mistaken? > > On Fri, Oct 19, 2012 at 1:29 PM, Andrew Trick <atrick at apple.com> wrote: > > On Oct 17, 2012, at 1:22 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > >> I'm curious why I am seeing this: >> >> %uglygep18.sum = add i32 %lsr_iv8, %tmp45 >> %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum >> %scevgep1920 = bitcast i8* %scevgep19 to i16* >> %tmp78 = load i16* %scevgep1920, align 2 >> %uglygep14.sum = add i32 %lsr_iv8, %tmp45 >> %scevgep15 = getel...

On Wed, Sep 23, 2015 at 12:00 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> >> Should we try the patch in it's current location, namely after LSR? > > Sure; post the patch as you have it so we can look at what's going on. > http://reviews.llvm.org/D12494 One particular point: The algorithm checks that SCEV's are equal when their raw pointers are equal. Is

...mistaken? >> >> On Fri, Oct 19, 2012 at 1:29 PM, Andrew Trick <atrick at apple.com> wrote: >> >> On Oct 17, 2012, at 1:22 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: >> >>> I'm curious why I am seeing this: >>> >>> %uglygep18.sum = add i32 %lsr_iv8, %tmp45 >>> %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum >>> %scevgep1920 = bitcast i8* %scevgep19 to i16* >>> %tmp78 = load i16* %scevgep1920, align 2 >>> %uglygep14.sum = add i32 %lsr_iv8, %tmp45 >>>...

...there is no advantage to what LLVM is doing here (such > as re-using pointer arithmetic computations). > > The 'Often Misunderstood GEP page' makes it sound like optimization always > replaces pointer arithmetic with GEP instructions at the end, even if it > might be an 'uglygep' (is this an instruction? it isn't in the language > reference) instead of a getelementptr. Is the problem that my pass is not at > the end of the optimization passes? If this is the case,  how can I more > effectively guarantee this? Right now I'm adding my pass immediately be...

...? > > Thanks. > > > On Wed, Oct 17, 2012 at 1:44 PM, Eli Friedman <eli.friedman at gmail.com>wrote: > >> On Wed, Oct 17, 2012 at 1:22 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: >> > I'm curious why I am seeing this: >> > >> > %uglygep18.sum = add i32 %lsr_iv8, %tmp45 >> > %scevgep19 = getelementptr i8* %parBits_017, i32 %uglygep18_sum >> > %scevgep1920 = bitcast i8* %scevgep19 to i16* >> > %tmp78 = load i16* %scevgep1920, align 2 >> > %uglygep14.sum = add i32 %lsr_iv8, %tmp45 >>...

On Mon, Nov 4, 2019 at 4:00 PM James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > To throw my hat into the ring, we also maintain a downstream target that > has a subset of this problem - it has non-8-bit-addressable memory. This > means that %uglygeps don't work, pointers can't be casted to i8* and expect > to be byte-addressed (conversions to memcpy/memset that use i8* aren't > welcome either), and GEP lowering code is slightly different. > > We maintain this currently as a pile of known technical debt. We have a > C...

Hm, no. I expect byte addresses - everywhere. The compiler should not know that the arch needs word addresses. During lowering LOAD and STORE get explicit conversion operations for the memory address. Even if my arch was byte addressed the code would be false/illegal. Boris > Am 09.06.2020 um 19:36 schrieb Eli Friedman <efriedma at quicinc.com>: > > Blindly guessing here,

On Sat, Nov 2, 2019 at 12:45 AM Jorg Brown via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Nov 1, 2019 at 8:40 AM Adrian Prantl via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > On Nov 1, 2019, at 3:41 AM, Dmitriy Borisenkov via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> > It seems that there are two possible

Hi, I want to improve the way CGP sinks the incoming values of a PHI node towards memory accesses. Improving it means a lot to some of our key benchmarks, and I believe can benefit many general cases as well. CGP's OptimizeMemoryInst function handles PHI nodes by running AddressingModeMatcher on all incoming values to see whether they reach consensus on the addressing mode. It does a