lhutton1 commented on code in PR #13212:
URL: https://github.com/apache/tvm/pull/13212#discussion_r1109118604
##########
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:
Apologies for only just getting back to this, yep I think the hash on the
call won't work due to difference between `initial_mod` and `mod` caused by
mutation during the partitioning process :/ I had a read through the span
filling preRFC and it does indeed sound like a complex issue, but I think the
reasoning for removing the suffix is valid (see
[here](https://discuss.tvm.apache.org/t/pre-rfc-tvm-explorer-infrastructure/13457/29#how-many-benefits-can-we-get-from-suffix-2)),
so I'm a bit hesitant to re-introduce it, but would be good to hear
@chunit-quic's opinion.
A naive and not well thought through suggestion, but I thought I'd throw it
out there - since spans don't seem to be mutated during the lowering, is it
possible to make span uniquely hashable, perhaps by introducing some kind of id
to the SpanNode and therefore keeping the name intact?
--
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]
