[LiveIntervals] Ignore artificial regs when adding kill flags (#116963)

If parts of a physical register for a given liverange, as assigned by
the register allocator, can be used to store other valu

[LiveIntervals] Ignore artificial regs when adding kill flags (#116963)

If parts of a physical register for a given liverange, as assigned by
the register allocator, can be used to store other values not
represented by this liverange, then `LiveIntervals::addKillFlags`
normally avoids adding a kill flag on the use of this register
when the value's liverange ends.

However, if all the other regunits are artificial, then we can
still safely add the kill flag, since those parts of the register
can never be accessed independently.

show more ...

[llvm] use 64-bit types for result of getDwarfRegNum (NFC) (#109494)

The register encoding used by NVPTX and cuda-gdb basically use strings
encoded as numbers. They are always within 64-bits, but t

[llvm] use 64-bit types for result of getDwarfRegNum (NFC) (#109494)

The register encoding used by NVPTX and cuda-gdb basically use strings
encoded as numbers. They are always within 64-bits, but typically
outside of 32-bits, since they often need at least 5 characters.

This patch changes the signature of `MCRegisterInfo::getDwarfRegNum` and
some related data structures to use 64-bit numbers to accommodate
encodings like this.

Additionally, `MCRegisterInfo::getDwarfRegNum` is marked as virtual, so
that targets with peculiar dwarf register mapping schemes (such as
NVPTX) can override its behavior.

I originally tried to do a broader switch to 64-bit types for registers,
but it caused many problems. There are various places in code generation
where registers are not just treated as 32-bit numbers, but also treat
certain bit offsets as flags. So I limited the change as much as
possible to just the output of `getDwarfRegNum`. Keeping the types used
by `DwarfLLVMRegPair` as unsigned preserves the current behaviors. The
only way to give a 64-bit output from `getDwarfRegNum` that actually
needs more than 32-bits is to override `getDwarfRegNum` and provide an
implementation that sidesteps the use of the `DwarfLLVMRegPair` maps
defined in tablegen files.

First layer of stack supporting:
https://github.com/llvm/llvm-project/pull/109495

show more ...

[MC] Use MCRegister and remove implicit casts from MCRegister to unsigned. NFC

[MC] Make MCRegisterInfo::getLLVMRegNum return std::optional<MCRegister>. NFC (#107776)

[MC] Cache MCRegAliasIterator (#93510)

AMDGPU has a lot of registers, almost 9000. Many of those registers have
aliases. For instance, SGPR0 has a ton of aliases due to the presence of
register tu

[MC] Cache MCRegAliasIterator (#93510)

AMDGPU has a lot of registers, almost 9000. Many of those registers have
aliases. For instance, SGPR0 has a ton of aliases due to the presence of
register tuples. It's even worse if you query the aliases of a register
tuple itself. A large register tuple can have hundreds of aliases
because it may include 16 registers, and each of those registers have
their own tuples as well.

The current implementation of MCRegAliasIterator is not good at this. In
some extreme cases it can iterate, 7000 more times than
necessary, just giving duplicates over and over again and using a lot of
expensive iterators.

This patch implements a cache system for MCRegAliasIterator. It does the
expensive part only once and then saves it for us so the next iterations
on that register's aliases are just a map lookup.

Furthermore, the cached data is uniqued (and sorted). Thus, this speeds
up code by both speeding up the iterator itself, but also by minimizing
the number of loop iterations users of the iterator do.

show more ...

[Target] Move SubRegIdxRanges from MCSubtargetInfo to TargetInfo. (#86245)

I'm planning to add HwMode support to SubRegIdxRanges for RISC-V GPR
pairs. The MC layer is currently unaware of the HwMod

[Target] Move SubRegIdxRanges from MCSubtargetInfo to TargetInfo. (#86245)

I'm planning to add HwMode support to SubRegIdxRanges for RISC-V GPR
pairs. The MC layer is currently unaware of the HwMode for registers and
I'd like to keep it that way.

This information is not used by the MC layer so I think it is safe to
move it.

show more ...

[MC] Use regunits instead of MCRegUnitIterator. NFC.

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

[MC] Use subregs/superregs instead of MCSubRegIterator/MCSuperRegIterator. NFC.

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

[Coverity] avoid array overflow when use -1 as index.

[MC] llvm::Optional => std::optional

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

[llvm] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of ma

[llvm] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[MC] Define and use MCRegisterInfo::regsOverlap

Separate MCRegisterInfo::regsOverlap out from
TargetRegisterInfo::regsOverlap. This is useful in the AMDGPU AsmParser
where we only have access to MCR

[MC] Define and use MCRegisterInfo::regsOverlap

Separate MCRegisterInfo::regsOverlap out from
TargetRegisterInfo::regsOverlap. This is useful in the AMDGPU AsmParser
where we only have access to MCRegisterInfo.

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

show more ...

MCRegisterInfo: Merge getLLVMRegNum and getLLVMRegNumFromEH

Summary:
The functions different in two ways:
- getLLVMRegNum could return both "eh" and "other" dwarf register
numbers, while getLLVMRe

MCRegisterInfo: Merge getLLVMRegNum and getLLVMRegNumFromEH

Summary:
The functions different in two ways:
- getLLVMRegNum could return both "eh" and "other" dwarf register
numbers, while getLLVMRegNumFromEH only returned the "eh" number.
- getLLVMRegNum asserted if the register was not found, while the second
function returned -1.

The second distinction was pretty important, but it was very hard to
infer that from the function name. Aditionally, for the use case of
dumping dwarf expressions, we needed a function which can work with both
kinds of number, but does not assert.

This patch solves both of these issues by merging the two functions into
one, returning an Optional<unsigned> value. While the same thing could
be achieved by adding an "IsEH" argument to the (renamed)
getLLVMRegNumFromEH function, it seemed better to avoid the confusion of
two functions and put the choice of asserting into the hands of the
caller -- if he checks the Optional value, he can safely process
"untrusted" input, and if he blindly dereferences the Optional, he gets
the assertion.

I've updated all call sites to the new API, choosing between the two
options according to the function they were calling originally, except
that I've updated the usage in DWARFExpression.cpp to use the "safe"
method instead, and added a test case which would have previously
triggered an assertion failure when processing (incorrect?) dwarf
expressions.

Reviewers: dsanders, arsenm, JDevlieghere

Subscribers: wdng, aprantl, javed.absar, llvm-commits

Tags: #llvm

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

llvm-svn: 372710

show more ...

Use MCRegister in MCRegisterInfo's interfaces

Summary:
As part of this, define DenseMapInfo for MCRegister (and Register while I'm at it)

Depends on D65599

Reviewers: arsenm

Subscribers: MatzeB,

Use MCRegister in MCRegisterInfo's interfaces

Summary:
As part of this, define DenseMapInfo for MCRegister (and Register while I'm at it)

Depends on D65599

Reviewers: arsenm

Subscribers: MatzeB, qcolombet, jvesely, wdng, nhaehnle, hiraditya, llvm-commits

Tags: #llvm

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

llvm-svn: 367719

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

[MC] Improve error message when a codeview register is unknown

This is in MCRegisterInfo, we can print the actual register name easily.

llvm-svn: 340089

[MC] Handle unknown literal register numbers in .cfi_* directives

r230670 introduced a step to map EH register numbers to standard
DWARF register numbers. This failed to consider the case when a
use

[MC] Handle unknown literal register numbers in .cfi_* directives

r230670 introduced a step to map EH register numbers to standard
DWARF register numbers. This failed to consider the case when a
user .cfi_* directive uses an integer literal rather than a
register name, to specify a DWARF register number that has no
corresponding LLVM register number (e.g. a special register that
the compiler and assembler have no name for).

Fixes PR34028.

Patch by Roland McGrath

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

llvm-svn: 319586

show more ...

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

[MC] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC).

llvm-svn: 294685

Extract LaneBitmask into a separate type

Specifically avoid implicit conversions from/to integral types to
avoid potential errors when changing the underlying type. For example,
a typical initializa

Extract LaneBitmask into a separate type

Specifically avoid implicit conversions from/to integral types to
avoid potential errors when changing the underlying type. For example,
a typical initialization of a "full" mask was "LaneMask = ~0u", which
would result in a value of 0x00000000FFFFFFFF if the type was extended
to uint64_t.

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

llvm-svn: 289820

show more ...

Avoid accessing LLVM/DWARF register mappings if undefined

Summary:
If the backend does not define LLVM/DWARF register mappings, the associated
variables are undefined since the map initializer is ca

Avoid accessing LLVM/DWARF register mappings if undefined

Summary:
If the backend does not define LLVM/DWARF register mappings, the associated
variables are undefined since the map initializer is called by auto-generated
TableGen routines. This patch initializes the pointers and sizes to nullptr
and zero, respectively, and checks that they are valid before searching
for a mapping.

Reviewers: grosbach, dschuff

Subscribers: llvm-commits

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

llvm-svn: 278574

show more ...

[codeview] Bail on a DBG_VALUE register operand with no register

This apparently comes up when the register allocator decides that a
variable will become undef along a certain path.

Also improve th

[codeview] Bail on a DBG_VALUE register operand with no register

This apparently comes up when the register allocator decides that a
variable will become undef along a certain path.

Also improve the error message we emit when we can't map from LLVM
register number to CV register number.

llvm-svn: 261016

show more ...

[codeview] Describe int local variables using .cv_def_range

Summary:
Refactor common value, scope, and label tracking logic out of DwarfDebug
into a common base class called DebugHandlerBase.

Updat

[codeview] Describe int local variables using .cv_def_range

Summary:
Refactor common value, scope, and label tracking logic out of DwarfDebug
into a common base class called DebugHandlerBase.

Update an old LLVM IR test case to avoid an assertion in LexicalScopes.

Reviewers: dblaikie, majnemer

Subscribers: llvm-commits

Differential Revision: http://reviews.llvm.org/D16931

llvm-svn: 260432

show more ...

Make SubRegIndex size mandatory, following r183020.

This also makes TableGen able to compute sizes/offsets of synthesized
indices representing tuples.

llvm-svn: 183061

Add a way to define the bit range covered by a SubRegIndex.

NOTE: If this broke your out-of-tree backend, in *RegisterInfo.td, change
the instances of SubRegIndex that have a comps template arg to u

Add a way to define the bit range covered by a SubRegIndex.

NOTE: If this broke your out-of-tree backend, in *RegisterInfo.td, change
the instances of SubRegIndex that have a comps template arg to use the
ComposedSubRegIndex class instead.

In TableGen land, this adds Size and Offset attributes to SubRegIndex,
and the ComposedSubRegIndex class, for which the Size and Offset are
computed by TableGen. This also adds an accessor in MCRegisterInfo, and
Size/Offsets for the X86 and ARM subreg indices.

llvm-svn: 183020

show more ...