search for: unswitching

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() &g...

Hi, I have a general question on LoopUnswtich pass. Consider the following IR snippet: define i32 @test(i1 %cond) { br label %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

...r float computation that is dependent on induction variable? -Ganesh From: Friedman, Eli [mailto:efriedma at codeaurora.org] Sent: Saturday, May 12, 2018 12:36 AM To: Gopalasubramanian, Ganesh <Ganesh.Gopalasubramanian at amd.com>; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Query on unswitching + vectorization 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 use...

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'

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

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

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

...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 the m...

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

...s 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, Nuno -----Original Message----- From: Sanjoy Das Sent: 16 de julho de 2017 02:47 To: Wei Mi Cc: llvm-dev...

I would like to begin a discussion about updating LLVM's opt-report infrastructure. There are some things I'd like to be able to do with optimization reports that I don't think can be done, or at least aren't natural to do, with the current implementation. I understand that there is a lot of code in place already to produce optimization remarks, and one of my explicit goals is to

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

For the example code below, int L = M + 10; for (k = 1 ; k <=L; k++) { dummy(); if (k < M) dummy2(); } , we can split the loop into two parts like : for (k = 1 ; k != M; k++) { dummy(); dummy2(); } for (; k <=L; k++) { dummy(); } By splitting the loop, we can remove the conditional block in the loop and indirectly increase vectorization

On Fri, Feb 23, 2018 at 12:15 AM, Jun Lim via llvm-dev <llvm-dev at lists.llvm.org> wrote: > For the example code below, > int L = M + 10; > for (k = 1 ; k <=L; k++) { > dummy(); > if (k < M) > dummy2(); > } > , we can split the loop into two parts like : > > for (k = 1 ; k != M; k++) { > dummy(); > dummy2(); > }

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

On 2018-02-22 16:21, Roman Lebedev wrote: > On Fri, Feb 23, 2018 at 12:15 AM, Jun Lim via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> For the example code below, >> int L = M + 10; >> for (k = 1 ; k <=L; k++) { >> dummy(); >> if (k < M) >> dummy2(); >> } >> , we can split the loop into two parts like :

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

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

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