I'm a bit late to this, but here are my thoughts:
The hardware string shouldn't be the only way to define target, it should be a convenient shortcut of a more complex definition. I think that's what **S0** does---we can maintain a mapping from a set of predefined hardware "keywords" into an actual target configuration, but not make it the only way to specify a target. Target configuration should allow target-specific parameters (for example a string with target-specific content). Those parameters would be accessible to the target's codegen and runtime, and only the code specific to that target would know how to interpret it. I like the idea of targets having attributes, specifically having an attribute specifying the code generator for that target. For example, "llvm" could be a known value of that attribute for some targets. "llvm" by itself should not be a target. As a matter of fact, conceptually, the fact that a target uses LLVM as code generator should not be visible outside of that target at all. However, we allow target-specific intrinsics (specifically LLVM intrinsics), so we need some sort of visibility of it outside of the target code. Now, instead of having "call_llvm_intrinsic", we could have a "call_target_intrinsic", with an extra parameter stating what codegen it is for. It would be up to the author to make sure that if a target intrinsic is used directly in the TVM IR, it will match the target's code generator. Lastly, we shouldn't really use target triples specifically. The LLVM code generator will need to know how to construct one from TVM's target desciption, but triples themselves are outdated as a concept, and are still around because it would be next to impossible to phase them out of use. --- [Visit Topic](https://discuss.tvm.ai/t/target-and-attributes/6013/9) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.ai/email/unsubscribe/9019723cb90027439472772e26b8c2209bf9471ce7ee1548955654e244225be6).
