#
c715a5d2 |
| 21-Mar-2018 |
Krzysztof Parzyszek <kparzysz@codeaurora.org> |
[Hexagon] Eliminate subregisters from PHI nodes before pipelining
The pipeliner needs to remove instructions from the SlotIndexes structure when they are deleted. Otherwise, the SlotIndexes map has
[Hexagon] Eliminate subregisters from PHI nodes before pipelining
The pipeliner needs to remove instructions from the SlotIndexes structure when they are deleted. Otherwise, the SlotIndexes map has stale data, and an assert will occur when adding new instructions.
This patch also changes the pipeliner to make the back-edge of a loop carried dependence 1 cycle. The 1 cycle latency is added to the anti-dependence that represents the back-edge. This changes eliminates a couple of hacks added to the pipeliner to handle the latency of the back-edge. It is needed to correctly pipeline the test case for the sub-register elimination pass.
llvm-svn: 328113
show more ...
|
Revision tags: llvmorg-5.0.2-rc1 |
|
#
febf70a9 |
| 16-Mar-2018 |
David L Kreitzer <david.l.kreitzer@intel.com> |
Quiet unused variable warnings. NFC.
Differential revision: https://reviews.llvm.org/D44583
llvm-svn: 327745
|
#
4b8bcf00 |
| 07-Mar-2018 |
Roorda, Jan-Willem <jan-willem.roorda@intel.com> |
[Pipeliner] Fixed node order issue related to zero latency edges
Summary: A desired property of the node order in Swing Modulo Scheduling is that for nodes outside circuits the following holds: none
[Pipeliner] Fixed node order issue related to zero latency edges
Summary: A desired property of the node order in Swing Modulo Scheduling is that for nodes outside circuits the following holds: none of them is scheduled after both a successor and a predecessor. We call node orders that meet this property valid.
Although invalid node orders do not lead to the generation of incorrect code, they can cause the pipeliner not being able to find a pipelined schedule for arbitrary II. The reason is that after scheduling the successor and the predecessor of a node, no room may be left to schedule the node itself.
For data flow graphs with 0-latency edges, the node ordering algorithm of Swing Modulo Scheduling can generate such undesired invalid node orders. This patch fixes that.
In the remainder of this commit message, I will give an example demonstrating the issue, explain the fix, and explain how the the fix is tested.
Consider, as an example, the following data flow graph with all edge latencies 0 and all edges pointing downward.
``` n0 / \ n1 n3 \ / n2 | n4 ```
Consider the implemented node order algorithm in top-down mode. In that mode, the algorithm orders the nodes based on greatest Height and in case of equal Height on lowest Movability. Finally, in case of equal Height and Movability, given two nodes with an edge between them, the algorithm prefers the source-node.
In the graph, for every node, the Height and Movability are equal to 0. As will be explained below, the algorithm can generate the order n0, n1, n2, n3, n4. So, node n3 is scheduled after its predecessor n0 and after its successor n2.
The reason that the algorithm can put node n2 in the order before node n3, even though they have an edge between them in which node n3 is the source, is the following: Suppose the algorithm has constructed the partial node order n0, n1. Then, the nodes left to be ordered are nodes n2, n3, and n4. Suppose that the while-loop in the implemented algorithm considers the nodes in the order n4, n3, n2. The algorithm will start with node n4, and look for more preferable nodes. First, node n4 will be compared with node n3. As the nodes have equal Height and Movability and have no edge between them, the algorithm will stick with node n4. Then node n4 is compared with node n2. Again the Height and Movability are equal. But, this time, there is an edge between the two nodes, and the algorithm will prefer the source node n2. As there are no nodes left to compare, the algorithm will add node n2 to the node order, yielding the partial node order n0, n1, n2. In this way node n2 arrives in the node-order before node n3.
To solve this, this patch introduces the ZeroLatencyHeight (ZLH) property for nodes. It is defined as the maximum unweighted length of a path from the given node to an arbitrary node in which each edge has latency 0. So, ZLH(n0)=3, ZLH(n1)=ZLH(n3)=2, ZLH(n2)=1, and ZLH(n4)=0
In this patch, the preference for a greater ZeroLatencyHeight is added in the top-down mode of the node ordering algorithm, after the preference for a greater Height, and before the preference for a lower Movability.
Therefore, the two allowed node-orders are n0, n1, n3, n2, n4 and n0, n3, n1, n2, n4. Both of them are valid node orders.
In the same way, the bottom-up mode of the node ordering algorithm is adapted by introducing the ZeroLatencyDepth property for nodes.
The patch is tested by adding extra checks to the following existing lit-tests: test/CodeGen/Hexagon/SUnit-boundary-prob.ll test/CodeGen/Hexagon/frame-offset-overflow.ll test/CodeGen/Hexagon/vect/vect-shuffle.ll
Before this patch, the pipeliner failed to pipeline the loops in these tests due to invalid node-orders. After the patch, the pipeliner successfully pipelines all these loops.
Reviewers: bcahoon
Reviewed By: bcahoon
Subscribers: Ayal, mgrang, llvm-commits
Differential Revision: https://reviews.llvm.org/D43620
llvm-svn: 326925
show more ...
|
#
20a0e550 |
| 06-Mar-2018 |
Roorda, Jan-Willem <jan-willem.roorda@intel.com> |
[Pipeliner] Test commit: fixed spelling mistake in comments
Reviewers: bcahoon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44152
llvm-svn: 326808
|
Revision tags: llvmorg-6.0.0 |
|
#
2d79017d |
| 27-Feb-2018 |
Krzysztof Parzyszek <kparzysz@codeaurora.org> |
[Pipeliner] Drop memrefs instead of creating ones with size UINT64_MAX
Absence of memory operands is treated as "aliasing everything", so dropping them is sufficient.
Recommit r326256 with a fixed
[Pipeliner] Drop memrefs instead of creating ones with size UINT64_MAX
Absence of memory operands is treated as "aliasing everything", so dropping them is sufficient.
Recommit r326256 with a fixed testcase.
llvm-svn: 326262
show more ...
|
#
10ab103a |
| 27-Feb-2018 |
Krzysztof Parzyszek <kparzysz@codeaurora.org> |
Revert "[Pipeliner] Drop memrefs instead of creating ones with size UINT64_MAX"
This reverts r326256. One testcase needs to be updated.
llvm-svn: 326259
|
#
82da5d7f |
| 27-Feb-2018 |
Krzysztof Parzyszek <kparzysz@codeaurora.org> |
[Pipeliner] Drop memrefs instead of creating ones with size UINT64_MAX
Absence of memory operands is treated as "aliasing everything", so dropping them is sufficient.
llvm-svn: 326256
|
Revision tags: llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1 |
|
#
8f976ba0 |
| 17-Jan-2018 |
Hiroshi Inoue <inouehrs@jp.ibm.com> |
[NFC] fix trivial typos in comments
"the the" -> "the"
llvm-svn: 322636
|
#
90ecac01 |
| 04-Jan-2018 |
Bob Wilson <bob.wilson@apple.com> |
support phi ranges for machine-level IR
Add iterator ranges for machine instruction phis, similar to the IR-level phi ranges added in r303964. I updated a few places to use this. Besides general cod
support phi ranges for machine-level IR
Add iterator ranges for machine instruction phis, similar to the IR-level phi ranges added in r303964. I updated a few places to use this. Besides general code simplification, this change will allow removing a non-upstream change from Swift's copy of LLVM (in a better way than my previous attempt in http://reviews.llvm.org/D19080).
https://reviews.llvm.org/D41672
llvm-svn: 321783
show more ...
|
#
f1caa283 |
| 15-Dec-2017 |
Matthias Braun <matze@braunis.de> |
MachineFunction: Return reference from getFunction(); NFC
The Function can never be nullptr so we can return a reference.
llvm-svn: 320884
|
#
f842297d |
| 13-Dec-2017 |
Matthias Braun <matze@braunis.de> |
Rename LiveIntervalAnalysis.h to LiveIntervals.h
Headers/Implementation files should be named after the class they declare/define.
Also eliminated an `#include "llvm/CodeGen/LiveIntervalAnalysis.h"
Rename LiveIntervalAnalysis.h to LiveIntervals.h
Headers/Implementation files should be named after the class they declare/define.
Also eliminated an `#include "llvm/CodeGen/LiveIntervalAnalysis.h"` in favor of `class LiveIntarvals;`
llvm-svn: 320546
show more ...
|
Revision tags: llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2 |
|
#
b3bde2ea |
| 17-Nov-2017 |
David Blaikie <dblaikie@gmail.com> |
Fix a bunch more layering of CodeGen headers that are in Target
All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, n
Fix a bunch more layering of CodeGen headers that are in Target
All these headers already depend on CodeGen headers so moving them into CodeGen fixes the layering (since CodeGen depends on Target, not the other way around).
llvm-svn: 318490
show more ...
|
#
3f833edc |
| 08-Nov-2017 |
David Blaikie <dblaikie@gmail.com> |
Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layering
This header includes CodeGen headers, and is not, itself, included by any Target headers, so move it into CodeGen to match the
Target/TargetInstrInfo.h -> CodeGen/TargetInstrInfo.h to match layering
This header includes CodeGen headers, and is not, itself, included by any Target headers, so move it into CodeGen to match the layering of its implementation.
llvm-svn: 317647
show more ...
|
Revision tags: llvmorg-5.0.1-rc1 |
|
#
615eb470 |
| 15-Oct-2017 |
Aaron Ballman <aaron@aaronballman.com> |
Reverting r315590; it did not include changes for llvm-tblgen, which is causing link errors for several people.
Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::
Reverting r315590; it did not include changes for llvm-tblgen, which is causing link errors for several people.
Error LNK2019 unresolved external symbol "public: void __cdecl `anonymous namespace'::MatchableInfo::dump(void)const " (?dump@MatchableInfo@?A0xf4f1c304@@QEBAXXZ) referenced in function "public: void __cdecl `anonymous namespace'::AsmMatcherEmitter::run(class llvm::raw_ostream &)" (?run@AsmMatcherEmitter@?A0xf4f1c304@@QEAAXAEAVraw_ostream@llvm@@@Z) llvm-tblgen D:\llvm\2017\utils\TableGen\AsmMatcherEmitter.obj 1
llvm-svn: 315854
show more ...
|
#
3e0199f7 |
| 12-Oct-2017 |
Don Hinton <hintonda@gmail.com> |
[dump] Remove NDEBUG from test to enable dump methods [NFC]
Summary: Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP.
Remove NDEBUG and
[dump] Remove NDEBUG from test to enable dump methods [NFC]
Summary: Add LLVM_FORCE_ENABLE_DUMP cmake option, and use it along with LLVM_ENABLE_ASSERTIONS to set LLVM_ENABLE_DUMP.
Remove NDEBUG and only use LLVM_ENABLE_DUMP to enable dump methods.
Move definition of LLVM_ENABLE_DUMP from config.h to llvm-config.h so it'll be picked up by public headers.
Differential Revision: https://reviews.llvm.org/D38406
llvm-svn: 315590
show more ...
|
#
12bdcab5 |
| 11-Oct-2017 |
Krzysztof Parzyszek <kparzysz@codeaurora.org> |
[Pipeliner] Fix offset value for instrs dependent on post-inc load/stores
The software pipeliner and the packetizer try to break dependence between the post-increment instruction and the dependent m
[Pipeliner] Fix offset value for instrs dependent on post-inc load/stores
The software pipeliner and the packetizer try to break dependence between the post-increment instruction and the dependent memory instructions by changing the base register and the offset value. However, in some cases, the existing logic didn't work properly and created incorrect offset value.
Patch by Jyotsna Verma.
llvm-svn: 315468
show more ...
|
#
8f174dde |
| 11-Oct-2017 |
Krzysztof Parzyszek <kparzysz@codeaurora.org> |
[Pipeliner] Improve serialization order for post-increments
The pipeliner is generating a serial sequence that causes poor register allocation when a post-increment instruction appears prior to the
[Pipeliner] Improve serialization order for post-increments
The pipeliner is generating a serial sequence that causes poor register allocation when a post-increment instruction appears prior to the use of the post-increment register. This occurs when there is a circular set of dependences involved with a sequence of instructions in the same cycle. In this case, there is no serialization of the parallel semantics that will not cause an additional register to be allocated.
This patch fixes the problem by changing the instructions so that the post-increment instruction is used by the subsequent instruction, which enables the register allocator to make a better decision and not require another register.
Patch by Brendon Cahoon.
llvm-svn: 315466
show more ...
|
#
fdf9bf4f |
| 10-Oct-2017 |
Justin Bogner <mail@justinbogner.com> |
CodeGen: Minor cleanups to use MachineInstr::getMF. NFC
Since r315388 we have a shorter way to say this, so we'll replace MI->getParent()->getParent() with MI->getMF() in a few places.
llvm-svn: 31
CodeGen: Minor cleanups to use MachineInstr::getMF. NFC
Since r315388 we have a shorter way to say this, so we'll replace MI->getParent()->getParent() with MI->getMF() in a few places.
llvm-svn: 315390
show more ...
|
#
32a40564 |
| 11-Sep-2017 |
Eugene Zelenko <eugene.zelenko@gmail.com> |
[CodeGen] Fix some Clang-tidy modernize-use-using and Include What You Use warnings; other minor fixes (NFC).
llvm-svn: 312971
|
Revision tags: llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2 |
|
#
6b3216aa |
| 31-Jul-2017 |
Florian Hahn <florian.hahn@arm.com> |
Guard print() functions only used by dump() functions.
Summary: Since r293359, most dump() function are only defined when `!defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)` holds. print() functions on
Guard print() functions only used by dump() functions.
Summary: Since r293359, most dump() function are only defined when `!defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)` holds. print() functions only used by dump() functions are now unused in release builds, generating lots of warnings. This patch only defines some print() functions if they are used.
Reviewers: MatzeB
Reviewed By: MatzeB
Subscribers: arsenm, mzolotukhin, nhaehnle, llvm-commits
Differential Revision: https://reviews.llvm.org/D35949
llvm-svn: 309553
show more ...
|
Revision tags: llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3 |
|
#
6bda14b3 |
| 06-Jun-2017 |
Chandler Carruth <chandlerc@gmail.com> |
Sort the remaining #include lines in include/... and lib/....
I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line
Sort the remaining #include lines in include/... and lib/....
I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days.
I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch.
This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files.
Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again).
llvm-svn: 304787
show more ...
|
Revision tags: llvmorg-4.0.1-rc2 |
|
#
1527baab |
| 25-May-2017 |
Matthias Braun <matze@braunis.de> |
CodeGen: Rename DEBUG_TYPE to match passnames
Rename the DEBUG_TYPE to match the names of corresponding passes where it makes sense. Also establish the pattern of simply referencing DEBUG_TYPE inste
CodeGen: Rename DEBUG_TYPE to match passnames
Rename the DEBUG_TYPE to match the names of corresponding passes where it makes sense. Also establish the pattern of simply referencing DEBUG_TYPE instead of repeating the passname where possible.
llvm-svn: 303921
show more ...
|
Revision tags: llvmorg-4.0.1-rc1 |
|
#
6bdc7555 |
| 31-Mar-2017 |
Simon Pilgrim <llvm-dev@redking.me.uk> |
Spelling mistakes in comments. NFCI.
llvm-svn: 299197
|
#
b518054b |
| 21-Mar-2017 |
Reid Kleckner <rnk@google.com> |
Rename AttributeSet to AttributeList
Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttr
Rename AttributeSet to AttributeList
Summary: This class is a list of AttributeSetNodes corresponding the function prototype of a call or function declaration. This class used to be called ParamAttrListPtr, then AttrListPtr, then AttributeSet. It is typically accessed by parameter and return value index, so "AttributeList" seems like a more intuitive name.
Rename AttributeSetImpl to AttributeListImpl to follow suit.
It's useful to rename this class so that we can rename AttributeSetNode to AttributeSet later. AttributeSet is the set of attributes that apply to a single function, argument, or return value.
Reviewers: sanjoy, javed.absar, chandlerc, pete
Reviewed By: pete
Subscribers: pete, jholewinski, arsenm, dschuff, mehdi_amini, jfb, nhaehnle, sbc100, void, llvm-commits
Differential Revision: https://reviews.llvm.org/D31102
llvm-svn: 298393
show more ...
|
#
fbfb19b1 |
| 16-Mar-2017 |
Simon Pilgrim <llvm-dev@redking.me.uk> |
Remove redundant conditions (PR31753). NFCI.
llvm-svn: 297976
|