Match naming convention for other m_Specific* matchers, and frees up the
m_Opc() matcher for future use in #84940 to allow us to capture the
opcode of a unknown binop
Moving to m_SpecificOpc does mess up the formatting in a few places,
I've tried to refactor to use the m_Value(SDValue, ....) matcher where I
can to retrieve some whitespace
These tests use constants in the physical register space. These will
correspond to different registers on different targets and aren't
stable.
Using virtual registers makes more sense here. This will print in a
coherent way if you anyone were to dump the DAG created by these tests.
Adds overloads
```cpp
auto m_ConstInt(uint64_t &);
auto m_ConstInt(int64_t &);
```
which behave analogously to `m_ConstInt(APInt &)`, but only match if the
captured integer fits within 64 bits.
I've seen more and more occurrences of what is essentially
```
m_AllOf(<sub pattern>, m_Value(BindVal))
```
That is, bind to the same SDValue that matches the sub-pattern. Most
people won't even bother write this `m_AllOf` construct because it's too
long, and instead just write another `sd_match` against the bound value.
This patch adds
```
m_Value(BindVal, <sub pattern>)
```
To replace the `m_AllOf` construct above and conditionally bind the
SDValue that matches the sub-pattern.
---------
Co-authored-by: Stefan Weigl-Bosker <stefan@s00.xyz>
BinaryOpc_match is already wired up for this - but allow us to use
m_BinOp/m_c_BinOp with the required flags directly
Updated the foldShiftToAvg folds to make use of this
Resolve#174436
Implemented matchers for intrinsics.
The usage looks something like:
```cpp
sd_match(N , m_IntrinsicWOChain<Intrinsic::${INTRINSIC_ID}>(/* match possible operands of the intrinsic */));
```
Resolves#173770
Adds m_SpecificNeg(SDValue V) to match either m_Neg(m_Specific(V)) or
constant/build-vector where elements are the negation of V's constants
Has unit test coverage on SelectionDAGPatternMatchTest.cpp
Following the suggestions in #170061, I replaced `SmallVector<SDValue>`
with `std::array<SDValue, NumPatterns>` and `SmallBitVector` with
`Bitset<NumPatterns>`.
I had to make some changes to the `collectLeaves` and
`reassociatableMatchHelper` functions. In `collectLeaves` specifically,
I changed the return type so I could propagate a failure in case the
number of found leaves is greater than the number of expected patterns.
I also added a new unit test that, together with the one already present
in the previous line, checks if the matching fails in the cases where
the number of patterns is less or more than the number of leaves.
I don't think this is going to completely address the increased compile
time reported in #169644, but hopefully it leads to an improvement.
Fixes#169645
The issue was caused by a for-loop improperly overwriting SDValue binds
when m_Reassociatable is given two or more patterns that (1) call
m_Value with an SDValue parameter and (2) differ by that parameter. This
fix comes with added unit tests relevant to SDValue bindings inside
m_Reassociatable patterns.
Essentially, the original implementation first tried to match every
combination of leaf node and pattern possible and stored that in a
matrix-like structure, and then did a recursive search on that matrix to
check if it's possible to pair every leaf with a pattern. The problem is
that m_Value has a side effect where it changes an SDValue, and the
creation of this matrix was corrupting these values. Below is an example
of this, following the order of execution in the original implementation
and using the case brought by issue #169645, where this behavior was
found. The example tries to match ((a >> 1) + (b >> 1) + (a & b & 1)),
using uppercase letters for the SDValue variables themselves and
lowercase for their values. The result is that the pattern matches the
same value for A and B, which was the behavior observed in the issue:
| Line | Leaf | Pattern | Match? | Effect |
|--------|--------|--------|--------|--------|
| 1 | a >> 1 | m_Srl(m_Value(A), m_One()) | Yes | A <- a |
| 2 | a >> 1 | m_Srl(m_Value(B), m_One()) | Yes | B <- a |
| 3 | a >> 1 | m_ReassociableAnd(m_Deferred(A), m_Deferred(B), m_One())
| No | -- |
| 4 | b >> 1 | m_Srl(m_Value(A), m_One()) | Yes | A <- b |
| 5 | b >> 1 | m_Srl(m_Value(B), m_One()) | Yes | B <- b |
| 6 | b >> 1 | m_ReassociableAnd(m_Deferred(A), m_Deferred(B), m_One())
| No | -- |
| 7 | a & b & 1 | m_Srl(m_Value(A), m_One()) | No | -- |
| 8 | a & b & 1 | m_Srl(m_Value(B), m_One()) | No | -- |
| 9 | a & b & 1 | m_ReassociableAnd(m_Deferred(A), m_Deferred(B),
m_One()) | a == b | -- |
To fix this, the function now matches the patterns during the recursive
search itself, instead of preparing the matrix beforehand. Although this
does fix the issue, it does mean that we're performing a best case of n
and worst case of n! matching attempts, instead of the fixed nˆ2 in the
original, where n is the number of patterns provided. Going back to the
table above, using this fix the lines 2, 3, 4, 6, 7, and 8 do not
happen, and so the only effects happening are A <- a and B <- b, which
then will result in line 9 matching correctly.
This patch introduces SpecificFP matcher for SelectionDAG nodes.
This includes:
Adding SpecificFP_match() in SDPatternMatch.h.
Adding test coverage in SelectionDAGPatternMatchTest.cpp.
Closes#165566
Similar to the m_BinOp/m_c_BinOp matchers, this patch introduces generic matchers for SelectionDAG nodes with three operands.
This includes:
- Adding m_TernaryOp() and m_c_TernaryOp() templates in SDPatternMatch.h.
- Adding comprehensive test coverage in SelectionDAGPatternMatchTest.cpp.
Fixes#165378
The "at construction" binop folds in SelectionDAG::getNode() has
different behaviour when compared to the equivalent LLVM IR. This PR
makes the behaviour consistent while also extending the coverage to
include signed/unsigned max/min operations.
This reverts commit 8ac7210b7f0ad49ae7809bf6a9faf2f7433384b0.
This breaks the building the AArch64 backend, e.g. see
https://github.com/llvm/llvm-project/pull/144947
Revert to unbreak the build.
Also reverts follow-up commits 1e76f012db3ccfaa05e238812e572b5b6d12c17e.
If a kernel is known to be executing only a single lane, IR
UniformityAnalysis will take note of that (via
GCNTTIImpl::hasBranchDivergence) and report that all values are uniform.
SelectionDAG's built-in divergence tracking should do the same.
Add SDPatternMatch matcher and unit test coverage for `ISD::LOAD`
opcode.
This only matches the loaded value i.e. ResNo 0 and not the output
chain.
e.g.
```
m_Load(m_Value(), m_Value(), m_Value())
```
The first value is the input chain, the second is the base pointer, and
the last value is the offset.
`m_Result<N>` matches a SDValue that is the N-th result of the defining
SDNode. This is useful for creating a more fine-grained matching on
SDNode with multiple results.
-----
Inspired by #145481
fixes https://github.com/llvm/llvm-project/issues/118847
implements matchers for reassociatable opcodes as well as helpers for
commonly used reassociatable binary matchers.
---------
Co-authored-by: Min-Yih Hsu <min@myhsu.dev>
Following discussions in #110443, and the following earlier discussions
in https://lists.llvm.org/pipermail/llvm-dev/2017-October/117907.html,
https://reviews.llvm.org/D38482, https://reviews.llvm.org/D38489, this
PR attempts to overhaul the `TargetMachine` and `LLVMTargetMachine`
interface classes. More specifically:
1. Makes `TargetMachine` the only class implemented under
`TargetMachine.h` in the `Target` library.
2. `TargetMachine` contains target-specific interface functions that
relate to IR/CodeGen/MC constructs, whereas before (at least on paper)
it was supposed to have only IR/MC constructs. Any Target that doesn't
want to use the independent code generator simply does not implement
them, and returns either `false` or `nullptr`.
3. Renames `LLVMTargetMachine` to `CodeGenCommonTMImpl`. This renaming
aims to make the purpose of `LLVMTargetMachine` clearer. Its interface
was moved under the CodeGen library, to further emphasis its usage in
Targets that use CodeGen directly.
4. Makes `TargetMachine` the only interface used across LLVM and its
projects. With these changes, `CodeGenCommonTMImpl` is simply a set of
shared function implementations of `TargetMachine`, and CodeGen users
don't need to static cast to `LLVMTargetMachine` every time they need a
CodeGen-specific feature of the `TargetMachine`.
5. More importantly, does not change any requirements regarding library
linking.
cc @arsenm @aeubanks
This patch adds icmp+select patterns for integer min/max matchers in
SDPatternMatch, similar to those in IR PatternMatch.
Reapply #111774.
Closes#108218.
This PR is related to #99591. In this PR, instead of modifying how the
legalisation occurs depending on surrounding instructions, we refine
after legalisation.
This PR has two parts:
* `SDPatternMatch/MatchContext`: Modify a little bit the code to match
Operands (used by `m_Node(...)`) and Unary/Binary/Ternary Patterns to
make it compatible with `VPMatchContext`, instead of only `m_Opc`
supported. Some tests were added to ensure no regressions.
* `DAGCombiner`: Add a `foldSubCtlzNot` which detect and rewrite the
patterns using matching context.
Remaining Tasks:
- [ ] GlobalISel
- [ ] Currently the pattern matching will occur even before
legalisation. Should I restrict it to specific stages instead ?
- [ ] Style: Add a visitVP_SUB ?? Move `foldSubCtlzNot` in another
location for style consistency purpose ?
@topperc
---------
Co-authored-by: v01dxyz <v01dxyz@v01d.xyz>
Add support for matching with `SDNodeFlags` i.e `add` with `nuw`.
This patch adds helpers for `or disjoint` or `zext nneg` with the same
names as we have in IR/PatternMatch api.
Closes#103060
Currently, when using a VP match context with `sd_context_match`, only Opcode matching is possible (`m_Opc(Opcode)`).
This PR suggest a way to make patterns with Operands (eg `m_Node`, `m_Add`, ...) works with a VP context.
This PR blocks another PR https://github.com/llvm/llvm-project/pull/102877.
Co-authored-by: v01dxyz <v01dxyz@v01d.xyz>
