search for: loopexitvalu

...l folks voiced general support, but with questions about why existing optimizations do not already catch this case. Deep dive by Wei Mi showed that the optimization is most likely not a clean-up of LSR sloppiness, but something new. Follow-up by myself confirmed that the redundancy eliminated the LoopExitValues pass exists in the original IR from Clang. As a next step, can we come to consensus on where the LoopExitValues optimization belongs? Regards, -steve

On Mon, Sep 21, 2015 at 11:13 AM, Wei Mi <wmi at google.com> wrote: > I have the same worry as Philip and Hal that the new LoopExitValues > pass may increase some live range significantly in certain cases > because it reuses value cross outerloop iterations. Like the following > hypothetical case, the value reuse will create a live range living > across loop2, loop3, .... But we can add some simple logic to obviate >...

...> Existing pass pipeline: > Loop-Closed SSA Form Pass > Loop Pass Manager > Induction Variable Simplification > Recognize loop idioms > Delete dead loops > <=== New > LoopExitValues > Function TargetTransformInfo > Loop Pass Manager > Unroll loops > Memory Dependence Analysis > I tried Wei's suggested location for the LEV pass shown above. Placing the pass here fails to find any SCEV redundancy in the test case because no...

...n the exit value of the induction variable. If the only // purpose of the loop is to compute the exit value of some derived // expression, this transformation will make the loop dead. I understand the stated purpose for the redundancy, but there is no mention of undoing the damage. The LoopExitValues pass seems to be exactly the cleanup that was missing. Do passes coming after IVS like LSR need the redundant calculations in place to identify dead loops or should IVS have cleaned up after itself immediately? Regards, -steve

Hello LLVM, This is a proposal for a new pass that improves performance and code size in some nested loop situations. The pass is target independent. >From the description in the file header: This optimization finds loop exit values reevaluated after the loop execution and replaces them by the corresponding exit values if they are available. Such sequences can arise after the

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

...ass eliminated 4 instructions. void matrix_mul(unsigned int Size, unsigned int *Dst, unsigned int *Src, unsigned int Val) { for (int Outer = 0; Outer < Size; ++Outer) for (int Inner = 0; Inner < Size; ++Inner) Dst[Outer * Size + Inner] = Src[Outer * Size + Inner] * Val; } With LoopExitValues ------------------------------- matrix_mul: testl %edi, %edi je .LBB0_5 xorl %r9d, %r9d xorl %r8d, %r8d .LBB0_2: xorl %r11d, %r11d .LBB0_3: movl %r9d, %r10d movl (%rdx,%r10,4), %eax imull %ecx, %eax movl %eax, (%rsi,%r10,4) incl %r11d incl %r9d cmpl...

Hi Steve it seems the general consensus is that the patch feels like a work-around for a problem with LSR (and possibly other loop transformations) that introduces redundant instructions. It is probably best to file a bug and a few of your test cases. Thanks Gerolf > On Sep 10, 2015, at 4:37 PM, Steve King via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Thu, Sep 10, 2015

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

Which cases does this pass handle which aren't otherwise optimized out by passes like GlobalValueNumbering or DeadCodeElimination? Thanks, Jake VanAdrighem On Thu, Sep 10, 2015 at 2:35 PM, Steve King <steve at metrokings.com> wrote: > Hello LLVM, > It seems this thread has gone cold. Is there some low risk way for > the community to take the new pass for a test drive? >

On Wed, Sep 2, 2015 at 5:36 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > Coremark really isn't a good enough test - have you run the LLVM test suite > with this patch, and what were the performance differences? For the test suite single source benches, the 235 tests improved performance, 2 regressed and 705 were unchanged. That seems very optimistic.