Logically, there are two kinds of operations involved: - K0: operations that deserializes/deserializes the data structure (llvm::Module) - K1: operations that transforms the llvm::Module
We are certainly in agreement that all K1 should be enclosed with option save/recovery scope. Parse/Save seems to belong to K0. From a logic reasoning pov, operations in K0 should not be impacted by cli opt as a result my comment. But I think @kparzysz-quic what you mean is that cl opt might breach into K0 as well. If that is really the case, it would indeed be helpful to take the setting/recover at the load/store level. Would be great to reason and confirm a bit. Since the ability to de-couple K0 and K1 is nice from the overall code structuring pov -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/83#issuecomment-1180419819 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/83/c1180419...@github.com>
