You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tvm.apache.org by Andrew Reusch via Apache TVM Discuss <no...@discuss.tvm.ai> on 2022/06/09 18:58:58 UTC
[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Name mangling in IRModules
Hi all,
In [[mini-RFC] Name mangling in AOT](https://discuss.tvm.apache.org/t/mini-rfc-name-mangling-in-aot/9907), we discussed ways to accommodate the `runtime::Module` tree in an embedded environment, where we prefer to call functions directly in the generated C using their symbol name rather than looking them up at runtime via a string dictionary. Mangling was needed to namespace these functions.
I think initially we viewed mangling as necessary for the top-level function names; therefore, we modified TECompilerImpl::Lower to produce PrimFuncs that contained module names.
Since then, we've come to a number of challenges around mangled names:
- tir.Constant may be declared as global variables by codegen; but then these names should really be mangled.
- We introduced a new MetadataModule which defined a PrimFunc outside of TECompilerImpl::Lower which we use to support the PackedFunc-based AOTExecutor. Because this function was defined separately, its name wasn't mangled. This broke the multiple-model-in-the-same program use case. We had to work around this by [conditionally](https://github.com/apache/tvm/blob/main/src/target/source/source_module.cc#L823) mangling the function name depending which runtime was in use.
Recall that mangling is needed in cases where two models are compiled into the same program--this turns out to surface itself mainly in the microTVM/C runtime use case, where we are not loading shared libraries. We were able to implement AOTExecutor in the C++ runtime because there, modules are compiled into `.so` and there is a mechanism to de-conflict symbol names which are duplicated across `.so`. In the C runtime we are not so lucky--all functions must be prefixed/mangled to avoid conflict.
I propose we push all mangling out of the central compiler and into the codegen layer. This means that codegen would need to rewrite references to unmangled names as necessary--e.g. to tir.Constant, to tir.Call, and e.g. when generating FuncRegistry. This is somewhat burdensome on the C and LLVM codegens, but there, mangling is truly a property of the runtime environment and not necessarily something that needs to live in the central compiler.
Would love to hear everyone's thoughts!
cc @manupa-arm @Mousius @alanmacd @mbs-octoml @tqchen @junrushao1994 @jroesch
Andrew
---
[Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-name-mangling-in-irmodules/12944/1) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/411e271da76ec9b2d3bdb857c10f8804408a6331e1ea9405d3af58a96964f387).
[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Name mangling in IRModules
Posted by Andrew Reusch via Apache TVM Discuss <no...@discuss.tvm.ai>.
i agree with that direction, but I think to do that requires us to merge the IRModules so that mangling transforms are applied globally rather than to just a part of the program. do you agree?
---
[Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-name-mangling-in-irmodules/12944/5) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/23f35c45c9e245fa3befbeaef03a8c4e354885cc422a27eae6969b37b31678f5).
[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Name mangling in IRModules
Posted by Mark Shields via Apache TVM Discuss <no...@discuss.tvm.ai>.
Name supplies usually have both a cache lookup:
```
name_supply.UniqueGlobalFor("__main__")
```
and a hinted fresh name generator:
```
name_supply.FreshGlobalWithPrefix("my_module", "my_var", "any_other_prefix")
```
---
[Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-name-mangling-in-irmodules/12944/10) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/5c85a3fe54de13fec8cc509d96f5e3021c35bfbd9f32d9b1b67f6bdae35b1728).
[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Name mangling in IRModules
Posted by tqchen via Apache TVM Discuss <no...@discuss.tvm.ai>.
> How would we enforce this fixed global symbol? Also from name supply?
When a function need to fix a global name, it will attach an attr "global_symbol" with the name. That attr can be used say by BYOC to pick a name, attach the global symbol, so followup passes respect that constraint.
We can have a stable set of reserved names.
---
[Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-name-mangling-in-irmodules/12944/9) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/bc3befa959ee6db712f2729d47ee03a3f8601599959582802e3ce1c451012286).
[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Name mangling in IRModules
Posted by Andrew Reusch via Apache TVM Discuss <no...@discuss.tvm.ai>.
[quote="mbs-octoml, post:6, topic:12944"]
Other than the plumbing, is there an issue with threading a name supply so that globals have a unique and appropriately hinted name at birth?
[/quote]
One question in my mind is: there are some names which must be stable e.g. `__main__`, `get_c_metadata`. I presume there would be a way to tell the name supply about this?
[quote="tqchen, post:7, topic:12944"]
a fixed `global_symbol`,
[/quote]
How would we enforce this fixed global symbol? Also from name supply?
---
[Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-name-mangling-in-irmodules/12944/8) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/b1064b5c7f5a852dbe60d5838c5ab6b45da62371541b3b0164f3c3845b92e4a3).
[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Name mangling in IRModules
Posted by tqchen via Apache TVM Discuss <no...@discuss.tvm.ai>.
[quote="mbs-octoml, post:6, topic:12944"]
(While doing this we could also ensure names begin in GlobalVar form instead of String form, since the latter causes multiple GlobalVars to be created with the same name
[/quote]
Indeed the `name_hint` field in GlobalVar is supposed to work for that purpose(a hint rather than a fixed name). In TIR and likely broadly, we use `global_symbol` attr to indicate the externally enforced name(which can not change) and that name can be referenced externally and we cannot change it during compilation.
> Followup on @areusch 's point merge the IRModules so that mangling transforms are applied globally
Agreed, alternatively, we still allow user to separate modules, where cross module interaction are done through a fixed `global_symbol`, which is less ideal but needed sometime. The encouraged path is to always hold as much as possible internally.
---
[Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-name-mangling-in-irmodules/12944/7) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/8340f45323841fb43f1b3b174dbe9adc3e5c6c946efaf47cf77a6e1cccb6df9b).
[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Name mangling in IRModules
Posted by Mark Shields via Apache TVM Discuss <no...@discuss.tvm.ai>.
Other than the plumbing, is there an issue with threading a name supply so that globals have a unique and appropriately hinted name at birth? It's not too hard to support name supply splitting such that names can be drawn from independent supplies without collision. It is also possible to refine the hints to, eg, include prefixes hinting at the backend or other context which can help keep the names a little self-describing.
(While doing this we could also ensure names begin in GlobalVar form instead of String form, since the latter causes multiple GlobalVars to be created with the same name hint but different identity, see our friend te_compiler.cc for hackery to work around that.)
I ended up needing a name supply in collage btw: https://github.com/mbs-octoml/mbs-tvm/blob/40b834911420c3c453e37cfe286b4c2c3e74b2ac/src/relay/collage/name_supply.h#L36
---
[Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-name-mangling-in-irmodules/12944/6) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/f48648a4414fe7a3c4628c00fd87e1d2e5a8218b2d794254cdaed50fa4da0a52).
[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Name mangling in IRModules
Posted by tqchen via Apache TVM Discuss <no...@discuss.tvm.ai>.
Agree that mangling should be deferred as long as possible. I think the keys is not to push all mangling to a certain stage, but have a clear spec about what can be mangled, and what cannot
---
[Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-name-mangling-in-irmodules/12944/4) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/2dab3dadae180cd17169c4474eeeb20e8f35881d697af7284648d29995e96b4f).
[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Name mangling in IRModules
Posted by Andrew Reusch via Apache TVM Discuss <no...@discuss.tvm.ai>.
One related thing was that we intended to consolidate all of the different functions into one IRModule (e.g. those passed to external codegen with those passed to ordinary TVM codegen). If we had done that, we could probably do the following:
- If a Relay-to-Runtime hook is used, find a way to lock the name or provide a way for that codegen to mangle the function name internally.
- If a TIR-to-Runtime hook is used, just mangle the names ourselves right before codegen.
We might still be able to get away with applying a mangle pass to a collection of IRModules if we did it at a single point.
---
[Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-name-mangling-in-irmodules/12944/3) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/4f023c4219c3d7f4125baa2086abfe17c71b0b0eccb989a04bd46e7c56908e9a).
[Apache TVM Discuss] [Development/pre-RFC] [pre-RFC] Name mangling in IRModules
Posted by tqchen via Apache TVM Discuss <no...@discuss.tvm.ai>.
This is somewhat related to linkage itself.
Specifically, depending on the progress of lowering, there can be a need to decide on name earlier if some of the external codegen involved(e.g. BYOC that pre-decides on "global_symbol" of the name, or user specifies that they would like to "lock" the name so they can be accessed from outside).
Aka we cannot force all he naming being deferred. This being said, we should have a clear critieria to tell that what names are "internal", as a result can be changed, and what are "external", as a result need to be fixed due to prior passes and agreements.
---
[Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-name-mangling-in-irmodules/12944/2) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/9727063f4583f65b205703334e116459e9a702313a2e4a50f4acc47756dfa2a2).