chunit-quic commented on code in PR #13212:
URL: https://github.com/apache/tvm/pull/13212#discussion_r1116451045
##########
python/tvm/relay/frontend/common.py:
##########
@@ -1067,6 +1067,20 @@ def __init__(self, span):
self._span =
tvm.relay.Span(tvm.relay.SourceName(span.decode("utf-8")), 0, 0, 0, 0)
else:
assert False, f"unsupported span type: {type(span)}"
+ self.suffix_str = "_PART_"
+ self.counter = 0
+ self.distance_from_leaf = -1
+
+ def _create_span(self):
+ """Adds suffix_str + counter value to _span.source_name.name,
+ to create a unique source_name for the Relay layer
+ """
+ if self.distance_from_leaf == 0:
+ return tvm.relay.Span(tvm.relay.SourceName(self._span), 0, 0, 0, 0)
+ self.distance_from_leaf -= 1
+ span_str = "{}{}{}".format(self._span.source_name.name,
self.suffix_str, str(self.counter))
+ self.counter += 1
+ return tvm.relay.Span(tvm.relay.SourceName(span_str), 0, 0, 0, 0)
Review Comment:
Hi @arina-grovety ,
> First, do I understand correctly that the workflow in my case will be as
follows:
Yes, invoke the post-processing pass to tag suffix to IR1 should result in
the same effect as your modification currently. Which is that the relation
between each span and expression is one-to-one mapping.
One more thing is, sorry that perhaps I forgot to deal a condition in the
previous pseudo code. We might need a dict to record whether the span of an
expression is rewritten. If yes, return the written expression, else keep
visiting the expression. Otherwise, we might rewrite the span of an expression
which has many consumers mutiple times.
> Doesn't this mean that, although optional, we will again get the situation
we wanted to avoid by removing the suffixes?
Unfortunately yes. The post-processing way is a workaround specifically for
this case. We will still face the problems introduced by suffix, even though it
is optional. Currently we use the span, or to be more precisely, the
source_name attribute of span as the one and only one indicator to the source
of an expression. Somehow it might be OK for the mapping between `frontend
source(TF, ONNX...) <-> Relay IR (with passes)`.
However, we observe that in some use cases, what we ask for span is much
more than what it can provide to us currently. Like:
1. Be an unique indicator for us to obtain which expression a span belongs
to.
2. Indicate which expression produces the output tensor of its frontend
source layer in one-to-many conversion.
3. Construct precise mapping between a pass
Including the issue 1 we have in here, we also have some discussions in the
preRFC try to handle the issues above, for example.
[line column number for
3.](https://discuss.tvm.apache.org/t/pre-rfc-tvm-explorer-infrastructure/13457#unresolved-questions-19)
[A var tracing map for
2](https://discuss.tvm.apache.org/t/pre-rfc-tvm-explorer-infrastructure/13457/17?u=chunit)
[add attribute or custom interface for
2.](https://discuss.tvm.apache.org/t/pre-rfc-tvm-explorer-infrastructure/13457/32#1-extend-the-object-span-add-an-attribute-1)
Because both expressions and spans might be changed, merged or even
discarded during the pass transformation, it is hardly to reach all
expectations with the capacity of current span instance. Until now we have
gathered some idea, yet it is still far from the implementation. Therefore
currently a post-processing workaround might be an short-term alternative
before a proper mechanism is done
--
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]
