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
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/84#issuecomment-1184817996
You are receiving this because you are subscribed to this thread.
Message ID: <apache/tvm-rfcs/pull/84/c1184817...@github.com>
