Cleanup include: TableGen

This also includes a few cleanup from Support.

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

Cleanup include: TableGen

This also includes a few cleanup from Support.

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

show more ...

[TableGen][SelectionDAG] Use ComplexPattern type for non-leaf nodes

When used as a non-leaf node, TableGen does not currently use the type
of a ComplexPattern for type inference, which also means it

[TableGen][SelectionDAG] Use ComplexPattern type for non-leaf nodes

When used as a non-leaf node, TableGen does not currently use the type
of a ComplexPattern for type inference, which also means it does not
check it doesn't conflict with the use. This differs from when used as a
leaf value, where the type is used for inference. This addresses that
discrepancy. The test case is not representative of most real-world uses
but is sufficient to demonstrate inference is working.

Some of these uses also make use of ValueTypeByHwMode rather than
SimpleValueType and so the existing type inference is extended to
support that alongside the new type inference.

There are also currently various cases of using ComplexPatterns with an
untyped type, but only for non-leaf nodes. For compatibility this is
permitted, and uses the old behaviour of not inferring for non-leaf
nodes, but the existing logic is still used for leaf values. This
remaining discrepancy should eventually be eliminated, either by
removing all such uses of untyped so the special case goes away (I
imagine Any, or a more specific type in certain cases, would be
perfectly sufficient), or by copying it to the leaf value case so
they're consistent with one another if this is something that does need
to keep being supported.

All non-experimental targets have been verified to produce bit-for-bit
identical TableGen output with this change applied.

Reviewed By: kparzysz

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

show more ...

[TableGen] Drop redundant const from return types (NFC)

Identified with readability-const-return-type.

[GlobalISel][TableGen] Fix ConstrainOperandRC bug

TableGen would pick the largest RC for constraining the operands, which
could potentially be an unallocatable RC. This patch removes selection
of un

[GlobalISel][TableGen] Fix ConstrainOperandRC bug

TableGen would pick the largest RC for constraining the operands, which
could potentially be an unallocatable RC. This patch removes selection
of unallocatable RCs.

Reviewed By: arsenm

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

show more ...

[TableGen] [CodeGenTarget] Cache the target's instruction namespace.

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

[TableGen][GlobalISel] Fix handling of zero_reg

When generating matching tables for GlobalISel, TableGen would output
"::zero_reg" whenever encountering the zero_reg, which in turn would
result in c

[TableGen][GlobalISel] Fix handling of zero_reg

When generating matching tables for GlobalISel, TableGen would output
"::zero_reg" whenever encountering the zero_reg, which in turn would
result in compilation error. This patch fixes that by instead outputting
NoRegister (== 0), which is the same result that TableGen produces when
generating matching tables for ISelDAG.

Reviewed By: arsenm

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

show more ...

[NFC] Fix trivial typos in comments

Reviewed By: jhenderson

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

Patch by Kazuaki Ishizaki.

Recommit "[GlobalISel] Import patterns containing INSERT_SUBREG"

I thought `llvm::sort` was stable for some reason but it's not.

Use `llvm::stable_sort` in `CodeGenTarget::getSuperRegForSubReg`.

Recommit "[GlobalISel] Import patterns containing INSERT_SUBREG"

I thought `llvm::sort` was stable for some reason but it's not.

Use `llvm::stable_sort` in `CodeGenTarget::getSuperRegForSubReg`.

Original patch: https://reviews.llvm.org/D66498

llvm-svn: 370084

show more ...

Revert "[GlobalISel] Import patterns containing INSERT_SUBREG"

When EXPENSIVE_CHECKS are enabled, GlobalISelEmitterSubreg.td doesn't get
stable output.

Reverting while I debug it.

See: https://rev

Revert "[GlobalISel] Import patterns containing INSERT_SUBREG"

When EXPENSIVE_CHECKS are enabled, GlobalISelEmitterSubreg.td doesn't get
stable output.

Reverting while I debug it.

See: https://reviews.llvm.org/D66498
llvm-svn: 370080

show more ...

[GlobalISel] Import patterns containing INSERT_SUBREG

This teaches the importer to handle INSERT_SUBREG instructions.

We were missing patterns involving INSERT_SUBREG in AArch64. It appears in
AArc

[GlobalISel] Import patterns containing INSERT_SUBREG

This teaches the importer to handle INSERT_SUBREG instructions.

