tmatheson added a comment. In D142963#4094545 <https://reviews.llvm.org/D142963#4094545>, @andrewrk wrote:
> Speaking as the one who filed the motivating bug report, all of the above > behaviors are fine. The motivating use case is explicitly specifying a //full > set// of enabled/disabled features, leaving nothing changed by LLVM's own > dependency resolution. In this use case, LLVM would never see any of these > three scenarios as input. This is not something that I would recommend that you do, at least until we have a coherent model for what enabling/disabling features via `-target-features` means with respect to backend features. Currently: - Architecture features are treated specially in some cases, - it's not clear what negative features mean with respect to dependent features, - the order in which you specify the `-target-features` changes the results, - etc. We don't test any combinations that we don't expect out of the clang driver (these are the first clang tests ever added for negative architecture features). You might have more reliable results if you stick to only using negative features where they are needed to disable features that were implicitly enabled. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D142963/new/ https://reviews.llvm.org/D142963 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
