bcm5719-llvm/polly/lib/Analysis, branch meklort-10.0.1

[NFC] Fixes -Wrange-loop-analysis warnings

2020-01-06T16:37:41+00:00

This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D72210

[polly][Support] Un-break polly tests

2020-01-01T22:29:04+00:00

Previously, the polly unit tests were stuck in a infinite loop. There was an edge case in StringRef::count() introduced by 9f6b13e5cce96066d7262d224c971d93c2724795, where an empty 'Str' would cause the function to never exit. Also fixed usage in polly.

Sink all InitializePasses.h includes

2019-11-14T00:34:37+00:00

This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of recompilation. I found this fact by looking at this table, which is sorted by the number of times a file was changed over the last 100,000 git commits multiplied by the number of object files that depend on it in the current checkout: recompiles touches affected_files header 342380 95 3604 llvm/include/llvm/ADT/STLExtras.h 314730 234 1345 llvm/include/llvm/InitializePasses.h 307036 118 2602 llvm/include/llvm/ADT/APInt.h 213049 59 3611 llvm/include/llvm/Support/MathExtras.h 170422 47 3626 llvm/include/llvm/Support/Compiler.h 162225 45 3605 llvm/include/llvm/ADT/Optional.h 158319 63 2513 llvm/include/llvm/ADT/Triple.h 140322 39 3598 llvm/include/llvm/ADT/StringRef.h 137647 59 2333 llvm/include/llvm/Support/Error.h 131619 73 1803 llvm/include/llvm/Support/FileSystem.h Before this change, touching InitializePasses.h would cause 1345 files to recompile. After this change, touching it only causes 550 compiles in an incremental rebuild. Reviewers: bkramer, asbirlea, bollu, jdoerfert Differential Revision: https://reviews.llvm.org/D70211

Fix Polly

2019-10-21T15:48:42+00:00

llvm-svn: 375421

[ScopBuilder] Fix bug 38358 by preserving correct order of ScopStmts.

2019-10-17T23:55:35+00:00

ScopBuilder::buildEqivClassBlockStmts creates ScopStmts for instruction groups in basic block and inserts these ScopStmts into Scop::StmtMap, however, as described in llvm.org/PR38358, comment #5, StmtScops are inserted into vector ScopStmt[BB] in wrong order. As a result, ScopBuilder::buildSchedule creates wrong order sequence node. Looking closer to code, it's clear there is no equivalent classes with interleaving isOrderedInstruction(memory access) instructions after joinOrderedInstructions. Afterwards, ScopStmts need to be created and inserted in the original order of memory access instructions, however, at the moment ScopStmts are inserted in the order of leader instructions which are probably not memory access instructions. The fix is simple with a standalone loop scanning isOrderedInstruction(memory access) instructions in basic block and inserting elements into LeaderToInstList one by one. The patch also removes double reversing operations which are now unnecessary. New test preserve-equiv-class-order-in-basic_block.ll is also added. Differential Revision: https://reviews.llvm.org/D68941 llvm-svn: 375192

[Polly] Fix formatting violation. NFC.

2019-10-11T03:09:24+00:00

llvm-svn: 374504

[Stats] Fix polly build due to change in llvm::Statistic constructor in r374490.

2019-10-11T01:43:36+00:00

llvm-svn: 374497

[ScopBuilder] Skip getting leader when merging statements to close holes.

2019-09-13T01:04:38+00:00

Function joinOrderedInstructions merges instructions when a leader is encountered twice. It also notices that leaders in SeenLeaders may lose their leadership in previous merging, and tries to handle the case using following code: Instruction *PrevLeader = UnionFind.getLeaderValue(SeenLeaders.back()); However, this is wrong because it always gets leader for the last element of SeenLeaders, and I believe it's wrong even we get leader for Prev here. As a result, Statements in cases like the one in patch aren't merged as expected. After investigation, I believe it's unnecessary to get leader instruction at all. This is based on fact: Although leaders in SeenLeaders could lose leadership, they only lose to others in SeenLeaders, in other words, one existing leader will be chosen as new leader of merged equivalent statements. We can take advantage of this and simply check if current leader equals to Prev and break merging if it does. The patch also adds a new test. Patch by bin.narwal Differential Revision: https://reviews.llvm.org/D67007 llvm-svn: 371801

[DependenceInfo] Compute WAR dependence info using ISL kills. NFC.

2019-08-29T18:55:55+00:00

When reading code of Dependences::calculateDependences, I noticed that WAR is computed specifically by buildWAR. Given ISL now supports "kills" in approximate dataflow analysis, this patch takes advantage of it. This patch also cleans up a couple lines redundant codes. Patch by bin.narwal Differential Revision: https://reviews.llvm.org/D66741 llvm-svn: 370396

[ScopBuilder] Remove superfluous while loop in buildDomains. NFC.

2019-08-29T14:42:41+00:00

The while loop iterating parent loop in ScopBuilder::buildDomains is unnecessary because either L or LD are later unused, this is a simple patch removing it. Patch by bin.narwal Differential Revision: https://reviews.llvm.org/D66698 llvm-svn: 370368