[quote="kazum, post:1, topic:6415"]
I’ve implemented [a prototype of
A0](https://github.com/kazum/tvm/tree/coreml_codegen)
[/quote]
The PR was sent and it's ready to review.
https://github.com/apache/incubator-tvm/pull/5634
---
[Visit Topic](https://discuss.tvm.ai/t/rfc-coreml-codegen/6415
@mbrookhart this sounds great!
Then I can use the second method to implement `MergeComposite` to allow
optional check functions as it currently does. Meanwhile, if a user's pattern
only needs to check attributes and shapes, the user can use the first method to
specify the pattern.
---
[V
Hmm. Okay. I'll add a check callback to the partition pass.
I think that leaves us with three levels of possible user control in level of
priority:
1. Use the Pattern Language for any constraints possible. We might be able to
add shape checking to the language, we can't use an external codegen
For our codegen, the check functions are actually quite complex. They're not
just attribute checks, there's also things relating to tensor sizes, number of
dimensions and quantisation parameters. Additionally, our codegen library
exposes an API to check whether a given operator is supported fo
I was mainly referring to this case
https://github.com/apache/incubator-tvm/pull/5637/files#diff-f9920485e5e341787129348ce1985db9R247-R251
and it does achieve the same functionality as the current `check` functions in
`MergeComposite` pass in my opinion.
In terms of ease-of-use, to me this pr
@comaniac @matt-arm
I've extending the AttrPattern to handle attributes of CallNodes and
FunctionNodes here: https://github.com/apache/incubator-tvm/pull/5637
Would you mind taking a look and letting me know if you think that would be
sufficiently powerful for solution B?
---
[Visit
Top
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.
I see. This is easily doable with the Rewriter API, since you can do an
arbitrary callback, but it doesn't have the niceties of the Parition pass.
The current AttrPattern is only matching Op attributes, but that's fairly easy
to extend.
I think I prefer doing this with the AttrPattern, it's a
VTA can't get correct in Zynq Ultra Scale based device. We once thought this
was a coherency problem, but recently I found there may be a bug in HLS C VTA
hardware with my partner
@hht.
Only FINISH instruction can set VTA_COMPUTE_DONE register in compute module.
And only GEMM/ALU instruction
