similar to: FYI, planning to enable nontrivial loop unswitch in the new PM at O3

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'

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

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

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

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

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 :

* 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

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

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

Hi, I am planning to begin a project to explore the space of tuning LLVM internals in an effort to increase performance. I am wondering if anyone can point to me any parameterizations, heuristics, or priorities functions within LLVM that can be tuned/adjusted. So far, I'm considering BranchProbabilityInfo and InlineCost. Does anyone have any other suggestions? Thanks, Robert

> On Sep 14, 2015, at 12:15 PM, Philip Reames <listmail at philipreames.com> wrote: > > On 09/04/2015 01:25 PM, Owen Anderson via llvm-dev wrote: >> 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

Hello, I am trying to simplify the CFG of a given code and eliminate the conditionals, even though I will obtain codes that are not semantically equivalent. For example, given a simple loop: for(i=0; i<N; i++){    a[i] = i;     if (i%2==0)       a[i] += 12; } I would keep only the loop, without the if statement: for(i=0; i<N; i++){    a[i] = i; } I can eliminate such conditionals on

Chandler et al, I have been playing with the new PM pipeline, being particularly interested in how it can handle devirtualization. Now, I discovered what I believe is a "regression" vs old PM on a rather simple one-translation-unit testcase. clang is able to devirtualize it with -O3 and fails to do so with -fexperimental-new-pass-manager added. It looks like a pipeline issue,

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

Yes, this looks broken in the new PM. The DevirtSCCRepeatedPass::run method first scans the functions in the SCC to collect value handles for indirect calls, runs the CGSCC pass pipeline and then checks if any of the call value handles now point to a direct call, in which case it runs the pipeline again (which should inline the devirtualized call) . The problem is scanning the initial SCC for

Recently I was looking into porting IRCE loop pass into the new pass manager and stumbled on a problem. The problem is due to the existing hard dependency of IRCE on BranchProbability analysis. If I understand it right, in a new pass manager there are only two ways for loop analysis to ask for the result of an "outer" (function/module-level) analysis:   - get it from a predefined

Hi, I'm surprised by the result of compiling the following lines of code: for (int i = 0; i < RANDOM_CHUNKS; i++) { for (int j = 0; j < RANDOM_CHUNK_SIZE; j++) { random_text[i][j] = (int)(ran()*256); } } The problem happens when -fsanitize=undefined, -fno-sanitize-recover and -O3 are enabled. In this case, UndefinedBehaviorSanitizer inserts check for array index out of

Stepan Dyatkovskiy wrote: > Hi all. > > Looking at test/Transforms/LoopUnswitch/preserve-analyses.ll, I found > improper phi instruction at string #122: > %call.i25.lcssa48 = phi i8* [ %call.i25, %if.then31.i.i ], [ %call.i25, > %if.then31.i.i ] ;<i8*> [#uses=0] > Is it trick or mistake? What's improper about it? The block may have two predecessors, both of which