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
Similar to SelectionDAG, this patch treats HwMode as an additional
predicate that needs to be satisfied for GIM_CheckFeatures.
The existing predicate passes around Record * that point to predicate
records. While HwMode expansion creates a string that needs to be
checked.
Each HwMode predicate string is uniqued by a new map that assigns
it an index. Each Rule stores the index, or -1 if HwMode doesn't
apply.
The HwMode indices each create a new Predicate feature bit and the
check string from the HwMode is used to set the feature bit.
GIM_CheckFeatures is emitted when the rule has Predicates or the HwModeIdx
is not -1.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D158660
PredicateBitset currently uses std::bitset, but std::bitset doesn't
have a constexpr constructor or any constexpr methods until C++23.
Each target that supports GlobalIsel has as an array of PredicateBitset
objects that currently use a global constructor.
SubtargetFeature used by the MC layer for feature bits, has its own
implementation of std::bitset that has constexpr constructor and methods
that provides all the capabilities that PredicateBitset needs.
This patch copies the implementation from SubtargetFeature, makes
it a template class, and puts it in ADT. I'll migrate SubtargetFeature
in a separate patch. Adapting all existing users to it being a template
was distracting from the goal of this patch.
This reduces the binary size of llc built with gcc 8.5.0 on my local
build by ~15k.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D158576
This reverts commit 4e3b89483a6922d3f48670bb1c50a37f342918c6, with
fixes for places I'd missed updating in lld and lldb. I've also
renamed OptionVisibility::Default to "DefaultVis" to avoid ambiguity
since the undecorated name has to be available anywhere Options.inc is
included.
Original message follows:
This splits OptTable's "Flags" field into "Flags" and "Visibility",
updates the places where we instantiate Option tables, and adds
variants of the OptTable APIs that use Visibility mask instead of
Include/Exclude flags.
We need to do this to clean up a bunch of complexity in the clang
driver's option handling - there's a whole slew of flags like
CoreOption, NoDriverOption, and FlangOnlyOption there today to try to
handle all of the permutations of flags that the various drivers need,
but it really doesn't scale well, as can be seen by things like the
somewhat recently introduced CLDXCOption.
Instead, we'll provide an additive model for visibility that's
separate from the other flags. For things like "HelpHidden", which is
used as a "subtractive" modifier for option visibility, we leave that
in "Flags" and handle it as a special case.
Note that we don't actually update the users of the Include/Exclude
APIs here or change the flags that exist in clang at all - that will
come in a follow up that refactors clang's Options.td to use the
increased flexibility this change allows.
Differential Revision: https://reviews.llvm.org/D157149
This splits OptTable's "Flags" field into "Flags" and "Visibility",
updates the places where we instantiate Option tables, and adds
variants of the OptTable APIs that use Visibility mask instead of
Include/Exclude flags.
We need to do this to clean up a bunch of complexity in the clang
driver's option handling - there's a whole slew of flags like
CoreOption, NoDriverOption, and FlangOnlyOption there today to try to
handle all of the permutations of flags that the various drivers need,
but it really doesn't scale well, as can be seen by things like the
somewhat recently introduced CLDXCOption.
Instead, we'll provide an additive model for visibility that's
separate from the other flags. For things like "HelpHidden", which is
used as a "subtractive" modifier for option visibility, we leave that
in "Flags" and handle it as a special case.
Note that we don't actually update the users of the Include/Exclude
APIs here or change the flags that exist in clang at all - that will
come in a follow up that refactors clang's Options.td to use the
increased flexibility this change allows.
Differential Revision: https://reviews.llvm.org/D157149
Without the fix gcc complains with:
../utils/TableGen/GlobalISelCombinerMatchTableEmitter.cpp:251:60: warning: suggest parentheses around '&&' within '||' [-Wparentheses]
BuildMI automatically adds the implicit operands of the
instruction. This meant we couldn''t set the dead flag on
dead implicit defs in that case.
Fix it by introducing an opcode to mark a given implicit
def as dead.
Fixes#64565
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D157515
This reverts commit d462f65b8242a82d2430605a741825bf10ebaca0.
It breaks the modules build again, but also may inhibit the use of `-DLLVM_TABLEGEN=`.
See the discussion here: https://reviews.llvm.org/D150144#4578311
rdar://113696899
This reverts commit 30b4351c7c75296dc60fc887212cdc98e85e9996.
This caused a dependency cycle that the Swift build picked up on:
```
CMake Error: The inter-target dependency graph contains the following strongly connected component (cycle):
"llvm-tblgen" of type EXECUTABLE
depends on "LLVMCodeGenTypes" (weak)
depends on "LLVMTableGenGlobalISel" (weak)
depends on "intrinsics_gen" (strong)
"LLVMTableGenGlobalISel" of type STATIC_LIBRARY
depends on "LLVMCodeGenTypes" (weak)
depends on "vt_gen" (strong)
"vt_gen" of type UTILITY
depends on "llvm-tblgen" (strong)
"autogen_intrinsics_RISCV" of type UTILITY
depends on "llvm-tblgen" (strong)
"intrinsics_gen" of type UTILITY
depends on "llvm-tblgen" (strong)
depends on "autogen_intrinsics_RISCV" (strong)
"LLVMCodeGenTypes" of type STATIC_LIBRARY
depends on "vt_gen" (strong)
```
rdar://113636528
Some Clang command-line handling code could benefit from the option's prefixed name being a `StringLiteral`. This patch changes the `llvm::opt` TableGen backend to generate and emit that into the .inc file.
Depends on D157028.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D157029
Checks for implicit defs that are unused within a pattern and mark them as dead.
This is done directly at the TableGen level forr efficiency.
The instructions are directly created with the "dead" operand and no further analysis is needed later.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D157273
This is an alternative to D156967 where I suggested the author
could use a VBR type.
This patch takes inspirations from Opc_EmitRegister2 that is used
for two byte registers.
I'm assuming 1 or 2 byte predicates should be enough so we don't
need the fully generality of VBR.
This avoids impacting the table size on targets that have more than
128 predicates already like X86.
Reviewed By: bogner
Differential Revision: https://reviews.llvm.org/D157196
This first notebook covers the basics.
* classes
* defs
* basic types
* let in various forms
Everything up to multiclass, which will be the
start of the 2nd part of the tutorial.
I'd like to keep them in logical sections as
far as possible, so they are easy to digest.
Differential Revision: https://reviews.llvm.org/D137085
Often you are doing one of 2 things:
* Building a larger example from many small cells.
* Showing many small isolated examples.
The default so far has followed iPython, where cells are connected
by default (in its case, the interpreter state backing them sticks
around).
This change adds a new magic `%config` where you can change the setting
`cellreset` to change that behaviour (this is currently the only setting).
Also added is a `%noreset` magic so that along with `%reset` you can
override the default for one particular cell.
The default is equivalent to `%config cellreset off`. If you then
wanted to reset in a cell, you can just do %reset to override it.
(this is what the current notebooks do)
If you instead do `%config cellreset on`, cells always reset and
you can choose not to using `%noreset`.
The setting is named `cellreset` not `reset` to differentiate it
a bit more from the one off command `reset`.
The demo notebook has been updated with examples of this in action.
Reviewed By: awarzynski
Differential Revision: https://reviews.llvm.org/D149055
When generating snippets for AArch64 with --opcode-index=-1, the code
generator asserts on opcodes that are not supported according to CPU
features.
The same assertion can be triggered even when generating a serial
snippet for a supported opcode if SERIAL_VIA_NON_MEMORY_INSTR execution
mode is used and an unsupported instruction is chosen as the "other
instruction". Unlike the first case, this one may result in flaky
failures because the other instruction is randomly chosen from the
instructions suitable for serializing execution.
This patch adjusts TableGen emitter for *GenInstrInfo.inc to make
possible to query for opcode availability instead of just asserting on
unsupported ones.
~~
Huawei RRI, OS Lab
Reviewed By: courbet
Differential Revision: https://reviews.llvm.org/D146303
Introduced the convergent equivalent of the existing G_INTRINSIC opcodes:
- G_INTRINSIC_CONVERGENT
- G_INTRINSIC_CONVERGENT_W_SIDE_EFFECTS
Out of the targets that currently have some support for GlobalISel, the patch
assumes that the convergent intrinsics only relevant to SPIRV and AMDGPU.
Reviewed By: arsenm
Differential Revision: https://reviews.llvm.org/D154766
Helps tracking changes in the tables on adding new register classes and
updating BaseClassOrder values.
Also eliminates tables translating base register class indexes into
TargetRegisterClass pointers.
Reviewed By: critson
Differential Revision: https://reviews.llvm.org/D156097
Builds on top of 6de2735c2428 to fix remaining issues with iteration order in the MatchTable Combiner backend.
See D155789 as well.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D155821
getOperandBitOffset() causes the following warning on MSVC:
E:\llvm\ninja\lib\Target\SystemZ\SystemZGenMCCodeEmitter.inc(15414): warning C4060: switch statement contains no 'case' or 'default' labels
Do not emit empty OpNum switches.
Reviewed By: RKSimon, uweigand
Differential Revision: https://reviews.llvm.org/D155805
In order to generate relocations or to apply fixups after the layout
has been computed, the targets need to know the offsets of the
respective operands. There are indirect ways to figure them out in some
cases, for example, on SystemZ, the first memory operand is always at
offset 2, and the second one is always at offset 4. But there are no
such tricks for the immediate operands on SystemZ, so one has to refer
to individual instruction encodings.
This information, however, is available to TableGen. Generate
the getOperandBitOffset() method to access it, and use it to simplify
getting memory operand offsets on SystemZ. This also paves the way for
implementing symbolic immediates on this platform.
For the multi-lit operands, getOperandBitOffset() returns the offset of
the first lit.
An alternative way to obtain offsets would be to pass them to the
encoder methods, but this would require reworking all targets. Also,
VarLenCodeEmitter already does this, but adopting it requires
reworking the respective targets without other significant benefits.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D155329
