tqchen commented on PR #12066:
URL: https://github.com/apache/tvm/pull/12066#issuecomment-1181791496
Alternatively, we can make name supply an `idempotent` object, which means
it is not part of the serialization and will be nullptr initially. Calling an
API `IRModule->GetOrCreateNameSupply()` will recreate it and store it in the
internal private field if it starts as nullptr, and reuse the created object.
Even in this alternative case, we need to work carefully with cases where we
copy on write the IRModule. In nature NameSupply is a mutable object while
IRModule is moving towards more immutable style. e.g. if we copy an IRModule
and mutate it once, we need to understand the API impact on the original
IRModule. Allowing recreation of NameSupply from fresh might be the best way
to avoid such problems.
So possible options:
- F0: `IRModule->CreateNameSupply()` which recreates NameSupply when needed,
always fresh, not all passes need it and minimize IRModule data structure for
serialization and other purpoes
- F1: `IRModule->GetOrCreateNameSupply()` initialize NameSupply in first
use, get around serialization problem. May have problems when we Copy and
branch out IRModules (where the new IRModule needs to effectively start from a
nullptr again).
Example to demonstrate the branching case
```python
def transform_example(moda):
modb = tvm.transform.SomePass1()(moda)
modc = tvm.transform.SomePass2()(moda)
```
In the above example, we can either choose to persist NameSupply during
transformation, as a result modb, modc share the same NameSupply, causing bugs
since they really are two different pathways. Or we duplicate/recreate the
NameSupply in each pass(since we do not know whether or not the NameSupply will
be used in another mod), which leads to overhead.
This is of course follows the design rationale of keeping things immutable,
in this world, likely likely F0 and F1 will have similar effects and recreation
when needed(in few times that it is necessary) may not be a bad idea.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
