[llvm] [AArch64][PAC] Introduce AArch64::PAC pseudo instruction (PR #146488)

Peter Collingbourne via llvm-commits llvm-commits at lists.llvm.org
Tue Jul 15 12:51:59 PDT 2025


pcc wrote:

> My point is that security-affecting updates should be better merged sooner than later :)

It is not so clear cut and this is not the criteria that I would use when making such decisions. For example if we increase the amount of security provided by a mitigation (assuming that security can be objectively measured) but make it so expensive as to be prevent some users from deploying it at all, the practical effect is reduced security.

That being said: in parallel I was also measuring the actual performance impact of this PR. I patched this PR into my [structure protection branch](https://github.com/pcc/llvm-project/tree/pfp) (top two commits) and measured it using the included pfp-bench script on my M2 Ultra Mac Studio. The performance impact of this change was below the noise level on BM_RPC_Fleet/process_time which is the benchmark most affected by structure protection. This result was even when using `-fexperimental-pointer-field-protection=untagged` which is most likely to be affected by this change due to use of constant discriminators. So indeed it looks like the performance impact is small if it exists and I don't have any performance concerns with this patch.

Command run:
```
../llvm/utils/pfp-bench --base-commit pfp~2 --test-commit pfp --project-path ~/2/fleetbench --num-iterations 512 --num-binary-variants 16 --output-dir pr146488-untagged
```
Result after 1400 runs (benchmark time in ns, x is without this PR, + is with):
```
BM_RPC_Fleet/process_time
x /tmp/.psub.PHbSvGg1QP
+ /tmp/.psub.O3H7nAag4Z
    N           Min           Max        Median           Avg        Stddev
x 1400        188544        236400        218269        217419     6916.1701
+ 1400        192093        235131        217715     217268.38     6423.6861
No difference proven at 80.0% confidence
```
I think it is important to have a convenient and objective way of measuring the performance impact of changes like this. Once structure protection is landed (or even before that, by using my branch) I think we'll have that using something like my script. If something similar can be developed for PAuth ABI I think that would be great as well.

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


More information about the llvm-commits mailing list