To match an interface or trait, users currently have to use the MatchAny tag. This tag can be quite problematic for compile time for things like the canonicalizer, as the MatchAny patterns may get applied to *every* operation. This revision adds better support by bucketing interface/trait patterns based on which registered operations have them registered. This means that moving forward we will only attempt to match these patterns to operations that have this interface registered. Two simplify defining patterns that match traits and interfaces, two new utility classes have been added: OpTraitRewritePattern and OpInterfaceRewritePattern.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
220 ms | x64 windows > MLIR.Dialect/Linalg::bufferize.mlir |
Event Timeline
mlir/include/mlir/IR/PatternMatch.h | ||
---|---|---|
193 | Wouldn't RootKind fit in 2-bits? Could this be the low-bits of the rootValue? |
Nice!
Please fix the linter messages and consider folding RootKind into some pointer.
mlir/include/mlir/IR/PatternMatch.h | ||
---|---|---|
73 | Nit: why uint16_t specifically? |
mlir/include/mlir/IR/PatternMatch.h | ||
---|---|---|
193 | We can't use a PointerIntPair here because OperationName already uses a bit (internally it is a PointerUnion of AbstractionOperation/Identifier). |
mlir/include/mlir/IR/PatternMatch.h | ||
---|---|---|
193 | Ah! Maybe worth a comment? Also would it fit within contextAndHasBoundedRecursion? (I don't know if there are 2 bits left there). |
mlir/include/mlir/IR/PatternMatch.h | ||
---|---|---|
193 | I considered fitting it into the context, but given that there is already padding for the benefit(it is only 2 bytes) I just slotted it in next to that. |
Nice, thanks
mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h | ||
---|---|---|
670 | Does the filter not have a context? |
mlir/include/mlir/Dialect/Linalg/Transforms/Transforms.h | ||
---|---|---|
670 | Not that I could find. |
Does the filter not have a context?