areusch commented on pull request #7785: URL: https://github.com/apache/tvm/pull/7785#issuecomment-828602244
@manupa-arm @giuseros I discussed this with @tqchen a bit. The overarching problem is the Target string is used to key autotvm logs, so adding non-autotuning attrs to Target means that tuning logs can't be directly used when those attrs change. To address this, we will either need: a) a new e.g. runtime-options object or b) a way to filter the non-autotvm related attrs from Target when building the tuning log key. A related question is whether or not we have a way to raise an exception when a user specifies an unregistered Target key--I can't remember offhand but suspect @zxybazh knows. This would become more important when we split config into two objects and need to provide feedback when the user accidentally specifies e.g. executor as part of Target. We also discussed that it's possible executor could have a place in Target in the future, should graph-level tuning further evolve. However, here we need to implement something that reflects the present-day state of the repo. We have two options proposed: 1. add `--executor=` with no default to Target, which will not affect tune logs except in cases where aot executor is used. 2. add `executor=` as a `relay.build` kwarg. Both of these are hacky--the proper thing is something like the a) or b) solutions proposed above. Between hacks 1 and 2, the downside of 1 has been spelled out earlier here, and the downside of 2 is that it creates a fairly central kwarg we'll have to deprecate in the near future. I guess I have a preference for solution 1), because we already include `--runtime` in Target, so in that we'll need to "deprecate" the `--runtime` Target attr as well, we are deprecating things in a single place rather than in two. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
