This patch adds "#include <set>" to several files that are relying on
transitive includes of <set>. It in turn unblocks the removal of
unnecessary includes of llvm/ADT/SmallSet.h in several other files.
Also disables generation of MutateOpcode. It's almost never used in
combiners anyway.
If we really want to use it, it needs to be investigated & properly
fixed (see TODO)
Fixes#70780
The inference is trivial and leverages the MCOI OperandTypes encoded in
CodeGenInstructions to infer types across patterns in a CombineRule.
It's thus very limited and only supports CodeGenInstructions (but that's the
main use case so it's fine).
We only try to infer untyped operands in apply patterns when they're
temp reg defs, or immediates. Inference always outputs a `GITypeOf<$x>` where
$x is a named operand from a match pattern.
This allows us to drop the `GITypeOf` in most cases without any errors.
This patch reference ac1ffd3caca12c254e0b8c847aa8ce8e51b6cfbf to suppot
a soft coding way to identify whether a cpu has a feature
`unaligned-scalar-mem` by `RISCVProcessors.td`.
This patch does not provide test case since there is no risc-v cpu
support `unaligned-scalar-mem` in llvm upstream now.
When this was ported to clang-tblen for https://reviews.llvm.org/D123682,
some of the refactoring for the clang copy was backported to llvm,
but used .front instead of .back as clang does.
This means that if you have values "a, b, c" you get
"must be 'a', ' b' or 'a'." instead of "must be 'a', ' b' or 'c'.".
RegBanks are constructed as global objects. Making the constructor
constexpr helps the compiler construct it without a global
constructor.
clang's optimizer seems to figure this out on its own, but at
least gcc 8 does not.
* Introduce field `PositionOrder` for class `Register` and
`RegisterTuples`
* If register A's `PositionOrder` < register B's `PositionOrder`, then A
is placed before B in the enum in X86GenRegisterInfo.inc
* The new order of registers in the enum for X86 will be
1. Registers before AVX512,
2. AVX512 registers (X/YMM16-31, ZMM0-31, K registers)
3. AMX registers (TMM)
4. APX registers (R16-R31)
* Add a new target hook `getNumSupportedRegs()` to return the number of
registers for the function (may overestimate).
* Replace `getNumRegs()` with `getNumSupportedRegs()` in LiveVariables
to eliminate iterations on unsupported registers
This patch can reduce 0.3% instruction count regression for sqlite3
during compile-stage (O3) by not iterating on APX registers
for #67702
The Scratch buffer passed to getBinaryCodeForInst needs to be able to
hold any value returned by getMachineOpValue or other custom encoders.
It's better to let the caller of getBinaryCodeForInst set the size of
Scratch as it's impossible for VarLenCodeEmitterGen to know what the
smallest needed size is.
VarLenCodeEmitterGen now calculates its smallest needed Scratch bit
width based on the slice operations and zero extends Scratch if it's too
small. This only guarantees that Scratch has enough bits for the
generated code not for getMachineOpValue or custom encoders.
The smallest internal APInt representation uses one uint64_t word so
there is no point in using a smaller size.
Though I doubt that many people will land here directly, I thought it
odd that we didn't have one we can at least reference in response to questions.
The intro I've copied from the programmer's reference and added a simple
example. Then some links to resources and tools, which is the main
reason to have this page.
VarLenCodeEmitterGen produced code that did not compile if using
alternative encoding in different HwModes. It's not possbile to assign
unsigned **Index = Index_<mode>[][2] = { ... };
As a fix, Index and InstBits where removed in favor of mode specific
getInstBits_<mode> functions since this is the only place the arrays are
accessed.
Handling of HwModes is now concentrated to the VarLenCodeEmitterGen::run
method reducing the overall amount of code and enabling other types of
alternative encodings not related to HwModes.
Added a test for VarLenCodeEmitterGen HwModes.
Make sure that HwModes are supported in the same way they are supported
for the standard CodeEmitter. It should be possible to define
instructions with universal encoding across modes, distinct encodings
for each mode or only define encodings for some modes.
Fixed indentation in generated code.
Use of llvm::Optional was migrated to std::optional. This included a
change in the constructor of ArrayRef.
However, there are still 2 places in the SubtargetEmitter which uses
llvm::None, causing a compile error when emitted.
Relax the parser to accept scalar integer expression in addition to
scalar logical expression. The parser now accepts scalar expression and
the semantic checks its type.
Use `MachineIRBuilder::buildConstant` to emit typed immediates in
'apply' MIR patterns.
This adds flexibility, e.g. it allows us to seamlessly handle vector
cases, where a `G_BUILD_VECTOR` is needed to create a splat.
The MatchTableExecutor did not use the MachineIRBuilder but instead
created instructions ad-hoc.
Making it use a Builder has the benefit that any observer added by a
combine is now notified when instructions are created by MIR patterns.
Another benefit is that it allows me to improve how constants are
created in apply MIR patterns.
`MachineIRBuilder::buildConstant` automatically handles splats for us,
this means that we may change `addCImm` to use that and handle vector
cases automatically.
When `PredicateUsesOperands` is set to true, GlobalISelEmitter preserves
the original index of predicate operands and uses that information on
each predicate usage. However, previously it only looked up the original
index for "actual" operands (i.e. operands of a predicate usage) that
are leaf nodes, which is an incorrect assumption.
This patch fix it by generalizing the acceptable kinds of actual
operands for predicate as well as checking the existance of bound
predicate operands.
…the size of a pointer by HwMode.
This adds an equivalent of PtrValueType that can use a
ValueTypeByHwMode.
This allows the size of a pointer to vary based on HwMode. This is
needed for RISC-V to support XLen sized pointers.
X86 don't want to unfold RMW instrs to 1 load + 1 op + 1 store, because
RMW could save code size and benefit RA when reg pressure is high.
And from all the call position analysis, we could find we didn't unfold
RMW in current code.
This is mostly AMDGPU-specific. When the expensive checks are enabled,
generating of AMDGPUGenRegisterInfo.inc currently takes about 20 minutes
on my machine for release+asserts builds, which effectively prevents
such testing from regular use. This patch fixes this by reducing the
time to about 2 minutes.
Generation times for AMDGPUGenRegisterInfo.inc without expensive checks
and other *GenRegisterInfo.inc files with and without the expensive
checks remain approximately the same.
The patch doesn't cause any changes in the contents of the generated
files.
The root cause of the current poor performance is that where glibcxx is
used, enabling the expensive checks defines _GLIBCXX_DEBUG, which
enables various consistency checks in the library. One such check is in
std::binary_search() to make sure the range is ordered. As
CodeGenRegisterClass::contains() relies on std::binary_search() and it
is called very a large number of times from within
CodeGenRegBank::inferMatchingSuperRegClass(), the libcxx checks heavily
affect the runtimes.
We used to return `int` in `getAsInt`, while `IntInit::getValue`
returns `int64_t` and `utohexstr` needs `uint64_t`. The casting
causes the wrong hex value when printing bits value.
Fixing an issue found in a UBsan build. When defining a variable-length
encoding with no operands or slices, the HasDynamicSegment member was
read without being initialised.
This commit:
TableGen: Try to fix expensive checks failures
d2a9b87fee84766b28bd39b46c913da00e1450f4
fixed one of the sort() calls, but there's another.
Caught on expensive-checks buildbots that started to fail sporadically
after submitting
[AMDGPU] Add True16 register classes.
469b3bfad20550968ac428738eb1f8bb8ce3e96d
The call to `initOpcodeValuesMap` was missing, causing the MatchTable to
(unintentionally) not emit a `SwitchMatcher`. Also adds other code
imported from `GlobalISelEmitter.cpp` to ensure rules are sorted by
precedence as well.
Overall this improves GlobalISel compile-time performance by a
noticeable amount. See #66751
A field `FilterClassField` is added to `GenericTable` class, which
is an optional bit field of `FilterClass`. If specified, only those
records with this field being true will have corresponding entries
in the table.
We have already customized folding for VINSERTPS by 7e6606f4f1, which do
the folding when alignment >= 4 bytes.
We cannot arbitrarily fold it like others because we need to calculate
the source offset.
Adds a new feature to MIR patterns: builtin instructions.
They offer some additional capabilities that currently cannot be expressed without falling back to C++ code.
There are two builtins added with this patch, but more can be added later as new needs arise:
- GIReplaceReg
- GIEraseRoot
Depends on D158714, D158713
Reviewed By: arsenm, aemerson
Differential Revision: https://reviews.llvm.org/D158975
Now that the old backend is gone, clean-up a few things that no longer make sense and tidy up the file a bit.
Depends on D158710
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D158714
Remove CodeGen leftovers from the old combiner backend and adapt the API to fit the new backend better.
It's now quite a bit closer to how InstructionSelector works.
- `CombinerInfo` is now a simple "options" struct.
- `Combiner` is now the base class of all TableGen'd combiner implementation.
- Many fields have been moved from derived classes into that class.
- It has been refactored to create & own the Observer and Builder.
- `tryCombineAll` TableGen'd method can now be renamed, which allows targets to implement the actual `tryCombineAll` call manually and do whatever they want to do before/after it.
Note: `CombinerHelper` needs to be mutable because none of its methods are const. This can be revisited later.
Depends on D158710
Reviewed By: aemerson, dsanders
Differential Revision: https://reviews.llvm.org/D158713
Irritatingly, atomic_store had operands in the opposite order from
regular store. This made it difficult to share patterns between
regular and atomic stores.
There was a previous incomplete attempt to move atomic_store into the
regular StoreSDNode which would be better.
I think it was a mistake for all atomicrmw to swap the operand order,
so maybe it's better to take this one step further.
https://reviews.llvm.org/D123143
The MatchTable-based GlobalISel Combiner backend is the new default. There are no in-tree users left of the old backend.
- Removed implementation of old MatchDAG-based Combiner, including tests, the backend itself and all supporting code.
- Renamed MatchTable backend to `GlobalISelCombinerEmitter.cpp` + removed "-matchtable" from its CL option.
- no need to have a verbose name as it's the only backend left now.
Reviewed By: aemerson
Differential Revision: https://reviews.llvm.org/D158710
This did not satisfy equivalence of transitivity. There was an attempt
to fix it in https://reviews.llvm.org/D58687 but it was not fully
correct. Masks might not be equivalent but be equal according to LessThan lambda
Reviewed By: aeubanks, MaskRay
Differential Revision: https://reviews.llvm.org/D157955
D150312 added a TODO:
TODO: consider renaming the field `StartAtCycle` and `Cycles` to
`AcquireAtCycle` and `ReleaseAtCycle` respectively, to stress the
fact that resource allocation is now represented as an interval,
relatively to the issue cycle of the instruction.
This patch implements that TODO. This naming clarifies how to use these
fields in the scheduler. In addition it was confusing that `StartAtCycle` was
singular but `Cycles` was plural. This renaming fixes this inconsistency.
This commit as previously reverted since it missed renaming that came
down after rebasing. This version of the commit fixes those problems.
Differential Revision: https://reviews.llvm.org/D158568
D150312 added a TODO:
TODO: consider renaming the field `StartAtCycle` and `Cycles` to
`AcquireAtCycle` and `ReleaseAtCycle` respectively, to stress the
fact that resource allocation is now represented as an interval,
relatively to the issue cycle of the instruction.
This patch implements that TODO. This naming clarifies how to use these
fields in the scheduler. In addition it was confusing that `StartAtCycle` was
singular but `Cycles` was plural. This renaming fixes this inconsistency.
This commit as previously reverted since it missed renaming that came
down after rebasing. This version of the commit fixes those problems.
Differential Revision: https://reviews.llvm.org/D158568
D150312 added a TODO:
TODO: consider renaming the field `StartAtCycle` and `Cycles` to
`AcquireAtCycle` and `ReleaseAtCycle` respectively, to stress the
fact that resource allocation is now represented as an interval,
relatively to the issue cycle of the instruction.
This patch implements that TODO. This naming clarifies how to use these
fields in the scheduler. In addition it was confusing that `StartAtCycle` was
singular but `Cycles` was plural. This renaming fixes this inconsistency.
Differential Revision: https://reviews.llvm.org/D158568
I had to tighten the restrictions on PatFrags a bit to make it consistent: instructions that
define the root of a PF can only have one def.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D157700
