[CodeGen] Remove some implict conversions of MCRegister to unsigned by using(). NFC

Many of these are indexing BitVectors or something where we can't
using MCRegister and need the register number.

[CodeGen] Use regunits instead of MCRegUnitIterator in RegisterClassInfo. NFC.

[CodeGen] Simplify RegisterClassInfo BitVector comparisons. NFC.

Revert "[CodeGen] Don't include aliases in RegisterClassInfo::IgnoreCSRForAllocOrder (#80015)"

This reverts commit f8525030004f907cd108e7c18df255a6d3b23124.

It was supposed to speed things up but l

Revert "[CodeGen] Don't include aliases in RegisterClassInfo::IgnoreCSRForAllocOrder (#80015)"

This reverts commit f8525030004f907cd108e7c18df255a6d3b23124.

It was supposed to speed things up but llvm-compile-time-tracker.com
showed a slight slow down.

show more ...

[CodeGen] Don't include aliases in RegisterClassInfo::IgnoreCSRForAllocOrder (#80015)

Previously we called ignoreCSRForAllocationOrder on every alias of every
CSR which was expensive on targets lik

[CodeGen] Don't include aliases in RegisterClassInfo::IgnoreCSRForAllocOrder (#80015)

Previously we called ignoreCSRForAllocationOrder on every alias of every
CSR which was expensive on targets like AMDGPU which define a very large
number of overlapping register tuples.

On such targets it is simpler and faster to call
ignoreCSRForAllocationOrder once for every physical register.

Differential Revision: https://reviews.llvm.org/D146735

show more ...

