[all-commits] [llvm/llvm-project] 3e98fb: [mlir] Refactor RewritePatternMatcher into a new P...

[River Riddle via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 3e98fbf4f522bf475ae2199a29f5411c86973ce5
      https://github.com/llvm/llvm-project/commit/3e98fbf4f522bf475ae2199a29f5411c86973ce5
  Author: River Riddle <riddleriver at gmail.com>
  Date:   2020-06-18 (Thu, 18 Jun 2020)

  Changed paths:
    M mlir/include/mlir/IR/PatternMatch.h
    M mlir/lib/Dialect/Linalg/Transforms/Transforms.cpp
    M mlir/lib/IR/PatternMatch.cpp
    M mlir/lib/Transforms/DialectConversion.cpp
    M mlir/lib/Transforms/Utils/GreedyPatternRewriteDriver.cpp

  Log Message:
  -----------
  [mlir] Refactor RewritePatternMatcher into a new PatternApplicator class.

This class enables for abstracting more of the details for the rewrite process, and will allow for clients to apply specific cost models to the pattern list. This allows for DialectConversion and the GreedyPatternRewriter to share the same underlying matcher implementation. This also simplifies the plumbing necessary to support dynamic patterns.

Differential Revision: https://reviews.llvm.org/D81985


  Commit: 80d7ac3bc7c04975fd444e9f2806e4db224f2416
      https://github.com/llvm/llvm-project/commit/80d7ac3bc7c04975fd444e9f2806e4db224f2416
  Author: River Riddle <riddleriver at gmail.com>
  Date:   2020-06-18 (Thu, 18 Jun 2020)

  Changed paths:
    M mlir/include/mlir/IR/PatternMatch.h
    M mlir/include/mlir/Transforms/DialectConversion.h
    M mlir/lib/IR/PatternMatch.cpp
    M mlir/lib/Transforms/DialectConversion.cpp
    A mlir/test/Transforms/test-legalize-unknown-root.mlir
    M mlir/test/lib/Dialect/Test/TestPatterns.cpp

  Log Message:
  -----------
  [mlir] Allow for patterns to match any root kind.

Traditionally patterns have always had the root operation kind hardcoded to a specific operation name. This has worked well for quite some time, but it has certain limitations that make it undesirable. For example, some lowering have the same implementation for many different operations types with a few lowering entire dialects using the same pattern implementation. This problem has led to several "solutions":
a) Provide a template implementation to the user so that they can instantiate it for each operation combination, generally requiring the inclusion of the auto-generated operation definition file.
b) Use a non-templated pattern that allows for providing the name of the operation to match
  - No one ever does this, because enumerating operation names can be cumbersome and so this quickly devolves into solution a.

This revision removes the restriction that patterns have a hardcoded root type, and allows for a class patterns that could match "any" operation type. The major downside of root-agnostic patterns is that they make certain pattern analyses more difficult, so it is still very highly encouraged that an operation specific pattern be used whenever possible.

Differential Revision: https://reviews.llvm.org/D82066


Compare: https://github.com/llvm/llvm-project/compare/af8aee7c073b...80d7ac3bc7c0