We were missing patterns involving INSERT_SUBREG in AArch64. It appears in
AArch64InstrInfo.td 107 times, and 14 times in AArch64InstrFormats.td.

To meaningfully import it, the GlobalISelEmitter needs to know how to infer a
super register class for a given register class.

This patch introduces the following:

- `getSuperRegForSubReg`, a function which finds the largest register class
which supports a value type and subregister index

- `inferSuperRegisterClass`, a function which finds the appropriate super
register class for an INSERT_SUBREG'

- `inferRegClassFromPattern`, a function which allows for some trivial
lookthrough into instructions

- `getRegClassFromLeaf`, a helper function which returns the register class for
a leaf `TreePatternNode`

- Support for subregister index operands in `importExplicitUseRenderer`

It also

- Updates tests in each backend which are impacted by the change

- Adds GlobalISelEmitterSubreg.td to test that we import and skip the expected
patterns

As a result of this patch, INSERT_SUBREG patterns in X86 may use the
LOW32_ADDR_ACCESS_RBP register class instead of GR32. This is correct, since the
register class contains the same registers as GR32 (except with the addition of
RBP). So, this also teaches X86 to handle that register class. This is in line
with X86ISelLowering, which treats this as a GR class.

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

llvm-svn: 369973

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

[GlobalISel][Tablegen] Assign small opcodes to pseudos

Sort pseudo instructions first while emitting enum's for target
instructions info. That puts them close to each other and to generic
G_* opcode

[GlobalISel][Tablegen] Assign small opcodes to pseudos

Sort pseudo instructions first while emitting enum's for target
instructions info. That puts them close to each other and to generic
G_* opcodes for GlobalISel. This makes it easier to build small jump
tables over opcodes that could be directly embedded into MatchTable's
Tablegen'erated for GlobalISel's InstructionSelect.

Reviewed By: bogner

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

llvm-svn: 333135

show more ...

[Tablegen] Tidying up InstRegexOp a little, NFC

Differential Review: https://reviews.llvm.org/D47240

llvm-svn: 333121

[MachineOperand][Target] MachineOperand::isRenamable semantics changes

Summary:
Add a target option AllowRegisterRenaming that is used to opt in to
post-register-allocation renaming of registers. T

[MachineOperand][Target] MachineOperand::isRenamable semantics changes

Summary:
Add a target option AllowRegisterRenaming that is used to opt in to
post-register-allocation renaming of registers. This is set to 0 by
default, which causes the hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq
fields of all opcodes to be set to 1, causing
MachineOperand::isRenamable to always return false.

Set the AllowRegisterRenaming flag to 1 for all in-tree targets that
have lit tests that were effected by enabling COPY forwarding in
MachineCopyPropagation (AArch64, AMDGPU, ARM, Hexagon, Mips, PowerPC,
RISCV, Sparc, SystemZ and X86).

Add some more comments describing the semantics of the
MachineOperand::isRenamable function and how it is set and maintained.

Change isRenamable to check the operand's opcode
hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq bit directly instead of
relying on it being consistently reflected in the IsRenamable bit
setting.

Clear the IsRenamable bit when changing an operand's register value.

Remove target code that was clearing the IsRenamable bit when changing
registers/opcodes now that this is done conservatively by default.

Change setting of hasExtraSrcRegAllocReq in AMDGPU target to be done in
one place covering all opcodes that have constant pipe read limit
restrictions.

Reviewers: qcolombet, MatzeB

Subscribers: aemerson, arsenm, jyknight, mcrosier, sdardis, nhaehnle, javed.absar, tpr, arichardson, kristof.beyls, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, sabuasal, niosHD, escha, nemanjai, llvm-commits

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

llvm-svn: 325931

show more ...

[TableGen] Add a way of getting the number of generic opcodes without including modular CodeGen headers.

This is a bit of a hack, but removes a cycle that broke modular builds
of LLVM. Of course the

[TableGen] Add a way of getting the number of generic opcodes without including modular CodeGen headers.

This is a bit of a hack, but removes a cycle that broke modular builds
of LLVM. Of course the cycle is still there in form of a dependency
on the .def file.

llvm-svn: 323383

show more ...

TableGen: Allow setting SDNodeProperties on intrinsics

Allows preserving MachineMemOperands on intrinsics
through selection. For reasons I don't understand, this
is a static property of the pattern

