Thanks @zackcquic . I also did a pass over the draft PR and I think the overall
proposal looks great. It would be good to think a bit about API naming and
naming convention in related previous designs.
e.g. how can we choose the argument name to the PassContext constructor
---
[Visit
Top
Thanks @zackcquic . To follow up on naming,
My understanding is that instrument goes beyond profiling(e.g. can use to
collect the IRs being passed around, dump the IR across pass runs for generate
debugging purposes). The proposal is essentially a structured form of tracing.
Because of that
Thanks for the PR @zackcquic.
1. Why would you like to keep runtime profiling and pass profiling separate?
The benefit I see is that a lot of the code is similar. We could avoid a lot of
code duplication. On the other hand runtime profiling has does have a lot of
code around handling timing o
Also CC @zhiics @zxybazh @vinx13
---
[Visit
Topic](https://discuss.tvm.apache.org/t/pass-instrument-framework-proposal/9874/3)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apache.org/email/un
@tqchen @tkonolige Here is the RFC created for discussion.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/pass-instrument-framework-proposal/9874/2)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discu
# [IR][Pass][Instrument] Pass Instrument Framework
https://github.com/apache/tvm/pull/7952
Proposal
===
Currently in TVM, there are trace mechanisms and passes time profiling.
* ### Trace
```cpp
/*!
* \brief PassContextNode contains the information that a pass can rely on,
* such as a
