[llvm] [llvm-exegesis][AArch64] Check for PAC keys before disabling them (PR #138643)

[Anatoly Trosinenko via llvm-commits]

https://github.com/atrosinenko commented:

I have just realized that the original issue was probably related to `FEAT_FPAC` (by the way, support for `FEAT_FPAC` is among the differences between emulated Neoverse-V1 that I used for testing and Neoverse-V2 mentioned it tests). I'm not sure if QEMU defines any "real" CPU model with FEAT_FPAC, but the `max` pseudo CPU model should work, though.

At the commit fd254b057fb34686d1f425592d57fe70a894fb44, I get
```
AUTIA: PAuth not supported on this system
```
for `cortex-a72` emulated CPU model and successfully executed snippets for `neoverse-v1,pauth-impdef=on` and `max,pauth-impdef=on`. If multiple opcodes are passed like in `--opcode-name=AUTIASP,AUTIA`, two `prctl` system calls ("get" and then "set") are performed for the first opcode and one more "get" `prctl` is performed for each subsequent opcode (or exactly one failing `prctl` per pauth opcode in case of `cortex-a72`, of course).

On the other hand, when executed on `cortex-a72` emulated CPU, `llvm-exegesis -mtriple=aarch64-linux-gnu -mcpu=neoverse-v2 -mode=latency --opcode-name=AUTIA --benchmark-phase=assemble-measured-code` returns `AUTIA: PAuth not supported on this system`, even though no snippet code is to be executed on the CPU, which is not correct.

It looks like the high-level logic of this code should be improved (and the description in `getIgnoredOpcodeReasonOrNull` updated). As far as I see, here are the issues that we want to avoid:
* if the CPU implements FEAT_PAuth with FEAT_FPAC, any snippet involving authentication instruction is likely to crash. As far as I understand, this does not crash the entire `llvm-exegsis` process, as it is able to handle signals that are normally fatal, but at least it reports errors that may be unexpected by the user.
* if the CPU does not implement FEAT_PAuth at all, `llvm-exegesis` still should be able to perform all tasks not involving actual snippet execution
  - it is even possible to run snippet generation (but not execution, of course) for the same instructions on x86_64 computer!
* error diagnostic is a plus

Given the above points, a reasonable solution could probably be keeping the approach implemented by this PR (request the enabled keys and, if any key is currently enabled, disable everything). But no errors should probably be reported on failure, not even "Unsupported opcode: isPointerAuth" on non-AArch64 systems. Additionally, it seems a good idea to give the user an option to opt out of these `prctl`s altogether.

* `getIgnoredOpcodeReasonOrNull` is probably intended to return error messages for the opcodes whose benchmarking is meaningless unless some custom support is implemented someday. It seems to be called even if merely *generating* a snippet on a *foreign* CPU architecture
* disabling PAuth keys as a side effect of `getIgnoredOpcodeReasonOrNull` call is probably OK, provided this does not crash llvm-exegesis
  - I guess, this could be a problem if `llvm-exegesis` executable or any shared object up the call stack is built with pac-ret - this probably only applies to libc stuff (including thread entry functions, if any)
* a failure to disable the keys when FEAT_FPAC is implemented, on the other hand, is probably not too harmful, as something like `error: 'snippet crashed while running: Illegal instruction'` would be printed in the report
  - as a reasonable tradeoff, you could return `nullptr` silently if `prctl(PR_PAC_GET_ENABLED_KEYS)` either returns 0 or sets `errno` to `EINVAL` (to rule out all "not applicable" cases we know about), but return an error message if the second `prctl` call was performed, and it failed (as it likely indicates we do something wrong)
* I doubt it is safe to assume every CPU would have the same timings with keys being enabled vs. disabled
  - it may be reasonable to perform `prctl` calls to disable all the keys by default, but even then it is probably a good idea to print a free-form warning to the console (like it is already done by some other part of llvm-exegesis for AUTIASP: `setRegTo is not implemented, results will be unreliable`)
  - or the default behavior could be to keep everything as-is and disable the keys if a special command line option is given

https://github.com/llvm/llvm-project/pull/138643