Thanks for the comments. Here are a short summary of supporting `check` using
pattern language based on my POC
(https://gist.github.com/comaniac/1f399dfdfee05a2f7a087c65c21f550c):
#### A. Callback
The `check` logic is used in callbacks to determine if this subgraph really
matches the pattern. If matching, the callback needs to create a composite
function as the POC I provided.
* User API would be similar as now. Specifically, user provides the following
inputs to `PatternCallback`:
1. A pattern.
2. A map of check functions for this pattern (e.g., `{'nn.conv2d': lambda
...: true}`).
* A redundant visit to the matched subgraph in order to create the composite
function seems inevitable.
#### B. A More Powerful but Complex Pattern Logic
The `check` logic is implemented along with the pattern using `AttrPattern`.
* User API would be just a pattern.
* We can use `pattern.partition()` to easily create composite functions.
* The logic of implementing a pattern might be more complex, implying a more
steep learning curve.
Here are my two cents. Since we already have `pattern.partition()`, it seems
not practical to improve the rewriter API to make the partition efficient. As a
result, I prefer solution **B**. On the other hand, I am not sure how complex
this logic would be and if it's reasonable for 3rd-party backend developers to
learn and implement. It would be great if @mbrookhart you could provide an
illustration or even an RFC to give us a more concrete idea :)
---
[Visit
Topic](https://discuss.tvm.ai/t/byoc-use-pattern-language-to-create-composite-functions/6727/21)
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/c089294d535f0fc5dab6b1040c5836324306ba713bef19805fd8fd8b034ab986).
