> 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.

This could probably be solved by adding `type` and/or `default` arguments to 
the argument parser, e.g.:

```
  self._register_target_attr("ultra_trail_attr_1", default=False)
```

For v1 I would prefer to only support default values, and restrict supported 
dtypes to string, int and bool.

> 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.

I agree with @PaulPalomeroBernardo on the user perspective. 
Implementing before and after options, also goes beyond the current Scope of 
UMA in my opinion. If we were to expose it in the UMA-API, pass dependencies 
should probably be implemented in TVM core.   


-- 
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/60#issuecomment-1127281501
You are receiving this because you are subscribed to this thread.

Message ID: <apache/tvm-rfcs/pull/60/c1127281...@github.com>

Reply via email to