[PATCH] D156784: [AArch64][PAC] Declare FPAC subtarget feature

[Momchil Velikov via Phabricator via cfe-commits]

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