> Regarding the name_hint being a final name. I am too of this opinion (it > should be a final name) and believe that it already works this way. If I am > not wrong, the only edge case is where we use the global_symbol attribute > instead.
We should define "final name". In this context, it is helpful to look at existing practices. This is a topic related to linking in most compilers, and they are closely related to the linkage type. - For a function that have ExternalLinkage, the name **cannot** change, and whatever name being supplied is the final name, this is because the users of the library needs to be able to refer to the function using the provided name. - For a function that have PrivateLinkage, the name can and should be able to change, this is because when we link multiple functions together, there can be two private functions that comes with the same name, as a result, the conflicted function can be renamed. Private functions are only referred within the module, so we can afford to rewrite all the callers of the function to the new name. - During optimization, if a function with PrivateLinkage is not called by any functions, we can safely remove that function, but we cannot do that for ExternalLinkage. There are more linkage types in LLVM but this two types roughly are sufficient for our discussion purposes. Now come back to our context, we roughly need two things: - N0: We need an IR node to uniquely identify a function, storing hints to the name, so new names can be generated base on the hint, but not necessarily pinning down the name (due to the need to support PrivateLinkage). That is `GlobalVar`. - N1: We need a way to uniquely specify the name, or specify that the linkage type of the function is external. Note that N0 means we cannot simply enforce a `name` or `name_hint` field to be final, it have to be a combination with another attribute that derives the linkage type. So our current convention is: - When a function have `global_symbol` attribute, it specifies the "final name"(as in symbol in the symbol tabel), and indicate that the LinkageType is External - When a function does not have `global_symbol` attribute, it means the LinkageType is private, at some time point, the compiler can choose to pick the final name, by attaching global symbol based on the `name_hint` of the function. But that should be deferred to as late as possible so we can perform optimizations like eliminate dead functions. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/84#issuecomment-1178996339 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/84/c1178996...@github.com>
