search for: unswitch

Hi, I am going through analysis on unswitching + vectorization. For the below test, llvm unswitches successfully but fails to vectorize the loop after unswitching. Llvm bails out saying "Found an outside user" apparently which is the value of 'tmp'. int i, w, x[1000], y[1000],tmp; void fn() { for (i = 0; i < 1000; i++...

On 5/10/2018 10:44 PM, Gopalasubramanian, Ganesh via llvm-dev wrote: > > Hi, > > I am going through analysis on unswitching + vectorization. > > For the below test, llvm unswitches successfully but fails to > vectorize the loop after unswitching. > > Llvm bails out saying “Found an outside user” apparently which is the > value of ‘tmp’. > > int i, w, x[1000], y[1000],tmp; > > void fn()...

...bel %loop_begin loop_begin: br i1 %cond, label %loop_body, label %loop_exit loop_body: br label %do_something do_something: call void @some_func() noreturn nounwind br label %loop_begin loop_exit: ret i32 0 } declare void @some_func() noreturn After running it through "opt -loop-unswitch -S", it unswitched loop on %cond and produced result like this: define i32 @test(i1 %cond) { br i1 %cond, label %..split_crit_edge, label %.loop_exit.split_crit_edge .loop_exit.split_crit_edge: ; preds = %0 br label %loop_exit.split ..split_crit_edge:...

* Looks like some sort of pass ordering issue; it will vectorize if indvars runs sometime between loop unswitch and the vectorizer. That insight is helpful. I scheduled Canonicalization of induction variable before loop vectorization and could get the loop vectorized. The indvars are heavily dependent on SCEV. If there a scalar like tmp which is of real type, we may not be able to get the indvars sorted out...

Is there any written description of what "non trivialness" is there? On Sun, Apr 29, 2018, 2:49 PM Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > One of the last big missing pieces for the new PM is enabling non-trivial > loop unswitch at O3. > > The pass is now working well and passing all the testing I have done as > well as some others' testing (thanks Fedor!) so it should be ready to be > enabled. > > I've done preliminary benchmarking on the test suite and SPEC and haven't > seen any interest...

One of the last big missing pieces for the new PM is enabling non-trivial loop unswitch at O3. The pass is now working well and passing all the testing I have done as well as some others' testing (thanks Fedor!) so it should be ready to be enabled. I've done preliminary benchmarking on the test suite and SPEC and haven't seen any interesting regressions and quite a few i...

Hi all, In light of recent discussions regarding updating passes to respect convergent semantics, and whether or not it is sufficient for barriers, I would like to propose a change in convergent semantics that should resolve a lot of the identified problems regarding loop unrolling, loop unswitching, etc. Credit to John McCall for talking this over with me and seeding the core ideas. Today, convergent operations may only be moved into control-equivalent locations, or, in layman’s terms, a convergent operation may neither be sunk into nor hoisted out of, a condition. This causes problems...

I'm looking at bug 3367. If I run: $ opt b.bc -inline -loop-rotate -loop-unswitch -debug-pass=Executions ... it eventually crashes in the inliner, because the call graph isn't up to date. (NB if you want to reproduce this you'll have to apply my patch from bug 3367 first.) The reason the call graph isn't up to date is that -loop-unswitch has changed a function and...

...lity to reschedule instructions in a tight loop to reduce stalls. In that case, there were enough registers to spare, so using extra register for extra induction variable was preferable since it reduced dependencies in the loop. In the second case, there was a big nested loop made even bigger after unswitching. However, the inner loop body was rather simple, of the form: loop { p+=n; ... p+=n; ... } use p. Due to unswitching there were several such loops each with the different number of p+=n ops, so when the IndVars pass rewrote all exit values, it added a lot of slightly different offsets to th...

Hi, > I'm looking at bug 3367. > > If I run: > > $ opt b.bc -inline -loop-rotate -loop-unswitch -debug-pass=Executions > > ... it eventually crashes in the inliner, because the call graph isn't > up to date. (NB if you want to reproduce this you'll have to apply my > patch from bug 3367 first.) > > The reason the call graph isn't up to date is that -loop-unswit...

Cool, thanks for debugging this issue and letting us know. We have a few patches to fix this issue: - Introduce freeze in IR: https://reviews.llvm.org/D29011 - Lowering freeze: https://reviews.llvm.org/D29014 - Fix loop unswitch: https://reviews.llvm.org/D29015 Bonus patches to recover perf: - Be less conservative in loop unswitching: https://reviews.llvm.org/D29016 - Instcombine support for freeze: https://reviews.llvm.org/D29013 It would be great if you could try out these patches to see if the bug goes away. Thanks...

...how the IR evolved over the course of compilation and what effects that may have had on optimizations. This mostly has to do with the handling of loops, vectorization, and inlining. Let's say, for example, I've got code like this: for (...) A if (lic) B C And the loop-unswitch pass turns it into this: if (lic) for (...) A; B; C else for (...) A; C Now let's say the vectorizer for some reason is able to vectorize the loop in the else-clause but not the if-clause. (I don't know if this kind of thing is possible with the current phase order...

Hi Adam, Thanks for your input. If I understand correctly, you’re saying that we can handle the loop versioning issue by explicitly identifying new loops as they are created. So, the unswitching optimization, for example, would report that it unswitched loop-0 at source location X, creating loop-1 and loop-2, and then later the vectorizer would report that it was unable to vectorize loop-1 at source location X, and later still that it was able to vectorize loop-2 at source location X. A...

...hat a loop has a conditional branch that is always true for one part of the iteration space and false for the other, then we can split such loop into two parts. As far as I check, GCC seems to handle this already (-fsplit-loops). For me, it seem possible to handle this as a special case of the loop-unswitch. Does anyone have any opinion about this transformation? Thanks, Jun

...hat a loop has a conditional branch that is always true for one part of the iteration space and false for the other, then we can split such loop into two parts. As far as I check, GCC seems to handle this already (-fsplit-loops). For me, it seem possible to handle this as a special case of the loop-unswitch. Does anyone have any opinion about this transformation? > > Thanks, > Jun Roman. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

...t they are some big patches > and I guess it still takes some time to get in. The issue when > compiling MemorySSA.cpp can be easily exposed by other changes, and it > is very time consuming to triage and extract the issue, so we like to > have some temporary solution, like to make loop unswitching more > conservative. If it sounds ok, I can work on it. My plan is to enhance > isGuaranteedNotToBeUndefOrPoison and use it as a precondition in loop > unswitching. > > Thanks, > Wei. > > > > On Mon, Jul 17, 2017 at 1:24 AM, Nuno Lopes <nlopes at microsoft.com&gt...

...is always true for one part of the >> iteration space and false for the other, then we can split such loop >> into two parts. As far as I check, GCC seems to handle this already >> (-fsplit-loops). For me, it seem possible to handle this as a special >> case of the loop-unswitch. Does anyone have any opinion about this >> transformation? >> >> Thanks, >> Jun > Roman. > >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mail...

On Feb 13, 2009, at 5:39 AM, Duncan Sands wrote: > Hi, > >> I'm looking at bug 3367. >> >> If I run: >> >> $ opt b.bc -inline -loop-rotate -loop-unswitch -debug-pass=Executions >> >> ... it eventually crashes in the inliner, because the call graph >> isn't >> up to date. (NB if you want to reproduce this you'll have to apply my >> patch from bug 3367 first.) >> >> The reason the call graph isn'...

...> I ask this because Bjarke recently came up with a mathematical definition of uniformity. I wonder if that is a foundation "convergent" needs as well. AFAICT, Bjarke's definition of "uniformity" is less restrictive than "convergent". For example, it allows loop unswitching the following code if "c" is uniform, which seems a case you ideally want to allow. > > DISALLOWED: > for (…) { > if (c) { … } > convergent(); > } > > Jingyue > > On Fri, Sep 4, 2015 at 1:25 PM, Owen Anderson via llvm-dev <llvm-dev at lists.llvm...

...ther the loop latch and exiting block of a loop is the same. The loops are vectorizable, and get vectorized with LLVM -O2 and also with other commercial compilers (icc, xlc). *** Details These loops ended up with different loop latch and exiting block after a series of optimizations including loop unswitching, jump threading, simplify-the-CFG, and loop simplify. The fundamental problem here is that the above optimizations cannot recognize a loop with a volatile iteration variable and do not preserve its canonical loop structure. (1) Loop unswitching generates several empty placeholder BBs only with...