areusch commented on PR #14233: URL: https://github.com/apache/tvm/pull/14233#issuecomment-1462566692
@junrushao looking over ObjectPath, it seems like a way to identify a particular IR node when printed. I agree it accomplishes the goal of identifying a tree path to an IR node which may otherwise have multiple. i think that's different from the goal here--the goal is to identify which framework operator ultimately caused such IR to be included. I agree this gets murky as transforms run--scheduling, for instance, creates a TIR function in which the Span could be blanket-assigned to the generated PrimFunc. If a PrimFunc fused two graph-level operators, different fragments of TIR would have different Span information attached. Problem 1 you're describing here has been contemplated in [TVM Explorer Infra RFC](https://discuss.tvm.apache.org/t/pre-rfc-tvm-explorer-infrastructure/13457) and the proposed/accepted solution was SequentialSpan (in other words, attach both parent spans when e.g. a further optimization on a schedule pass intermixes statements with different parent spans). we can also consider other solutions here, but I'm not sure I see how ObjectPath helps here. could you point us to an RFC or other discussion where Span was deprecated? -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
