Hi @MarisaKirisame , I currently have a question about representing "location inside the program" because when the users want to query about the Dataflow-Info, they will need to use "location".
**TLDR**: Pointers to ASTNodes are not one-to-one correspondent to "locations in the program". Can the usage/development of AAM/ADI lead to a good enough data representation of "location" for the compiler-pass developer to easily use it to query about Dataflow-Info or other info? **Detailed Version**: I notice that both in HalideIR and RelayIR, we don't explicitly require AST to really be a tree but a DAG. That means a pointer to an ASTNode cannot easily represent a precise location in the program. For example, in HalideIR, `add(x,x)` might be a node with two pointers pointing to one node, however, using the pointer to `x` will lead to ambiguity of position -- is the user asking for the Dataflow-Info right before the first `x` or the second `x`? The part in HalideIR is still fixable, at least a brutal way in mind is to just make DAG into a real tree; I also have another idea to fix that but the modification is not as simple as the current proposal, and I am currently concerned about how well-adapt this another solution is in this context of IRFunctor. However, I think the first brutal solution cannot adapt to RelayIR because it seems like (from the documentation) the semantic of DAG and Tree is different? Basically, when the current compiler-pass developer wants to get Dataflow-info, in the current context, the signature of IRMutator/IRFunctor/IRVisitor only provides "NodeRef" as default. As above suggested (the ambiguity using NodeRef to represent location) **I tend to believe this signature will have to extend if the compiler-pass developer wants to get Dataflow-Info.** -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/apache/incubator-tvm/issues/4468#issuecomment-565901356
