All the the alternatives (A1a, A1b, A1c), should be able to cover the need that
we initially bought up -- around N3. Additionally, the Target system as it is
now is already powerful enough to resolve the N3 related needs that was bought
up, as the alternatives @junrushao1994 listed along the A1c direction.
In all cases , it is certainly possible to resolve the problems with extra
layers of abstractions and indirections. As a matter of fact, they are all
very similar, except for how the data structure itself is built up.
So the main thing that would be helpful here is to understand the tradeoffs
here under different contexts, given our previous discussions was focused
around N3, it is also helpful to look at things from other needs.
To give some examples:
>From N0's pov, the ability to directly pass in Target with a host field is a
>good default solutions for this most comon combo, so in the case of API/UX
>design, we might want to encourage this kind of usage without worrying about
>additional fields for hetergenous setups in a config.
```python
build(mod, Target("cuda", host="llvm"))
```
Additionally, the transition between E0 to E1 encourages a transition from
Target with host field(that indicates a mixed host program) to a device
only(without host).
>From N2's perspective. `aws/c5` favors deployment target as a holistic
>thing(aka at the config level).
```
build(mod, "aws/c5")
```
Under the context of config and target, we will need to be able to say that a
tag can refers to either a config and Target, which effectively complicates the
tagging system and explaination here. Additionally, there will be needs to have
a common mechanism to register the tags for both target and config. Making them
more uniformed would make this perspective more streamlined.
>From the N4's pov, we will need to be able to represent the objects during
>decompositions, which means there will be need of smooth transitions of
>related information at the function level. For example, for some a function
>that involves mixed target host/device mixing the transitions to a device
>only. If that entails a difference in terms of the "target constraints", e.g.
>for functions with multi-target it starts with a "config" attr, then for
>functions with a single device it becomes a "target" attr. Such transition is
>not as uniform.
In the context of N5, there will be a need to be able to log both single
device target, or multitarget config as part of the autotuning logs in the same
way. From the automation's pov they are all "target constraints" of a function,
or a collection of functions. As in N4, this would favor a single entity that
captures the "target constraint" in an uniformed way, or at least a unified
serialization mechanism and perhaps repr printing that covers the target
involved.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/pre-rfc-compilation-configuration-representation/11372/27)
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/f0bd693e141f56bca8a52bb7db681478f6e6181f203a28a925f4c093188f6af5).
