[llvm] [BOLT] Extend Inliner to work on functions with Pointer Autentication (PR #162458)

Gergely Bálint via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 18 06:05:47 PST 2025


================
@@ -313,6 +313,20 @@ class AArch64MCPlusBuilder : public MCPlusBuilder {
            Inst.getOpcode() == AArch64::RETABSPPCr;
   }
 
+  void createMatchingAuth(const MCInst &AuthAndRet, MCInst &Auth) override {
+    Auth.clear();
+    switch (AuthAndRet.getOpcode()) {
+    case AArch64::RETAA:
+      Auth.setOpcode(AArch64::AUTIASP);
+      break;
+    case AArch64::RETAB:
+      Auth.setOpcode(AArch64::AUTIBSP);
+      break;
+    default:
+      llvm_unreachable("Unhandled fused pauth-and-return instruction");
----------------
bgergely0 wrote:

Fair point, althought BOLT currently has 118 `llvm_unreachable`s, 9 in this very file. Not saying that should excuse adding more, just that this isn't a make-or-break thing.

> Alternatively, could we handle it gracefully and fall back to not-inlining things we don't support.

Tbh, here I'm more on the side of an error and exit, rather than a silent inline-skip. 
[This armclang page](https://developer.arm.com/documentation/101754/0624/armclang-Reference/armclang-Command-line-Options/Examples-for-the-armclang--mbranch-protection-command-line-option) suggests that when `FEAT_PAuth_LR ` is enabled (which is Armv9.5+), the compiler flag `mbranch-protection=standard` will mean `bti+pac-ret+pc` instead of `bti+pac-ret` (current operation). 
 (I suspect the same is expected in upstream builds of clang).
 
As these new instructions would likely need changes in BOLT, having an explicit error on these locations sound preferable, wdyt?

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


More information about the llvm-commits mailing list