PaulPalomeroBernardo commented on PR #60:
URL: https://github.com/apache/tvm-rfcs/pull/60#issuecomment-1126285691
So here is my take on A2:
In the accelerator-specific backend, a user would register target attribute
names e.g.
```
class UltraTrailBackend(UMABackend):
def __init__(self):
super(UltraTrailBackend, self).__init__()
#######################################################################
# Target configuration
#######################################################################
self._register_target_attr("ultra_trail_attr_1")
self._register_target_attr("ultra_trail_attr_2")
```
They can be used during target creation similar to other sub_target strings
```
ut_target = tvm.target.Target("ultra_trail -ultra_trail_attr_1=attr1
-ultra_trail_attr_2=attr2")
```
This is basically implemented by passing a list of attribute names to the
target kind registration
```
TVM_REGISTER_GLOBAL("relay.backend.contrib.uma.RegisterTarget")
.set_body_typed([](String target_name, Array<String> attr_names){
auto target_kind =
::tvm::TargetKindRegEntry::RegisterOrGet(target_name)
.set_name()
.set_device_type(kDLCPU)
.add_attr_option<Array<String>>("keys")
.add_attr_option<String>("tag")
.add_attr_option<String>("device")
.add_attr_option<String>("model")
.add_attr_option<Array<String>>("libs")
.add_attr_option<Target>("host")
.add_attr_option<Integer>("from_device")
.set_attr<FTVMRelayToTIR>("RelayToTIR",
relay::contrib::uma::RelayToTIR(target_name))
.set_attr<FTVMTIRToRuntime>("TIRToRuntime",
relay::contrib::uma::TIRToRuntime);
for (auto &attr_name : attr_names) {
target_kind.add_attr_option<String>(attr_name);
}
});
```
The main downside I see with this, is that all attributes are treated as
strings since the type is hardcoded. However, I'm not sure if we can avoid this
at all.
What do you think?
For A1:
I would like to keep the phases. They definitely need proper documentation,
but I think a handfull of phases (e.g., `PRE_PARTITIONING`,
`POST_PARTITIONING`, ...) provide more orientation for new users than having to
explicitly define the dependencies to other passes. We could think of also
supporting the `before` and `after` options to provide more flexibility for
experienced users.
--
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]
