tra added a comment. We normally do not need to deviate from the host options all that often. I would argue that keeping options identical is a reasonable default for most options. For some options the driver may be able to derive a sensible value based on the host options. E.g. some options can be ignored. Some can be downgraded. Some can be replaced with a target-specific equivalent. For others we must require the user to provide the value.
So, at the very least we must be able to put all options into one of the categories. We also need to figure out what kind of syntax we'll use to specify target-specific options. We currently have a `-Xarch...` hack in some toolchains, but it's rather awkward to us in practice as it does not give you much control over where are those options placed on the cc1's command line, they are also rather verbose and usually do not support options with arguments. We could make -Xarch=XYZ a sticky option which would consider following options to apply only to particular arch with, possibly, few special arch names to specify `host`, `device`, `all` subcompilations. It's also possible that I'm reinventing the wheel here. Are there existing precedents for command-line options with this kind of multi-consumer functionality? Repository: rC Clang https://reviews.llvm.org/D49148 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
