> 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.
Thank you for feedback @tqchen! I agree with your suggestions and amended the
text with further clarifications.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/84#issuecomment-1171207368
You are receiving this because you are subscribed to this thread.
Message ID: <apache/tvm-rfcs/pull/84/c1171207...@github.com>
