search for: lcssa

So, there are two primary ideas behind SSA form management in the loop optimizers of LLVM: - Require LCSSA form input, leverage its (very powerful) guarantees to simplify maintaining SSA form, and also maintain LCSSA form. - Don't bother with LCSSA form input, assume the worst, and use powerful incremental SSA formation utilities built on SSAUpdater to form SSA on demand when needed. (Note, there...

...2014, at 11:29 AM, Chris Lattner <clattner at apple.com> wrote: > > On Feb 1, 2014, at 4:33 AM, Chandler Carruth <chandlerc at gmail.com> wrote: > >> So, there are two primary ideas behind SSA form management in the loop optimizers of LLVM: >> >> - Require LCSSA form input, leverage its (very powerful) guarantees to simplify maintaining SSA form, and also maintain LCSSA form. >> >> - Don't bother with LCSSA form input, assume the worst, and use powerful incremental SSA formation utilities built on SSAUpdater to form SSA on demand when need...

...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 does that. 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...

...+CC llvm-dev My guess is that it would be rather error prone to pinpoint exact places where we start populating new LPPassManager since it’s created lazily via LoopPass::assignPassManager. So we are risking to miss adding verifiers in some of the LPPassManager’s. One similar idea is to introduce LCSSAVerifier function pass and make LCSSA pass to be dependant on it. That will allow me to check ‘getAnalysisIfAvaliable<LCSSAVerifier>’ inside of the LPPassManager and explicitly call LCSSA verification when it’s present. This feels a quite hacky, but in theory should work. — Igor On 14 Oct 2...

...LPPassManager since it’s created lazily via LoopPass::assignPassManager. So we are risking to miss adding verifiers in some of the LPPassManager’s. > That’s true, I didn’t particularly like that either, but suggested as a potential workaround. >> >> One similar idea is to introduce LCSSAVerifier function pass and make LCSSA pass to be dependant on it. That will allow me to check ‘getAnalysisIfAvaliable<LCSSAVerifier>’ inside of the LPPassManager and explicitly call LCSSA verification when it’s present. This feels a quite hacky, but in theory should work. > We’ll always ha...

...On Oct 14, 2016, at 9:54 AM, Igor Laevsky <igor at azulsystems.com<mailto:igor at azulsystems.com>> wrote: Hi Michael, Hi Igor, Hi Michael, Hi Michael, What I was referring to is that we can write something like this inside LPPassManager iteration: if (getAnalaysisIfAvaliable<LCSSAVerifier>()) { CurrentLoop->verifyLCSSA(); ) This will have less impact but feels a bit wrong. Originally I didn’t like this idea, but the more I think about it the more I like it. Currently all loop passes use (or should use) getLoopAnalysisUsage to record their pass requirements, so all of t...

...l %for.end8 >> for.cond2.preheader.lr.ph: >> %cond22 = phi i32 [ %call, %cond.end ], [ 46, %entry ] >> %cmp314 = icmp sgt i32 %cond22, 0 >> br label %for.cond2.preheader >> for.cond2.preheader: >> %x.019 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %x.1.lcssa, >> %for.inc6 ] >> %a.018 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %inc7, %for.inc6 ] >> br i1 %cmp314, label %for.body4, label %for.inc6 >> for.body4: >> %x.116 = phi i32 [ %inc, %for.body4 ], [ %x.019, %for.cond2.preheader ] >> %b.015 = phi i32 [...

...d2.preheader.lr.ph, label %for.end8 > for.cond2.preheader.lr.ph: > %cond22 = phi i32 [ %call, %cond.end ], [ 46, %entry ] > %cmp314 = icmp sgt i32 %cond22, 0 > br label %for.cond2.preheader > for.cond2.preheader: > %x.019 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %x.1.lcssa, > %for.inc6 ] > %a.018 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %inc7, %for.inc6 ] > br i1 %cmp314, label %for.body4, label %for.inc6 > for.body4: > %x.116 = phi i32 [ %inc, %for.body4 ], [ %x.019, %for.cond2.preheader ] > %b.015 = phi i32 [ %inc5, %for.body4 ], [ 0...

...ackground: We have an issue with in loop values being correctly marked uniform but the out of loop uses can be non-uniform. Currently the out of loop users are not marked as divergent because the in loop value is uniform inside the loop. We have gotten around this problem for the moment by applying LCSSA which inserts a PHI in the loop exit for the in loop uniform value that allows the divergent info to be passed onto isel. The LCSSA is being inserted into XXXDAGToDAGISel class but this causes a pass scheduling conflict with StackProtector. So what we've done is try to preserve StackProtector...

...label %for.end8 for.cond2.preheader.lr.ph: %cond22 = phi i32 [ %call, %cond.end ], [ 46, %entry ] %cmp314 = icmp sgt i32 %cond22, 0 br label %for.cond2.preheader for.cond2.preheader: %x.019 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %x.1.lcssa, %for.inc6 ] %a.018 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %inc7, %for.inc6 ] br i1 %cmp314, label %for.body4, label %for.inc6 for.body4: %x.116 = phi i32 [ %inc, %for.body4 ], [ %x.019, %for.cond2.preheader ] %b.015 = phi i32 [ %inc5, %for.bo...

...for.cond2.preheader.lr.ph: >>> %cond22 = phi i32 [ %call, %cond.end ], [ 46, %entry ] >>> %cmp314 = icmp sgt i32 %cond22, 0 >>> br label %for.cond2.preheader >>> for.cond2.preheader: >>> %x.019 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %x.1.lcssa, >>> %for.inc6 ] >>> %a.018 = phi i32 [ 0, %for.cond2.preheader.lr.ph ], [ %inc7, %for.inc6 >>> ] >>> br i1 %cmp314, label %for.body4, label %for.inc6 >>> for.body4: >>> %x.116 = phi i32 [ %inc, %for.body4 ], [ %x.019, %for.cond2.preheader...

...deadargelim -instcombine -simplifycfg -basiccg -prune-eh -inline-cost -always-inline -functionattrs -sroa -domtree -early-cse -simplify-libcalls -lazy-value-info -jump-threading -correlated-propagation -simplifycfg -instcombine -tailcallelim -simplifycfg -reassociate -domtree -loops -loop-simplify -lcssa -loop-rotate -licm -lcssa -loop-unswitch -instcombine -scalar-evolution -loop-simplify -lcssa -indvars -loop-idiom -loop-deletion -loop-unroll -memdep -memcpyopt -sccp -instcombine -lazy-value-info -jump-threading -correlated-propagation -domtree -memdep -dse -adce -simplifycfg -instcombine -strip-...

Hi Dan, I whipped up this patch as a more optimal test of whether replacing the phi node PN by V will break LCSSA form. I hope it is more or less correct, but since I know nothing about loops it could well be completely bogus :) Can you please comment on it. Best wishes, Duncan. -------------- next part -------------- A non-text attachment was scrubbed... Name: lcssa.diff Type: text/x-patch Size: 1697 byte...

