Open PhilippvK opened 1 year ago
I don't remember the context of the PR well. But at that time I was working on MS tuning for Hexagon with link_params = True
, so I don't know why I didn't hit this problem.
There is no deep reason to use PostOrderVisit
there, if you can come up with a way to visit the expr in the same way that TE compiler does (and make sure to keep them in sync), feel free to make such change.
In principle, the order of returned tasks shouldn't matter. But it's unfortunate that things are not as straightforward as it should be.
In e030b14, the task extraction mechanism for MetaScheudle was adapted to use a Module-scope NameSupply for the naming of constants. However it seems like due to the use of
PostOrderVisit
in https://github.com/apache/tvm/blob/927df5966237f10978319044716d93c90bf8843c/src/relay/backend/task_extraction.cc#L80C10-L80C10, the generation of constant names starts with the last fused function (layer/layer/task) in the model while in the normal compilation flow it seems to be the other way around.This leads to a few problems/limitations when matching the tasks using all ModuleEquality implementations
Expected behavior
The tuned records for the MLPerf Tiny KWS model should be used during compilation.
Actual behavior
Warning about failed lookup for tasks in JSON database:
Here is the diff between the TIR used in TVM compilation pipeline (green) vs. the one in the MetaScheduler Tuning database:
The data of the NDArrays (ommited here for cutting down the diff) matches (which would not even be an issue when using the
ignore-ndarray
ModuleEquality), hence the only changes in the diff are die names of the constants.Environment
upstream/main
later)Steps to reproduce
Will follow up with a script later today!
Triage
Please refer to the list of label tags here to find the relevant tags and add them below in a bullet format (example below).
CC @masahi @mbs-octoml
cc @ibsidorenko