Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1, llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1 |
|
#
eebe841a |
| 26-Sep-2018 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
RegAlloc: Allow targets to split register allocation
AMDGPU normally spills SGPRs to VGPRs. Previously, since all register classes are handled at the same time, this was problematic. We don't know a
RegAlloc: Allow targets to split register allocation
AMDGPU normally spills SGPRs to VGPRs. Previously, since all register classes are handled at the same time, this was problematic. We don't know ahead of time how many registers will be needed to be reserved to handle the spilling. If no VGPRs were left for spilling, we would have to try to spill to memory. If the spilled SGPRs were required for exec mask manipulation, it is highly problematic because the lanes active at the point of spill are not necessarily the same as at the restore point.
Avoid this problem by fully allocating SGPRs in a separate regalloc run from VGPRs. This way we know the exact number of VGPRs needed, and can reserve them for a second run. This fixes the most serious issues, but it is still possible using inline asm to make all VGPRs unavailable. Start erroring in the case where we ever would require memory for an SGPR spill.
This is implemented by giving each regalloc pass a callback which reports if a register class should be handled or not. A few passes need some small changes to deal with leftover virtual registers.
In the AMDGPU implementation, a new pass is introduced to take the place of PrologEpilogInserter for SGPR spills emitted during the first run.
One disadvantage of this is currently StackSlotColoring is no longer used for SGPR spills. It would need to be run again, which will require more work.
Error if the standard -regalloc option is used. Introduce new separate -sgpr-regalloc and -vgpr-regalloc flags, so the two runs can be controlled individually. PBQB is not currently supported, so this also prevents using the unhandled allocator.
show more ...
|
#
82492f24 |
| 17-Feb-2021 |
Mircea Trofin <mtrofin@google.com> |
[NFC][Regalloc] Share the VirtRegAuxInfo object with LiveRangeEdit
VirtRegAuxInfo is an extensibility point, so the register allocator's decision on which implementation to use should be communicate
[NFC][Regalloc] Share the VirtRegAuxInfo object with LiveRangeEdit
VirtRegAuxInfo is an extensibility point, so the register allocator's decision on which implementation to use should be communicated to the other users - namely, LiveRangeEdit.
Differential Revision: https://reviews.llvm.org/D96898
show more ...
|
#
61efa3d9 |
| 18-Feb-2021 |
Kazu Hirata <kazu@google.com> |
[CodeGen] Use range-based for loops (NFC)
|
#
492b1d78 |
| 03-Nov-2020 |
Gaurav Jain <gjn@google.com> |
[NFC] Use [MC]Register in register allocation
Differential Revision: https://reviews.llvm.org/D90725
|
#
61e8a446 |
| 30-Oct-2020 |
Mircea Trofin <mtrofin@google.com> |
[NFC][regalloc] Use MCRegister appropriately
Differential Revision: https://reviews.llvm.org/D90506
|
#
b9c21d43 |
| 23-Oct-2020 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
RegAlloc: Clear isSSA
The MIR parser may infer SSA, so -run-pass=regallocgreedy would hit a verifier error after multiple vreg defs are added.
|
#
43d34799 |
| 09-Oct-2020 |
Mircea Trofin <mtrofin@google.com> |
[NFC][MC] Use MCRegister in LiveRangeMatrix
The change starts from LiveRangeMatrix and also checks the users of the APIs are typed accordingly.
Differential Revision: https://reviews.llvm.org/D89145
|
#
596a9f6b |
| 09-Oct-2020 |
Mircea Trofin <mtrofin@google.com> |
[NFC][Regalloc] Pass VirtRegMap by reference.
It's never null - the reason it's modeled as a pointer is because the pass can't init it in its ctor. Passing by ref simplifies the code, too, as the nu
[NFC][Regalloc] Pass VirtRegMap by reference.
It's never null - the reason it's modeled as a pointer is because the pass can't init it in its ctor. Passing by ref simplifies the code, too, as the null checks were unnecessary complexity.
Differential Revision: https://reviews.llvm.org/D89171
show more ...
|
#
b268e24d |
| 24-Sep-2020 |
Mircea Trofin <mtrofin@google.com> |
[NFC][regalloc] Separate iteration from AllocationOrder
This separates the two concerns - encapsulation of traversal order; and iteration.
Differential Revision: https://reviews.llvm.org/D88256
|
#
d6de40f8 |
| 29-Sep-2020 |
Mircea Trofin <mtrofin@google.com> |
[NFC][regalloc] Make VirtRegAuxInfo part of allocator state
All the state of VRAI is allocator-wide, so we can avoid creating it every time we need it. In addition, the normalization function is all
[NFC][regalloc] Make VirtRegAuxInfo part of allocator state
All the state of VRAI is allocator-wide, so we can avoid creating it every time we need it. In addition, the normalization function is allocator-specific. In a next change, we can simplify that design in favor of just having it as a virtual member.
Differential Revision: https://reviews.llvm.org/D88499
show more ...
|
#
6d193ba3 |
| 28-Sep-2020 |
Mircea Trofin <mtrofin@google.com> |
[NFC][regalloc] Unit test for AllocationOrder iteration.
Added unittests. In the process, separated core construction - which just needs the hits, order, and 'HardHints' values - from construction f
[NFC][regalloc] Unit test for AllocationOrder iteration.
Added unittests. In the process, separated core construction - which just needs the hits, order, and 'HardHints' values - from construction from current register allocation state, to simplify testing.
Differential Revision: https://reviews.llvm.org/D88455
show more ...
|
#
6e85c3d5 |
| 15-Sep-2020 |
Mircea Trofin <mtrofin@google.com> |
[NFC][Regalloc] accessors for 'reg' and 'weight'
Also renamed the fields to follow style guidelines.
Accessors help with readability - weight mutation, in particular, is easier to follow this way.
[NFC][Regalloc] accessors for 'reg' and 'weight'
Also renamed the fields to follow style guidelines.
Accessors help with readability - weight mutation, in particular, is easier to follow this way.
Differential Revision: https://reviews.llvm.org/D87725
show more ...
|
#
b7f6ecf0 |
| 30-Jun-2020 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
RegAlloc: Start using Register
|
#
a3982491 |
| 26-Apr-2020 |
Simon Pilgrim <llvm-dev@redking.me.uk> |
[Pass] Ensure we don't include PassSupport.h or PassAnalysisSupport.h directly
Both PassSupport.h and PassAnalysisSupport.h are only supposed to be included via Pass.h.
Differential Revision: https
[Pass] Ensure we don't include PassSupport.h or PassAnalysisSupport.h directly
Both PassSupport.h and PassAnalysisSupport.h are only supposed to be included via Pass.h.
Differential Revision: https://reviews.llvm.org/D78815
show more ...
|
#
e5205074 |
| 08-Mar-2020 |
Marcello Maggioni <hayarms@gmail.com> |
Move Spiller.h from lib/ directory path to include/CodeGen. NFC
This allows Spiller.h to be used and included outside of the lib/CodeGen directory. For example to be used in the lib/Target directory
Move Spiller.h from lib/ directory path to include/CodeGen. NFC
This allows Spiller.h to be used and included outside of the lib/CodeGen directory. For example to be used in the lib/Target directory or other places.
show more ...
|
#
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <chandlerc@gmail.com> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2 |
|
#
d34e60ca |
| 14-May-2018 |
Nicola Zaghen <nicola.zaghen@imgtec.com> |
Rename DEBUG macro to LLVM_DEBUG. The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/
Rename DEBUG macro to LLVM_DEBUG. The DEBUG() macro is very generic so it might clash with other projects. The renaming was done as follows: - git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g' - git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM - Manual change to APInt - Manually chage DOCS as regex doesn't match it.
In the transition period the DEBUG() macro is still present and aliased to the LLVM_DEBUG() one.
Differential Revision: https://reviews.llvm.org/D43624
llvm-svn: 332240
show more ...
|
Revision tags: llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1 |
|
#
ef95969e |
| 18-Dec-2017 |
Matthias Braun <matze@braunis.de> |
LiveStacks: Rename LiveStack.{h|cpp} to LiveStacks.{h|cpp}; NFC
Filenames should match the name of the class they contain.
llvm-svn: 321037
|
#
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 |
|
#
c71cced0 |
| 30-Nov-2017 |
Francis Visoiu Mistrih <francisvm@yahoo.com> |
[CodeGen] Always use `printReg` to print registers in both MIR and debug output
As part of the unification of the debug format and the MIR format, always use `printReg` to print all kinds of registe
[CodeGen] Always use `printReg` to print registers in both MIR and debug output
As part of the unification of the debug format and the MIR format, always use `printReg` to print all kinds of registers.
Updated the tests using '_' instead of '%noreg' until we decide which one we want to be the default one.
Differential Revision: https://reviews.llvm.org/D40421
llvm-svn: 319445
show more ...
|
Revision tags: 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 ...
|
Revision tags: llvmorg-5.0.1-rc1 |
|
#
6188f326 |
| 15-Sep-2017 |
Jonas Paulsson <paulsson@linux.vnet.ibm.com> |
Recommit "[RegAlloc] Make sure live-ranges reflect the state of the IR when removing them"
This was temporarily reverted, but now that the fix has been commited (r313197) it should be put b
Recommit "[RegAlloc] Make sure live-ranges reflect the state of the IR when removing them"
This was temporarily reverted, but now that the fix has been commited (r313197) it should be put back in place.
https://bugs.llvm.org/show_bug.cgi?id=34502
This reverts commit 9ef93d9dc4c51568e858cf8203cd2c5ce8dca796.
llvm-svn: 313349
show more ...
|
#
0f056352 |
| 07-Sep-2017 |
Jonas Paulsson <paulsson@linux.vnet.ibm.com> |
Revert "[RegAlloc] Make sure live-ranges reflect the state of the IR when removing them"
This temporarily reverts commit 463fa38 (r311401).
See https://bugs.llvm.org/show_bug.cgi?id=34502
llvm-svn
Revert "[RegAlloc] Make sure live-ranges reflect the state of the IR when removing them"
This temporarily reverts commit 463fa38 (r311401).
See https://bugs.llvm.org/show_bug.cgi?id=34502
llvm-svn: 312708
show more ...
|
Revision tags: llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3 |
|
#
4056e807 |
| 21-Aug-2017 |
Quentin Colombet <qcolombet@apple.com> |
[RegAlloc] Make sure live-ranges reflect the state of the IR when removing them
When removing a live-range we used to not touch them making debug prints harder to read because the IR was not matchin
[RegAlloc] Make sure live-ranges reflect the state of the IR when removing them
When removing a live-range we used to not touch them making debug prints harder to read because the IR was not matching what the live-ranges information was saying.
This only affects debug printing and allows to put stronger asserts in the code (see r308906 for instance).
llvm-svn: 311401
show more ...
|
Revision tags: llvmorg-5.0.0-rc2, 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 ...
|