In particular: 1. The Dominator pattern adds some fuzziness to the pattern matching that is non-standard for graph pattern matchers. It provides a way to find something like a convolution op, who's output is then used by several elementwise ops, that are then combined together. This kind of feature is often found in the current operator fusor and device code like VTA, we're thinking of using the pattern to clean up and simplify those passes. A review of the API and the example unit tests would be appreciated. 2. The pattern partitioning function finds matches for the patttern and replaces those subgraphs with function calls to identical subgraphs. This gives us a way of isolating patterns that can later be offloaded to a fusion or a bring your own codegen pass.
Another point bring out is that this pattern matcher, as it currently stands, is only capable of matching patterns with a single output. Matching something like an LSTM cell is currently out of scope. Is anyone aware of a case where mutli-output pattern matching is needed in the near term? Thanks, Matthew --- [Visit Topic](https://discuss.tvm.ai/t/rfc-relay-program-matching-for-relay-pt-1-a-pattern-language/5833/28) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/40e3a7d6b1ce91dc22d23ed8c53acef96595c4ca473f080b2aba58af1689938b).
