# \[pre-RFC\] TVM Explorer Infrastructure

**URL:** <https://discuss.tvm.apache.org/t/pre-rfc-tvm-explorer-infrastructure/13457>\
**Category:** RFC\
**Created:** [September 1, 2022, 3:03am UTC](https://discuss.tvm.apache.org/t/pre-rfc-tvm-explorer-infrastructure/13457 "2022-09-01T03:03:40Z")\
**Posts on this page:** 1\
**Showing post:** 29

<div class="post-metadata">

**Author:** ![chunit](https://discuss.tvm.apache.org/letter_avatar_proxy/v4/letter/c/c68b51/32.png) [@chunit](https://discuss.tvm.apache.org/u/chunit)\
**Post date:** [December 7, 2022, 1:32am UTC](https://discuss.tvm.apache.org/t/pre-rfc-tvm-explorer-infrastructure/13457/29 "2022-12-07T01:32:05Z")

</div>

Hi @lixiaoquan

> Thank you very much for the explanation.

You’re welcome, it’s really great to have a discussion about this issue. 😃

> It sometimes has more benefits, that when I saw an op without a span, I can guess it it is generated by a pass, not from original model.

Just one more thing before a long, and detailed description about removal of suffix. About the span after processing a pass, in the third part of this RFC we aim to fill span to those Relay passes which are involved in build flow. Therefore you could expect if everything of this RFC is going well, we could have span tagged result after invoking certain passes.

Perhaps in the following I could try to describe the removal of suffixes from several aspects. Hope it could provide you more reasons about why we want to remove them all in the end. 🙂

# Reference to a related work

Take the [compiler explorer](https://godbolt.org/) for example, you can see most functions in the high level language(C++) is converted to a sequence of lower level functions(assembly). It’s not necessary to tag a suffix to generated lower level functions. In this scenario, knowing a high level language is converted to which set of level functions is enough. Similarly, the suffixes might not be necessary in Relay, because knowing a frontend model layer is converted to which set of Relay exprs might be enough for the first glance.

# How many benefits can we get from suffix?

It is somehow the most important reason in my point of view personally. Suppose what we focus on is “frontend → Relay”, and what would happen if we keep the suffixes after invoking the build() or optimize()? There might be a span-tagged expr like this:

```python
%0 = expr(...) /* span=other_expr_PART_3 */

```

If user does not check the very first Relay module, which is generated by the API `from_{frontend}()`, the \_PART\_ means nothing to them. (The only thing they know is, ok, the generation of this expr is related to “other\_expr”, I don’t know the meaning of PART). Even worse, it might be confusing to them when seeing the suffix, like, where can I find the PART? Therefore, if we focus on the conversion between “frontend → Relay” only. It is not a good choice to use suffix when passes are involved.

On the other hand, the value of suffix might be a special indicator of an expr between passes, which means “Relay-\>Relay”. However, the more we try to enhance the debugging ability, the more we find “sourceName” might not be the best choice for it. For example, suppose I have an IR, which has the original form like this:

```python
# IR1
fn() {
  %0 = reshpae(..) /* span=reshpae_add_PART_1 */
  %1 = add() /* span=reshape_add */
}

```

Then I invoke a pass, which converts add call to subtract call:

```python
# IR2
fn() {
  %0 = reshpae(..) /* span=reshpae_add_PART_1 */
  %1 = subtract() /* span=reshape_add */
}

```

Finally I invoke a pass to merge these two expr to an op which defined by myself:

```python
# IR3
fn() {
  %0 = my_expr() /* span=[reshape_add_PART_1, reshape_add] */
}

```

You can see, well, `my_expr` call is from the `reshpae_add_PART_1` and `reshpae_add`. However, it seems to be the relation between “IR3 and IR1”. When I wnat to compare the relation between “IR3 and IR2”. I have to rely on the legacy (sourceName of span) from IR1, which might be confusing by its literal meaning. The better choice in this scenario might be using the line, column information. So that the relationship between IR3 and IR2 can be more straightforward. Yet there are still something wait to be delt if we want to use the line, column information. Like, how to define the line number of an IR module.

In summary, in the conversion of “frontend-\> Relay”, suffix seems to be not necessary. On the other hand, in the conversion of “Relay → Relay”, use suffix is not straightforward enough.

# Any workaround?

If suffix is something really hard to give up. Perhaps a post-processing pass can be a workaround for it. For example, a pass traverses the whole Relay IR, and tag \_PART\_ to those spans with the same SourceName. With the help of this pass, we can have a very similar result like the previous reverted PR.

Thank you for reading such a long reply. It feels great to have a discussion with you about this topic. 😃

---

_[View the full topic](https://discuss.tvm.apache.org/t/pre-rfc-tvm-explorer-infrastructure/13457)._