search for: uglygeps

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_sum %scevgep1516 = bitcast i8* %scevgep15 to i16*

That solves the issue but it seems odd to me that instcombine doesn't take care of it? So is this just a setup for the backend? If not, seems like if there is a possibility that lsr could create these redundant 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,

Hi Steve, Do you primarily find this to help for nested loops? If so, that could be because LSR explicitly bails out of processing them: // Skip nested loops until we can model them better with formulae. if (!L->empty()) { DEBUG(dbgs() << "LSR skipping outer loop " << *L << "n"); return; } I don't know how much time you're

The IR after LSR is: *** IR Dump After Loop Strength Reduction *** ; Preheader: 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

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

Hello, I am working on an application of LLVM where I would strongly prefer that getelementptr not be lowered into pointer arithmetic by any passes other than my own. I'm writing a ModulePass. I am observing a situation where I compile a C++ file with no optimization and I get code as I would expect that uses getelementptr. However, if I enable optimization with -O3, *some* of my

Ok, thanks. Even still though I would expect -instcombine (run after lsr) would do this cleanup? On Fri, Oct 19, 2012 at 2:41 PM, Andrew Trick <atrick at apple.com> wrote: > > On Oct 19, 2012, at 2:34 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > > That solves the issue but it seems odd to me that instcombine doesn't take > care of it? > > > LSR is

In an effort to turn on the new pass manager by default, I've been trying to make all lit tests pass when opt uses the new pass manager. (Change the default value of -enable-new-pm in opt.cpp to true to repro) A good chunk of the remaining failures are some loop pass tests, mostly LSR, that are failing. The legacy PM does not by default run LCSSA before running loop passes, but the new PM

Eli, Thanks. So I'm unclear exactly which llvm opt will exhibit copy prop. behavior? It seems to me that codegenprepare is doing a useful thing (for me, since I'm just using the llvm IR and not going to backend, providing it's "exposing" and not simply "adding for layout for CodeGen opts" (or something similar to this)? Thanks. On Wed, Oct 17, 2012 at 1:44

On Oct 19, 2012, at 2:34 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > That solves the issue but it seems odd to me that instcombine doesn't take care of it? LSR is part of the backend. It's lowering the IR for a specific target. It seems to think those redundant operations are good for reducing register pressure, but doesn't actually have much knowledge about register

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

On Oct 19, 2012, at 2:44 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Ok, thanks. > > Even still though I would expect -instcombine (run after lsr) would do this cleanup? It's valid to run any IR pass after -loop-reduce. So you can try it. -gvn is probably what you're looking for. It isn't something we normally want to do. Turn off LSR if it does bad things on

On Wed, Feb 29, 2012 at 11:00 AM, Dillon Sharlet <dsharlet at gmail.com> wrote: > Hello, > > I am working on an application of LLVM where I would strongly prefer that > getelementptr not be lowered into pointer arithmetic by any passes other > than my own. I'm writing a ModulePass. > > I am observing a situation where I compile a C++ file with no optimization >

Eli, Actually, I stil see this issue without codegenprepare being used. I'm also compiling with -o3. So I'm still not sure why I'm seeing this issue? Thanks. On Wed, Oct 17, 2012 at 1:54 PM, Ryan Taylor <ryta1203 at gmail.com> wrote: > Eli, > > Thanks. So I'm unclear exactly which llvm opt will exhibit copy prop. > behavior? > > It seems to me

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

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