chill added a comment. In D156784#4653741 <https://reviews.llvm.org/D156784#4653741>, @atrosinenko wrote:
> As discussed in D156716 <https://reviews.llvm.org/D156716>, it is not clear > if I have to add FeatureFPAC to every relevant CPU. I would say, yes, it has to be added to each CPU that has that feature - that's what a subtarget feature is for. If we need to a way to alter code generation as a response to a user choice, that ought to be done with a specific command line option and `TargetOptions` and/or function and module level attributes. > Maybe it is worth conservatively assuming that this feature should only be > enabled manually by the user as a precaution against "I have CPU core X but > it is not listed, so let's use cpu=Y because X supports all the instructions > supported by Y //(but not FEAT_FPAC)//" - that would not cause any obvious > run-time crashes under normal operation, but would make the code less secure. As far as I can tell, the existing practice for security-related code generation is to have it disabled by default and enable it explicitly by `clang` command line options (c.f `-mbranch-protection=...`, `-mharden-sls=...`, `-fstack-clash-protection`, `-fsanitize=memtag`, ...). In that spirit, I would suggest not using target features to alter code generation in a rather obscure way but being quite explicit about it. For example, have an option `-mauth-ret-check=default|force` where: - the presence of the option enables LR check before tail calls - `default` (or `enable`) would mean `FEAT_FPAC` takes precedence - `force` would mean `FEAT_FPAC` is ignored Alternatively, maybe even better, these could be options to `-mbranch-protection=...`. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D156784/new/ https://reviews.llvm.org/D156784 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
