gigiblender commented on code in PR #84:
URL: https://github.com/apache/tvm-rfcs/pull/84#discussion_r913138881


##########
rfcs/0077_name_mangling_ir_modules.md:
##########
@@ -0,0 +1,102 @@
+- Feature Name: name_mangling_ir_modules
+- Start Date: 2022-06-29
+- RFC PR: [apache/tvm-rfcs#xxxx](https://github.com/apache/tvm-rfcs/pull/xxxx)
+- GitHub Issue: [apache/tvm#0000](https://github.com/apache/tvm/issues/0000)
+
+# Summary
+[summary]: #summary
+
+This RFC proposes a clean-up of the current name mangling strategy.
+
+# Motivation
+[motivation]: #motivation
+
+One reason for this RFC is that currently, it is difficult to know at various 
points in the compiler whether a `name_hint` is final or has yet to be mangled. 
 Name mangling is performed in various places:
+
+- `tvm::runtime::get_name_mangled` prefixes a name (usually module name) with 
a function name and is called from
+    - the AOT executor to create the main function and set the 
"`global_symbol"` attribute. It is also used to obtain the main function name 
and run it. See `AOTExecutorCodegen::CreateMainFunc` and 
`AOTExecutorCodegen::Run`
+    - During TE lowering in `TECompilerImpl::Lower`.
+    - In the `source_module.cc` to perform codegen for the C runtime.
+    - In the `NameMangleExtFuncs::Run`, name mangling is applied to all the 
module functions before AOT codegen.
+- `tvm::relay::tec::GetUniqueName` is used to avoid conflicts between multiple 
variables/functions that have the same name.
+    - in the `TECompilerImpl::LowerInternal` and `LowerShape`.
+
+Additionally, multiple `GlobalVars` having the same name are created 
throughout the code. In `TECompilerImpl::LowerInternal`, they are reduced to 
single values.
+
+This RFC aims to unify the creation of unique `GlobalVars` and refactor the 
current `GlobalVar` name mangling to be done through a single entity. 
+
+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+The changes are internal to TVM. 
+The code writer is expected to avoid as much as possible calling the 
constructor of `GlobalVar` and instead use a `NameSupply` to generate one. 
+The `NameSupply` is constructed by passing a `String prefix` (usually a module 
name) that is to be prepended to the `GlobalVars` generated: `auto name_supply 
= NameSupply::NameSupplyWithPrefix(mod_name);`
+
+A `NameSupply` can be attached to an `IRModule`. The `IRModule` acts a carrier 
for the `NameSupply` through compiler passes. 
+The attached `NameSupply` can then be retrieved from the `IRModule` when, for 
example, a pass generates new `GlobalVars`.
+
+The `NameSupply` contains two methods to provide a `GlobalVar`:
+
+- `GlobalVar UniqueGlobalFor(String name, bool add_prefix)` performs a cache 
lookup and returns a `GlobalVar`. If a miss occurs, a new `GlobalVar` is 
created, inserted into the cache, and returned. The `add_prefix` boolean 
defaults to `true`. If it is `false`, then the `prefix_` field will not be 
added to the `GlobalVar`.

Review Comment:
   I think that's certainly something worth exploring. I can add that during 
the implementation if it proves necessary. 



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@tvm.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to