[microTVM] Refactor uTVM to microTVM

[mehrdadh]

This PR:

• Rename all uTVM files and definitions to microTVM.

[mehrdadh]

cc @areusch @gromero

[gromero]

Hi @mehrdadh Since I joined the project I was inclined to use (and tried to stick with) the form "uTVM". I have no strong feelings other than really sticking with only one form, hence I think that PR makes sense indeed (ppl might even write mTVM sometimes, which doesn't look good at all). I'm just wondering if I missed any discussion or thread about favoring microTVM. Either way I think using microTVM is the right choice, because uTVM is often written also using the mu symbol (Greek), which is confusing sometimes and might be difficult to type on some consoles. On Linux I also prefer typing "micro" instead of CTRL-Shift-u-b-5 :)

[mehrdadh]

@gromero thanks for the feedback!
The main reason as you mentioned is that "uTVM" is kinda confusing, specially for the people who are using it for the first time. And it's not really straightforward to write. It would be great if we unify it and make sure everyone is using the same brand.
We had some internal conversation, but we didn't have a community discussion about choosing a name, I guess mostly because I thought it's not a major change. However, we could post an RFC and ask for people's vote.
We could also CC people here and see if anyone has any suggestion.

[mehrdadh]

CC @leandron @manupa-arm @guberti @Mousius @giuseros

[leandron]

I was thinking about something similar to this PR when I read @areusch's PR with the MLF documentation. I agree with @gromero that sticking with one form is the important bit here.

microTVM looks great to me, because it is plain and clear on what it means. It is also already in use in many parts of the docs.

There are these places also that come to mind that need to be changed (from µTVM to microTVM):

• python/tvm/micro/contrib/zephyr.py
• python/tvm/driver/tvmc/runner.py
• python/tvm/driver/tvmc/compiler.py

In terms of the need or not for an RFC, I think the microTVM spelling is already in so many parts of the live documentation (e.g. https://tvm.apache.org/docs/microtvm/index.html), that makes this PR basically a fix PR, rather than an introductory PR. Based on that, I don't think we need an RFC for this.

Thanks for doing this work @mehrdadh!

[gromero]

The main reason as you mentioned is that "uTVM" is kinda confusing, specially for the people who are using it for the first time. And it's not really straightforward to write. It would be great if we unify it and make sure everyone is using the same brand.

Yeah, thanks for proposing that change.

We had some internal conversation, but we didn't have a community discussion about choosing a name, I guess mostly because I thought it's not a major change. However, we could post an RFC and ask for people's vote.

I asked just out of curiosity. I thought of a change like that just after I joined the project so I was wondering if I missed anything recently in the open so I could check it out curiosity. I really don't think it's necessary a RFC for that change.

[Mousius]

This is a great improvement @mehrdadh, I agree microTVM is the most correct as I had similar feelings towards the awkwardness of µTVM -> uTVM (and µ broke one of my scripts 😿). Thanks for proposing this 😸

One small thing that follows on from @leandron's comment is that there are also some µs hiding in NEWS.md and CONTRIBUTORS.md

[mehrdadh]

@leandron @Mousius thanks for pointing out those files. I fixed all of them.
We still have couple of µTVM and utvm in NEWS.md which are mentioning some PRs. I haven't changed those. Here is a list of them:

• µtvm debug improvements µtvm debug improvements #5648
• µTVM CRT modifications for on-device RPC server µTVM CRT modifications for on-device RPC server #5921
• AutoTVM + uTVM for Cortex-M7 ([RUNTIME][uTVM] AutoTVM + uTVM for Cortex-M7 #5417)
• uTVM support for ARM STM32F746XX boards ([µTVM] Enable AutoTVM for ARM STM32F746XX Boards #4274)
• [BUILD] Disable utvm standalone runtime by default ([BUILD] Disable utvm standalone runtime by default #4240)

We could also refactor these if someone with contributor access could help in renaming these PRs.

[mehrdadh]

cc @hogepodge
It would be great to also reflect this PR in TVM doc. I'll be happy to do it if you could point me to where the doc lives.
Thanks!

[areusch]

thanks @mehrdadh i agree this makes more sense.