search for: unswitches

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++) { if (w==1) { y[i] = 1; tmp = i*2; }...

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() > > { > >   for (i = 0; i < 1000; i++) { > >...

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

...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 user" apparently which is the value of 'tmp'. int i, w, x[1000], y[1000],tmp; void fn() { for (i = 0; i < 1000; i++) { if (w==1) { y[i] = 1; tmp = i*2; }...

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,

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

Hello, Recently I've come across two instances where Induction Variable Simplification lead to noticable performance regressions. In one case, the removal of extra IV lead to the inability 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

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

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

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

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(); > }

The issue blocks another optimization patch and Wei has spent huge amount of effort isolating the the bootstrap failure to this same problem. I agree with Wei that other developers may also get hit by the same issue and the cost of leaving this issue open for long can be very high to the community. David On Mon, Jul 17, 2017 at 10:01 AM, Wei Mi <wmi at google.com> wrote: > Sanjoy and

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

Hi Jingyue, I consider it a very important element of the design of convergent that it does not require baseline LLVM to contain a definition of uniformity, which would itself pull in a definition of SIMT/SPMD, warps, threads, etc. The intention is that it should be a conservative (but hopefully not too conservative) approximation, and that implementations of specific GPU programming models

Hi all, I would like to propose an improvement of the “almost dead” block elimination in Transforms/Local.cpp so that it will preserve the canonical loop form for loops with a volatile iteration variable. *** Problem statement Nested loops in LCALS Subset B (https://codesign.llnl.gov/LCALS.php) are not vectorized with LLVM -O3 because the LLVM loop vectorizer fails the test whether the loop