Thanks @gigiblender ! a few points for consideration:
- Ideally NameSupply should interact well with our current linkage spec, e.g.
if a function have an attribute `global_symbol`, it means the name is
"final"(because external users are expecting to look it up with that name),
likely we need to have global. Anything that does not have a `global_symbol`
attr can subject to change.
- Would be useful to initialize a NameSupply from an existing IRModule, so it
does not need to be carried through out passes and is only needed for pass that
regenerate global vars.
In addition to that, it would be really nice to get some smart naming resolve
mechanism.
For example, it would be really nice to have the following effect (by parsing
the suffix integer separately from prefix string
```python
x = get_next_name("fun12", existing_names=["func12", "func13", "func4"])
assert x == "func14"
```
This is to avoid the case where we have "func12_0_0_0_0" when multiple set of
prefixes are called and they usually looks confusion.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/84#issuecomment-1170277851
You are receiving this because you are subscribed to this thread.
Message ID: <apache/tvm-rfcs/pull/84/c1170277...@github.com>
