Allow targets to define a mapping from registers to register
classes such that each register has exactly one base class.
As registers may be in multiple register classes the base class
is determined by the container class with the lowest BaseClassOrder.
Only register classes with BaseClassOrder set are considered
when determining the base classes. By default BaseClassOrder is
unset in RegisterClass so no code is generated unless a target
explicit defines one or more base register classes.
Reviewed By: arsenm, foad
Differential Revision: https://reviews.llvm.org/D139616
This patch proposes to add a !listremove() bang operator to allow us to prune list entries by removing any entries from the first list arg that are also contained in the second list arg.
The particular use case I have in mind is for improved analysis of x86 scheduler models for which I'm hoping to start using the CodeGenProcModel 'Unsupported' features lists, which lists the ISA features a particular model DOESN'T support - with such a diverse and growing list of x86 ISAs, I don't want to have to update all these lists with every ISA change to every model - so I'm intending to keep a single central list of all x86 features, and then have the each model "remove" the features that it supports via a !listremove() - leaving just the unsupported ones.
Differential Revision: https://reviews.llvm.org/D139642
Commit a538d1f13a first added support for named sub-operands in
CodeEmitterGen. We now add a few more features to that, enabling
further target cleanups.
1. Adds support for handling an EncoderMethod in a sub-operand in
CodeEmitterGen. Previously, the specified encoder of a sub-operand was
ignored, and only the default used.
2. Adds support for sub-operands in DecoderEmitter, along with support
for tied sub-operands.
The changes to the decoder required a few minor tweaks to a few
targets, where existing brokeness was exposed. In order to keep this
patch small, I left FIXMEs which will be addressed in upcoming
patches. (Except MIPS16, since its object file emission/decoding is
totally broken).
Differential Revision: https://reviews.llvm.org/D137653
When calculating the size of concatenated subregisters, and at least
one of the subregisters involved has an unknown size (-1), then the
concatenated size should be set to -1 as well.
This bug was found for an out-of-tree target.
Looking at lib/Target the only in-tree target that has a subregister
with unknown size is X86:
X86RegisterInfo.td: def sub_mask_0 : SubRegIndex<-1>;
But it looks like sub_mask_0 don't result in any concatenated subreg
index with faulty size if looking at X86SubRegIdxRanges[].
Differential Revision: https://reviews.llvm.org/D138341
This patch adds dumping of the Offset and Size info for each
SubRegIndex printed when using
llvm-tblgen -gen-register-info -register-info-debug
It also updates the ConcatenatedSubregs.td to check those printouts,
including some new subreg definitions that show short-comings in
how the size is calculated when concatenating subregisters and at
least one has an incomplete size (-1). Today TableGen will just add
sizes together, resulting in MCRegisterInfo::getSubRegIdxSize()
returning a value that isn't -1 even if the combined subregister size
is unknown.
Differential Revision: https://reviews.llvm.org/D138340
Currently the DecoderEmitter constructor takes a bunch of string
parameters containing bits of code to interpolate.
However, there's only two ways it can be called. The one used for most
targets which doesn't handle the SoftFail DecoderStatus (not a
problem, because they don't use SoftFail). The other mode, which is
used for ARM/AArch64, does handle SoftFail, but requires an externally
defined helper function in those targets.
This is unnecessary complication; remove the parameters, and unify
onto a single version which does support SoftFail, defining the helper
itself.
This patch adds base 2 logarithm that returns integer result. I initially wanted to name it `!log2`,
but numbers are not permitted in the name. The documentation makes sure to clarify that it is
base 2 since it is not explicit in the operator name.
Differential Revision: https://reviews.llvm.org/D134068
Small QoL change to allow Predicates to be used in GICombineRule.
Currently only one combine in the AMDGPU backend makes use of it.
The implementation is pretty simple to get started but of course we can expand this later on and optimize predicate checking better if needed.
Reviewed By: dsanders
Differential Revision: https://reviews.llvm.org/D136681
Currently attributes for intrinsics are emitted using the
ArrayRef<AttrKind> based constructor for AttributeLists. This works
out fine for simple enum attributes, but doesn't really generalize
to attributes that accept values. We're already doing something
awkward for alignment attributes, and I'd like to have a cleaner
solution to this with
https://discourse.llvm.org/t/rfc-unify-memory-effect-attributes/65579 in mind.
The new generation approach is to instead directly construct
Attributes, giving us access to the full generality of that
interface. To avoid significantly increasing the size of the
generated code, we now also deduplicate the attribute sets. The
code generated per unique AttributeList looks like this:
case 204: {
AS[0] = {1, getIntrinsicArgAttributeSet(C, 5)};
AS[1] = {AttributeList::FunctionIndex, getIntrinsicFnAttributeSet(C, 10)};
NumAttrs = 2;
break;
}
and then the helper functions contain something like
case 5:
return AttributeSet::get(C, {
Attribute::get(C, Attribute::NoCapture),
});
and
case 10:
return AttributeSet::get(C, {
Attribute::get(C, Attribute::NoUnwind),
Attribute::get(C, Attribute::ArgMemOnly),
});
A casualty of this change is the intrin-properties.td test, as I
don't think that FileCheck allows matching this kind of output.
Differential Revision: https://reviews.llvm.org/D135679
Without it, the count of renderer functions is inaccurate and, in some
edge cases (like the patterns added in D134354), we can actually
go out of bounds (run out of pre-allocated renderer function spaces
in the GISel state)
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D134861
This is extremely useful for language tooling as it allows
for providing go-to-def/find-references/etc. for many
more situations than what is currently possible.
Differential Revision: https://reviews.llvm.org/D134087
Summary:
The existing undefined-bitfield-to-operand matching behavior is very
hard to understand, due to the combination of positional and named
matching. This can make it difficult to track down a bug in a target's
instruction definitions.
Over the last decade, folks have tried to work-around this in various
ways, but it's time to finally ditch the positional matching. With
https://reviews.llvm.org/D131003, there are no longer cases that
_require_ positional matching, and it's time to start removing usage
and support for it.
Therefore: add a (default-false) option, and set it to true only in
those targets that require positional matching today. Subsequent
changes will start cleaning up additional in-tree targets.
NOTE TO OUT OF TREE TARGET MAINTAINERS:
If this change breaks your build, you may restore the previous
behavior simply by adding:
let useDeprecatedPositionallyEncodedOperands = 1;
to your target's InstrInfo tablegen definition. However, this is
temporary -- the option will be removed in the future.
If your target does not set 'decodePositionallyEncodedOperands', you
may thus start migrating to named operands. However, if you _do_
currently set that option, I recommend waiting until a subsequent
change lands, which adds decoder support for named sub-operands.
Differential Revision: https://reviews.llvm.org/D134073
In `GIMatchTreeOpcodePartitioner::applyForPartition()`, the loop over
the possible leaves skip a leaf if the instruction does not care
about the instruction.
When processing the referenced operands in the next loop the same
leaves need to be skipped.
Later, when these leaves are added to all partitions, the bit vector
must be resized first before the bit representing the leaf is set.
This fixes a crash in llvm-tblgen.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D134192
CodeGenSchedModels::hasReadOfWrite tries to predicate whether the WriteDef is contained in the list of ValidWrites of someone ProcReadAdvance,
so that WriteID of WriteDef can be compressed and reusable.
It tries to iterate all ProcReadAdvance entry, but not all ProcReadAdvance defs also inherit from SchedRead.
Some ProcReadAdvances are defined by ReadAdvance.So it's not complete to enumerate all ProcReadAdvances if just iterate all SchedReads.
Differential Revision: https://reviews.llvm.org/D132205
The following changes are necessasy to get the generated tree
matcher to compile:
- In CodeExpansions::declare(), the assert() prevents connecting
two instructions. E.g. the match code
(match (MUL $t, $s1, $s2),
(SUB $d, $t, $s3)),
results in two declarations of $t, one for the def and one for
the use. Removing the assertion allows this construct.
If $t is later used, it is one of the operands, which should be
perfectly fine.
- The code emitted in GIMatchTreeVRegDefPartitioner::generatePartitionSelectorCode()
is not compilable:
- The value of NewInstrID should be emitted, not the name
- Both calls involving getOperand() end with one parenthesis too many
- Swaps generated condition for the partition code in the latter function
It also changes the rules i2p_to_p2i, fabs_fabs_fold, and fneg_fneg_fold
to use the tree matcher for a linear match. These rules are tested by:
CodeGen/AArch64/GlobalISel/combine-fabs.mir
CodeGen/AArch64/GlobalISel/combine-fneg.mir
CodeGen/AArch64/GlobalISel/combine-ptrtoint.mir
CodeGen/AMDGPU/GlobalISel/combine-add-nullptr.mir
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D133257
If a MachineInstr's operand should be Reg in compiler's output but is
currently FrameIndex, `isCompressibleInst()` will terminate at
`MachineOperandType::getReg()`.
This patch adds `.isReg()` checks to make `isCompressibleInst()` return
false for these MachineInstr, allowing `getInstSizeInBytes()` to return
a value and `EstimateFunctionSizeInBytes()` to work as intended.
See https://reviews.llvm.org/D129999#3694222 for details.
Reviewed By: luismarques
Differential Revision: https://reviews.llvm.org/D129999
This change improves ctags generation for tablegen files.
For the following example
```
class A;
class A {
int a;
}
```
Previously, tags were generated only for a forward declaration of class 'A'.
This patch allows generating tags for the forward declarations
and further definition of class 'A'.
Reviewed By: barannikov88
Original patch by: rusyaev-roman (Roman Rusyaev)
Some adjustments by: nhaehnle (Nicolai Hähnle)
Differential Revision: https://reviews.llvm.org/D129935
This patch introduce an automatic generation of the clause parser from the TableGen
information.
New information can be stored directly in the TableGen file:
- The different aliases that a clause support.
- prefix before a value.
- whether a prefix is optional or not.
Makes it easier to add new clauses and also avoid some error (`write` clause incorrect until now).
This patch is updating only the OpenACC part. A patch with a modification of the OpenMP clause parser will follow.
Reviewed By: kiranchandramohan
Differential Revision: https://reviews.llvm.org/D106968
This change introduces the HasNoUse builtin predicate in PatFrags that
checks for the absence of use of the first result operand.
GlobalISelEmitter will allow source PatFrags with this predicate to be
matched with destination instructions with empty outs. This predicate is
required for selecting the no-return variant of atomic instructions in
AMDGPU.
Differential Revision: https://reviews.llvm.org/D125212
This is used by disassemblers: `llvm-mc -disassemble -mattr=` and `llvm-objdump --mattr=`.
The main use case is for llvm-objdump to disassemble all known instructions
(D128030).
In user-facing tools, "all" is intentionally not supported in producers:
integrated assembler (`.arch_extension all`), clang -march (`-march=armv9.3a+all`).
Due to the code structure, `llvm-mc -mattr=+all` `llc -mattr=+all` are not
rejected (they are internal tool). Add `llvm/test/CodeGen/AArch64/mattr-all.ll`
to catch behavior changes.
AArch64SysReg::SysReg::haveFeatures: check `FeatureAll` to print
`AArch64SysReg::SysReg::AltName` for some system registers (e.g. `ERRIDR_EL1, RNDR`).
AArch64.td: add `AssemblerPredicateWithAll` to additionally test `FeatureAll`.
Change all `AssemblerPredicate` (except `UseNegativeImmediates`) to `AssemblerPredicateWithAll`.
utils/TableGen/{DecoderEmitter,SubtargetFeatureInfo}.cpp: support arbitrarily
nested all_of, any_of, and not.
Note: A predicate supports all_of, any_of, and not. For a target (though
currently not for AArch64) an encoding may be disassembled differently with
different target features.
Note: AArch64MCCodeEmitter::computeAvailableFeatures is not available to
the disassembler.
Reviewed By: peter.smith, lenary
Differential Revision: https://reviews.llvm.org/D128029
Control the MCOperandInfo expansion with `-instr-info-expand-mi-operand-info`.
For X86, this would make it possible to see memory operand type e.g.:
```
/* MOV8rm */
GR8, i8mem,
/* MOV8rm_NOREX */
GR8_NOREX, i8mem_NOREX,
```
The intended use is a follow-up diff D126116 (`getMemOperandSize`).
Reviewed By: skan
Differential Revision: https://reviews.llvm.org/D127932
We can cast a string to a record via !cast, but we have no mechanism
to check if it is valid and TableGen will raise an error if failed to
cast. Besides, we have no semantic null in TableGen (we have `?` but
different backends handle uninitialized value differently), so operator
like `dyn_cast<>` is hard to implement.
In this patch, we add a new operator `!exists<T>(s)` to check whether
a record with type `T` and name `s` exists. Self-references are allowed
just like `!cast`.
By doing these, we can write code like:
```
class dyn_cast_to_record<string name> {
R value = !if(!exists<R>(name), !cast<R>(name), default_value);
}
defvar v = dyn_cast_to_record<"R0">.value; // R0 or default_value.
```
Reviewed By: tra, nhaehnle
Differential Revision: https://reviews.llvm.org/D127948
Make Offsets and OpcodeOperandTypes tables human-readable by printing the
instruction name before the operand list.
In effect, this makes debugging generated `getOperandType` possible.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D127931
Make Offsets and OpcodeOperandTypes tables human-readable by printing the
instruction name before the operand list.
In effect, this makes debugging generated `getOperandType` possible.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D127931
Adds MVT::v128i2, MVT::v64i4, and implied MVT::i2, MVT::i4.
Keeps MVT::i2, MVT::i4 lowering actions as expand, which should be
removed once targets set this explicitly.
Adjusts 11 lit tests to reflect slightly different behavior during
DAG combine.
Differential Revision: https://reviews.llvm.org/D125247
Adds MVT::v128i2, MVT::v64i4, and implied MVT::i2, MVT::i4.
Keeps MVT::i2, MVT::i4 lowering actions as `expand`, which should be
removed once targets set this explicitly.
Adjusts 11 lit tests to reflect slightly different behavior during
DAG combine.
Differential Revision: https://reviews.llvm.org/D125247
Most clients only used these methods because they wanted to be able to
extend or truncate to the same bit width (which is a no-op). Now that
the standard zext, sext and trunc allow this, there is no reason to use
the OrSelf versions.
The OrSelf versions additionally have the strange behaviour of allowing
extending to a *smaller* width, or truncating to a *larger* width, which
are also treated as no-ops. A small amount of client code relied on this
(ConstantRange::castOp and MicrosoftCXXNameMangler::mangleNumber) and
needed rewriting.
Differential Revision: https://reviews.llvm.org/D125557
To support variable length instructions, I think of them as fixed length instructions with the "maximum length". For example, if there're three instructions with 2, 6 and 9 bytes, we can fit them into the algorithm by treating them all as 9 bytes.
Also, since we can't know the length of the instruction in advance, there is a function object with type `void(APInt &, uint64_t)` added in the parameter list of `decodeInstruction` and `fieldFromInstruction`. We can use this to supply the additional bits the decoder needs after we know the opcode of the instruction.
Finally, `InstrLenTable` is added to let the decoder know the length of the instructions.
See D120960 for its usage.
Reviewed By: myhsu
Differential Revision: https://reviews.llvm.org/D120958
The builtin predicate handling has a strange behavior where the code
assumes that a PatFrag is a stack of PatFrags, and each level adds at
most one predicate. I don't think this particularly makes sense,
especially without a diagnostic to ensure you aren't trying to set
multiple at once.
This wasn't followed for address spaces and alignment, which could
potentially fall through to report no builtin predicate was
added. Just switch these to follow the existing convention for now.
The new encoder directive can be used to specify custom encoder for a
single operand or slice. This is different from the EncoderMethod field
within an Operand, which affects every operands in the target.
In addition, this patch also changes the function signature of the
encoder method -- a new argument, InsertPost, is added to both the
default one (i.e. getMachineValue) and the custom one. This argument
provides the bit position where the operand will eventually be inserted.
Differential Revision: https://reviews.llvm.org/D119100
Full write up:
https://gist.github.com/mshockwave/66e98d099256deefc062633909bb7b5b
The existing CodeEmitterGen infrastructure is unable to generate encoder
function for ISAs with variable-length instructions. This patch
introduces a new infrastructure to support variable-length instruction
encoding, including a new TableGen syntax for writing instruction
encoding directives and a new TableGen backend component,
VarLenCodeEmitterGen, built on top of CodeEmitterGen.
Differential Revision: https://reviews.llvm.org/D115128
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
Not only RISCV but also other target such as CSKY, there are compressed instructions mixed with normal instructions.
To reuse the basic infra to compress/uncompress and predict instruction, we need reconstruct the RISCVCompressInstEmitter
and make it more general and suitable for other target.
Differential Revision: https://reviews.llvm.org/D113475
Add a warning to TableGen for unused template arguments in classes and
multiclasses, for example:
multiclass Foo<int x> {
def bar;
}
$ llvm-tblgen foo.td
foo.td:1:20: warning: unused template argument: Foo::x
multiclass Foo<int x> {
^
A flag '--no-warn-on-unused-template-args' is added to disable the
warning. The warning is disabled for LLVM and sub-projects if
'LLVM_ENABLE_WARNINGS=OFF'.
Reviewed By: RKSimon
Differential Revision: https://reviews.llvm.org/D109359
During rule optimization, identical SameOperandMatchers are hoisted into a common group,
however previously only one operand index was considered.
Commutable patterns can introduce SameOperandMatcher checks where the second index is commuted,
resulting in a different check that cannot be hoisted.
Reviewed By: qcolombet
Differential Revision: https://reviews.llvm.org/D111506
Tablegen currently expects targets to have at least one
pressure set for every broader register category. AMDGPU's
VGPR or AGPR, for instance, seemed to work correctly without
any pset, though we have forced one for each type to avoid
the assertion in computeRegUnitSets. However, psets can not
be entirely empty. At least one set is mandatory for every
target. This patch bypasses the assertion for the classes
when GeneratePressureSet is zero while ensuring the
RegUnitSets are not empty.
Reviewed By: arsenm, rampitec
Differential Revision: https://reviews.llvm.org/D110305
Analogous to the TSFlags for machine instructions, this
patch introduces a bit vector for register classes to have
target specific flags that become a tablegened value in
TargetRegisterClass.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D108767
My use case for this is illustrated in the test case: I want to define
the same instruction twice with different (disjoint) predicates, because
the instruction has different operands on different subtargets. It's
convenient to do this with a multiclass that also defines an alias for
the instruction.
Previously tablegen would complain if this alias was defined twice with
no predicate. One way to fix this would be to add a predicate on each
definition of the alias, matching the predicate on the instruction. But
this (a) is slightly awkward to do in the real world use case I had, and
(b) leads to an inefficient matcher that will do something like this:
if (Mnemonic == "foo_alias") {
if (Features.test(Feature_Subtarget1Bit))
Mnemonic == "foo";
else if (Features.test(Feature_Subtarget2Bit))
Mnemonic == "foo";
return;
}
It would be more efficient to skip the feature tests and return "foo"
unconditionally.
Overall it seems better to allow multiple definitions of the identical
alias with no predicate.
Differential Revision: https://reviews.llvm.org/D105033
If an instruction has several operands and a PC-relative one is not the
first of them, the generator may produce the code that does not pass the
'Address' parameter to the printout method. For example, for an Arm
instruction 'LE LR, $imm', it reuses the same code as for other
instructions where the second operand is not PC-relative:
void ARMInstPrinter::printInstruction(...) {
...
case 11:
// BF16VDOTI_VDOTD, BF16VDOTI_VDOTQ, BF16VDOTS_VDOTD, ...
printOperand(MI, 1, STI, O);
O << ", ";
printOperand(MI, 2, STI, O);
break;
...
The patch fixes that by considering 'PCRel' when comparing
'AsmWriterOperand' values.
Differential Revision: https://reviews.llvm.org/D104698
