Wow lots more discussion here! Thanks @junrushao1994 for writing up our discussions. So one thing I'd like to point out is that the recursive Target approach is not more expressive than the approach proposed by this original RFC. Expressing a "contains" relation can be done equivalently well by - defining a recursion relationship inside the Target data structure - defining another structure which describes the contains relationship (akin to a join table in database theory)
The main reason I am interested in the join-table approach here is that it vastly simplifies `MergeTarget` as described by Junru above. And, I'd like to point out that it's not sufficient here to merely define a function which hides the complexity under the covers. Users need to be able to understand what this function is doing because they are writing the inputs (though we are providing a tag, [Command Line Configuration Files](https://github.com/apache/tvm-rfcs/blob/main/rfcs/0030-tvmc-comand-line-configuration-files.md) contemplates an expansion of the role of tagging to include tagging a partial configuration, as discussed earlier. I'm not sure it will be generally simple to explain how MergeTarget works as Target grows if we adopt the general approach of trying to attach every piece of compiler config to some Target which "owns" it. The drawback of the flat configuration structure is it could be more difficult to consume inside the compiler. We should discuss whether this is truly an issue and how to mitigate it. Finally, while I do think it's important to arrive at an an expressive, understandable Target data structure, as the compiler grows more complex, I think there is a tension between a Target structure which is clear to the user and a Target structure which naturally reflects the organization of the compiler (and therefore has the nice properties of clearly delineating where config should live and being easy to route in the compiler top-level). Hopefully, the organization of the compiler is also such that it's logical to a power user interested in creating a complex config. However, here I think that UX sugar can help to compose the common target patterns such as "cuda" (which really means 1 CUDA device with an implied "llvm" host). We already do this today anyway, so I suspect it will continue to play a role in the future. --- [Visit Topic](https://discuss.tvm.apache.org/t/pre-rfc-compilation-configuration-representation/11372/34) 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/30809ee43fa1aa60868eecc5edabeb2520299736463ead505d5c1822243e6986).