TableGen: Allow setting SDNodeProperties on intrinsics

Allows preserving MachineMemOperands on intrinsics
through selection. For reasons I don't understand, this
is a static property of the pattern and the selector
deliberately goes out of its way to drop if not present.

Intrinsics already inherit from SDPatternOperator allowing
them to be used directly in instruction patterns. SDPatternOperator
has a list of SDNodeProperty, but you currently can't set them on
the intrinsic. Without SDNPMemOperand, when the node is selected
any memory operands are always dropped. Allowing setting this
on the intrinsics avoids needing to introduce another equivalent
target node just to have SDNPMemOperand set.

llvm-svn: 321212

show more ...

TableGen support for parameterized register class information

This replaces TableGen's type inference to operate on parameterized
types instead of MVTs, and as a consequence, some interfaces have
ch

TableGen support for parameterized register class information

This replaces TableGen's type inference to operate on parameterized
types instead of MVTs, and as a consequence, some interfaces have
changed:
- Uses of MVTs are replaced by ValueTypeByHwMode.
- EEVT::TypeSet is replaced by TypeSetByHwMode.

This affects the way that types and type sets are printed, and the
tests relying on that have been updated.

There are certain users of the inferred types outside of TableGen
itself, namely FastISel and GlobalISel. For those users, the way
that the types are accessed have changed. For typical scenarios,
these replacements can be used:
- TreePatternNode::getType(ResNo) -> getSimpleType(ResNo)
- TreePatternNode::hasTypeSet(ResNo) -> hasConcreteType(ResNo)
- TypeSet::isConcrete -> TypeSetByHwMode::isValueTypeByHwMode(false)

For more information, please refer to the review page.

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

llvm-svn: 313271

show more ...

[TableGen] Use StringRef instead of std::string for CodeGenInstruction namespace. NFC

llvm-svn: 307362

TableGen: Use StringRef instead of const std::string& in return vals.

This will allow to switch to a different string storage in an upcoming
commit.

llvm-svn: 288612

Re-apply r286384, "X86: Introduce the "relocImm" ComplexPattern, which represents a relocatable immediate.", with a fix for 32-bit x86.

Teach X86InstrInfo::analyzeCompare() not to crash on CMP and S

Re-apply r286384, "X86: Introduce the "relocImm" ComplexPattern, which represents a relocatable immediate.", with a fix for 32-bit x86.

Teach X86InstrInfo::analyzeCompare() not to crash on CMP and SUB instructions
that take a global address operand.

llvm-svn: 286420

show more ...

Revert r286384, "X86: Introduce the "relocImm" ComplexPattern, which represents a relocatable immediate."

Suspected to be the cause of a sanitizer-windows bot failure:
Assertion failed: isImm() && "

Revert r286384, "X86: Introduce the "relocImm" ComplexPattern, which represents a relocatable immediate."

Suspected to be the cause of a sanitizer-windows bot failure:
Assertion failed: isImm() && "Wrong MachineOperand accessor", file C:\b\slave\sanitizer-windows\llvm\include\llvm/CodeGen/MachineOperand.h, line 420

llvm-svn: 286385

show more ...

X86: Introduce the "relocImm" ComplexPattern, which represents a relocatable immediate.

A relocatable immediate is either an immediate operand or an operand that
can be relocated by the linker to an

X86: Introduce the "relocImm" ComplexPattern, which represents a relocatable immediate.

A relocatable immediate is either an immediate operand or an operand that
can be relocated by the linker to an immediate, such as a regular symbol
in non-PIC code.

Start using relocImm for 32-bit and 64-bit MOV instructions, and for operands
of type "imm32_su". Remove a number of now-redundant patterns.

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

llvm-svn: 286384

show more ...

Use the range variant of find instead of unpacking begin/end

If the result of the find is only used to compare against end(), just
use is_contained instead.

No functionality change is intended.

ll

Use the range variant of find instead of unpacking begin/end

If the result of the find is only used to compare against end(), just
use is_contained instead.

No functionality change is intended.

llvm-svn: 278433

show more ...

TableGen: Use StringRef instead of std::string

llvm-svn: 270741

[TableGen] Replace instructions() with getInstructionsByEnumValue(). No need to make an iterator_range when we already have a function that returns an ArrayRef. NFC

llvm-svn: 258019