[CodeGen] Use RegUnits in RegisterClassInfo::getLastCalleeSavedAlias (#79996)

Change the implementation of getLastCalleeSavedAlias to use RegUnits
instead of register aliases. This is much faster o

[CodeGen] Use RegUnits in RegisterClassInfo::getLastCalleeSavedAlias (#79996)

Change the implementation of getLastCalleeSavedAlias to use RegUnits
instead of register aliases. This is much faster on targets like AMDGPU
which define a very large number of overlapping register tuples.

No functional change intended. If PhysReg overlaps multiple CSRs then
getLastCalleeSavedAlias(PhysReg) could conceivably return a different
arbitrary one, but currently it is only used for some debug printing
anyway.

Differential Revision: https://reviews.llvm.org/D146734

show more ...

[CodeGen] Use range-based for loops (NFC)

Fix CSR update check

D132080 introduced a bug leading to `RegisterClassInfo` caches not
getting invalidated when there was exactly one more CSR register added.

Differential Revision: https://review

Fix CSR update check

D132080 introduced a bug leading to `RegisterClassInfo` caches not
getting invalidated when there was exactly one more CSR register added.

Differential Revision: https://reviews.llvm.org/D132606

show more ...

RegisterClassInfo: Fix CSR cache invalidation

`RegisterClassInfo` caches information like allocation orders and reuses
it for multiple machine functions where possible. However the `MCPhysReg
*Calle

RegisterClassInfo: Fix CSR cache invalidation

`RegisterClassInfo` caches information like allocation orders and reuses
it for multiple machine functions where possible. However the `MCPhysReg
*CalleeSavedRegs` field used to test whether the set of callee saved
registers changed did not work: After D28566
`MachineRegisterInfo::getCalleeSavedRegs()` can return dynamically
computed CSR sets that are only valid while the `MachineRegisterInfo`
object of the current function exists.

This changes the code to make a copy of the CSR list instead of keeping
a possibly invalid pointer around.

Differential Revision: https://reviews.llvm.org/D132080

show more ...

[RegisterClassInfo] Invalidate cached information if ignoreCSRForAllocationOrder changes

Even if CSR list is same between functions, we could have had a different
allocation order if ignoreCSRForAll

[RegisterClassInfo] Invalidate cached information if ignoreCSRForAllocationOrder changes

Even if CSR list is same between functions, we could have had a different
allocation order if ignoreCSRForAllocationOrder is evaluated differently.
Hence invalidate cached register class information if
ignoreCSRForAllocationOrder changes.

Patch by Srividya Karumuri <srividya_karumuri@apple.com>

Differential Revision: https://reviews.llvm.org/D126565

show more ...

Cleanup codegen includes

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after: 1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-in

Cleanup codegen includes

This is a (fixed) recommit of https://reviews.llvm.org/D121169

after: 1061034926
before: 1063332844

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121681

show more ...

Revert "Cleanup codegen includes"

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https:/

Revert "Cleanup codegen includes"

This reverts commit 7f230feeeac8a67b335f52bd2e900a05c6098f20.
Breaks CodeGenCUDA/link-device-bitcode.cu in check-clang,
and many LLVM tests, see comments on https://reviews.llvm.org/D121169

show more ...

Cleanup codegen includes

after: 1061034926
before: 1063332844

Differential Revision: https://reviews.llvm.org/D121169

[CodeGen] Use range-based for loops (NFC)

Support a list of CostPerUse values

This patch allows targets to define multiple cost
values for each register so that the cost model
can be more flexible and better used during the
register allocat

Support a list of CostPerUse values

This patch allows targets to define multiple cost
values for each register so that the cost model
can be more flexible and better used during the
register allocation as per the target requirements.

For AMDGPU the VGPR allocation will be more efficient
if the register cost can be associated dynamically
based on the calling convention.

Reviewed By: qcolombet

Differential Revision: https://reviews.llvm.org/D86836

show more ...

[RegisterClassInfo] Return non-zero for RC without allocatable reg

In some case, the RC may have 0 allocatable reg.
eg: VRSAVERC in PowerPC, which has only 1 reg, but it is also reserved.

The curre

[RegisterClassInfo] Return non-zero for RC without allocatable reg

In some case, the RC may have 0 allocatable reg.
eg: VRSAVERC in PowerPC, which has only 1 reg, but it is also reserved.

The curreent implementation will keep calling the computePSetLimit because
getRegPressureSetLimit assume computePSetLimit will return a non-zero value.

The fix simply early return the value from TableGen for such special case.

Reviewed By: RKSimon

Differential Revision: https://reviews.llvm.org/D92907

show more ...

RegisterClassInfo::computePSetLimit - assert that we actually find a register.

Fixes "pointer is null" clang static analyzer warning.

[RegisterClassInfo] Use SmallVector::assign instead of resize to make sure we erase previous contents from all entries of the vector.

resize only writes to elements that get added. Any elements that

[RegisterClassInfo] Use SmallVector::assign instead of resize to make sure we erase previous contents from all entries of the vector.

resize only writes to elements that get added. Any elements that
already existed maintain their previous value. In this case we're
trying to erase cached information so we should use assign which
will write to every element.

Found while trying to add new tests to an existing X86 test and
noticed register allocation changing in other functions.

show more ...

[ARM] Thumb2: favor R4-R7 over R12/LR in allocation order when opt for minsize

For Thumb2, we prefer low regs (costPerUse = 0) to allow narrow
encoding. However, current allocation order is like:

[ARM] Thumb2: favor R4-R7 over R12/LR in allocation order when opt for minsize

For Thumb2, we prefer low regs (costPerUse = 0) to allow narrow
encoding. However, current allocation order is like:
R0-R3, R12, LR, R4-R11

As a result, a lot of instructs that use R12/LR will be wide instrs.

This patch changes the allocation order to:
R0-R7, R12, LR, R8-R11
for thumb2 and -Osize.

In most cases, there is no extra push/pop instrs as they will be folded
into existing ones. There might be slight performance impact due to more
stack usage, so we only enable it when opt for min size.

https://reviews.llvm.org/D30324

llvm-svn: 365014

show more ...

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

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

[RegisterClassInfo] Invalidate the register pressure set limit cache when reserved regs or callee saved regs change

Previously we only invalidated the pressure set limit cached when the TargetRegist

[RegisterClassInfo] Invalidate the register pressure set limit cache when reserved regs or callee saved regs change

Previously we only invalidated the pressure set limit cached when the TargetRegisterInfo pointer changes. But as reserved regs and callee saved regs are used as part of calculating the limits we should invalidate when those change too.

I encountered this when reverting a patch from the 6.0 branch. One of the x86 test files had a function that used rbp as a frame pointer, making it reserved. It was followed by another function which didn't use rbp but had the same TRI so the pressure set limit cache was not invalidated. If i removed the function that used rbp as a frame pointer from the file, the remaining function then got a different register pressure limit for the GR16 pressure set. This caused the machine scheduler to change the scheduling for the function. This was an unexpected change from just deleting a function.

I don't have a test case for trunk because the particular x86 test case is different enough from the 6.0 branch to not be affected now.

Differential Revision: https://reviews.llvm.org/D43274

llvm-svn: 325153

show more ...

[CodeGen] Rename functions PrintReg* to printReg*

LLVM Coding Standards:
Function names should be verb phrases (as they represent actions), and
command-like function should be imperative. The na

[CodeGen] Rename functions PrintReg* to printReg*

LLVM Coding Standards:
Function names should be verb phrases (as they represent actions), and
command-like function should be imperative. The name should be camel
case, and start with a lower case letter (e.g. openFile() or isFoo()).

Differential Revision: https://reviews.llvm.org/D40416

llvm-svn: 319168

show more ...

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

Move TargetFrameLowering.h to CodeGen where it's implemented

This header already includes a CodeGen header and is implemented in
lib/CodeGen, so move the header there to match.

This fixes a link er

Move TargetFrameLowering.h to CodeGen where it's implemented

This header already includes a CodeGen header and is implemented in
lib/CodeGen, so move the header there to match.

This fixes a link error with modular codegeneration builds - where a
header and its implementation are circularly dependent and so need to be
in the same library, not split between two like this.

llvm-svn: 317379

show more ...