History log of /llvm-project/llvm/lib/CodeGen/RegAllocBasic.cpp (Results 26 – 50 of 157)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


1234567