areusch commented on PR #84: URL: https://github.com/apache/tvm-rfcs/pull/84#issuecomment-1184817996
we discussed this at the [community meeting](https://discuss.tvm.apache.org/t/next-tvm-community-meeting-july-13/13120/2) yesterday. here are notes: - @areusch: one of suggestions raised was to make it possible to reconstruct a NameSupply from an IRModule. we might need to make it possible to initialize it from multiple IRmodules since we currently lower Relay to many separate IRModules in the compiler. - @kparzysz-quic : what's the use of having multiple modules, unless they're built for separate devices. do we need `mod_name` as a field? - `mod_name` is not to distinguish different IRModules at compile time; more to distinguish separate models at runtime via namespace prefix. - @kparzysz-quic : what is the connection between the name that we attach to a global and the name that actually ends up in an object file? there is a strong need to have a degree of control over the names that end up in the object file and their visibility. how are we addressing this need? i think there is a lack of this in TVM now. we don't have a way - @tqchen: good point. we should document the linkage type. right now there is an implicit convention: the `name_hint` is not final (it's just an internal-to-compiler concept) and there's a GlobalVar which enforces that there is external linkage type with a fixed name. e.g. if we are splitting the compilation flow, then there is an expectation that when calling into a symbol, the name won't change. another rule: if a function has attribute `kGlobalSymbol`, you cannot change it or even delete it. - @manupa-arm : when we say we want to have control: do we want this to extend to Relay? if a Relay module contains a GlobalVar, should that be emitted with exactly that name? - @tqchen : if an IRModule has a function with attr `kGlobalSymbol` we should respect that. but as a rule of thumb we should delay attaching this attr til as late of possible, so we should try to avoid that symbol. - @areusch : we also don't have this ability in scheduling; it would be hard to attach that attribute to a Relay function e.g. main because we prefix lowered functions - @tqchen: we could special-case an AOT entry function when the compiler takes special care around a symbol. - filed https://github.com/apache/tvm/issues/12098 to document the convention. - @areusch some context for this RFC: in the C++ runtime, we previously mostly cared that a GlobalVar name could be passed to Module.GetFunction() and then that function would find that implemented PrimFunc. When we implemented AOT in the C runtime, we changed to expecting to be able to directly call those names as C symbols. This caused a bit of a problem when we moved to implement both the C and C++ AOTExecutor wrappers, where metadata lookups could be different because of name mangling. To solve that, we intended to move in a direction where the names of all symbols were fixed at birth, thus NameSupply. - @kparzysz-quic: who is typically the caller of these functions? - @areusch typically an executor - @kparzysz-quic can we modify the names of the global? shouldn't matter so long as everyone agrees -- 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
