similar to: [LLVMdev] compile .bc in cpp program

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

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

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

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

On 07/18/2017 06:03 PM, David Majnemer via llvm-dev wrote: > I doubt it is possible for us to try and make any fix which is > predicated on eagerly treating undef in a particular way, refinement > will always cause these problems to come about... > > Given what I've seen in LLVM (and what I've learned from other > compilers), we probably have two choices: > 1.

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

On Mon, Jul 17, 2017 at 5:11 PM, Wei Mi <wmi at google.com> wrote: > On Mon, Jul 17, 2017 at 2:09 PM, Sanjoy Das > <sanjoy at playingwithpointers.com> wrote: >> Hi, >> >> On Mon, Jul 17, 2017 at 1:56 PM, Daniel Berlin via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> >>> >>> On Mon, Jul 17, 2017 at 1:53 PM, Wei Mi

This is a bug found by internal compiler bootstrap, and possibly it is the root cause of https://bugs.llvm.org/show_bug.cgi?id=33652 and https://bugs.llvm.org/show_bug.cgi?id=33626. Here is the testcase 1.c. The original code is at MemorySSA.cpp:586 for rL307764. ------------------------- 1.c --------------------------- long a, c, d, e, f, m, cnt, i_hasval; volatile long b; void goo(long); void

There's already a LoopSimplifyCFG which is a loop-pass (and thus can iterate with other loop passes) and eliminates trivial branches.  Having a simple pass which just strips unreachable blocks and converts conditional branches to unconditional ones while updating appropriate analyzes (LoopInfo, DomTree, LCSSA, etc..) seems very reasonable.  This could also be a utility function called

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],

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.

On Jul 11, 2012, at 2:50 AM, Chandler Carruth wrote: > In working on a new optimization pass (splitting cold regions into separate functions based on branch probabilities) I've run into some limitations of the current pass manager infrastructure. After chatting about this with Nick, it seems that there are some pretty systematic weaknesses of the current design and implementation (but not

Does LLVM have loop multiversioning ? it seems it does not with clang++ -O3 -mllvm -debug-pass=Arguments program.c -c bash-4.1$ clang++ -O3 -mllvm -debug-pass=Arguments fast_algorithms.c -c clang-3.6: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated Pass Arguments: -datalayout -notti -basictti -x86tti -targetlibinfo -no-aa -tbaa -scoped-noalias

* 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

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 01/07/2015 05:33 PM, Chandler Carruth wrote: > How does this compare with classical approaches of loop peeling, > partitioning, fission, or whatever you might call it? I'm still developing a good sense for this, but let me lay out some observations. Fair warning, this is going to be long and rambling. Let's start with a toy example: while(c) { x = this->x; y =

I did gathered aggregate statistics reported by “-stats” over the ~400 test files. The following table summarizes the impact. The first column is the sum where the new analysis is enabled, the second column is the delta from baseline where no CFL alias analysis is performed. I am not experienced enough to know which of these are “good” or “bad” indicators. —david 72,250 685 SLP

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

Hi all. By now loops with switch instruction are unswitched value-by-value. For example for case range [0..9] we need to run unswitch process 10 times! I want try to optimize that case. Is there any hidden problems that blocks this improvement? Regards, Stepan.