...In >> fact, the `run` method on analyses should probably be called >> `computeResult` or something like that to avoid confusion. >> >> >> >> This makes sense to me. >> >> >> >> We do currently have some "in between" passes, like LCSSA, which are >> transformations, but are required by other passes, and transform the IR but >> whose preservation represents properties of the IR. The particulars of how >> we handle LCSSA aside (e.g. I think we should preserve it more, perhaps >> everywhere), how are we plann...

...35 AM Nicolai Hähnle-Montoro <nhaehnle at gmail.com> wrote: > > Hi all, > > re-upping and renaming this thread to get some attention, as we'd like > some feedback on a change that affects the future design direction. > > The concrete problem: We would like to mark the LCSSA pass as > preserving the StackProtector pass in order to be able to properly > express all dependencies we have. Unfortunately, those passes are > defined in different modules that do not (and should not) depend on > each other, which causes linking to fail. > > Our proposal is to...

...gelim -domtree -instcombine -simplifycfg -basiccg -prune-eh -inline-cost -inline -functionattrs -argpromotion -sroa -domtree -early-cse -lazy-value-info -jump-threading -correlated-propagation -simplifycfg -domtree -instcombine -tailcallelim -simplifycfg -reassociate -domtree -loops -loop-simplify -lcssa -loop-rotate -licm -loop-unswitch -instcombine -scalar-evolution -loop-simplify -lcssa -indvars -loop-idiom -loop-deletion -function_tti -loop-unroll -memdep -mldst-motion -domtree -memdep -gvn -memdep -memcpyopt -sccp -domtree -instcombine -lazy-value-info -jump-threading -correlated-propagation -...

...x, align 8, !tbaa !5 > %add = fadd double %sum.05, %1 > %inc = add nsw i64 %i.06, 1 > > %exitcond = icmp eq i64 %inc, %n > br i1 %exitcond, label %for.end, label %for.body > > for.end: ; preds = %for.body, > %entry > %sum.0.lcssa = phi double [ 0.000000e+00, %entry ], [ %add, %for.body ] > ret double %sum.0.lcssa > } > > > and the second looks like > > double v[10000]; > > double zap(long n) { > double sum = 0; > for (long i = 0; i < n; i++) > sum += v[i]; > return sum;...

...%0, i64 %i.06 %1 = load double* %arrayidx, align 8, !tbaa !5 %add = fadd double %sum.05, %1 %inc = add nsw i64 %i.06, 1 %exitcond = icmp eq i64 %inc, %n br i1 %exitcond, label %for.end, label %for.body for.end: ; preds = %for.body, %entry %sum.0.lcssa = phi double [ 0.000000e+00, %entry ], [ %add, %for.body ] ret double %sum.0.lcssa } and the second looks like double v[10000]; double zap(long n) { double sum = 0; for (long i = 0; i < n; i++) sum += v[i]; return sum; } yielding ; ModuleID = 'z.c' target datalayout =...

...gelim -domtree -instcombine -simplifycfg -basiccg -prune-eh -inline-cost -inline -functionattrs -argpromotion -domtree -sroa -early-cse -lazy-value-info -jump-threading -correlated-propagation -simplifycfg -domtree -instcombine -tailcallelim -simplifycfg -reassociate -domtree -loops -loop-simplify -lcssa -loop-rotate -licm -loop-unswitch -instcombine -scalar-evolution -loop-simplify -lcssa -indvars -loop-idiom -loop-deletion -loop-unroll -mldst-motion -domtree -memdep -gvn -memdep -memcpyopt -sccp -domtree -bdce -instcombine -lazy-value-info -jump-threading -correlated-propagation -domtree -memdep...

...ransformations" and they are two separate things. In fact, the `run` method on analyses should probably be called `computeResult` or something like that to avoid confusion. >> >> This makes sense to me. >> >> We do currently have some "in between" passes, like LCSSA, which are transformations, but are required by other passes, and transform the IR but whose preservation represents properties of the IR. The particulars of how we handle LCSSA aside (e.g. I think we should preserve it more, perhaps everywhere), how are we planning on handling this class of things...