[llvm] [BOLT] Extend Inliner to work on functions with Pointer Autentication (PR #162458)
Peter Waller via llvm-commits
llvm-commits at lists.llvm.org
Tue Nov 18 06:21:09 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");
----------------
peterwaller-arm wrote:
> currently has 118 llvm_unreachables, 9 in this very file.
I think there are valid uses for `llvm_unreachable`. I recall a [discourse thread on the topic](https://discourse.llvm.org/t/llvm-unreachable-is-widely-misused/60587/1). A quick sampling of the uses suggests plenty of the existing uses are valid. I agree it's not make or break but I think we want to be moving in the right general direction over time and have a clear idea of what primitive is the best to use in each case.
1. If it's missing functionality that we cannot currently proceed with at all, we should exit with an error, ideally surfacing information which is actionable for the user (expressing what is not supported yet).
2. If we can cope with the input anyway (e.g. by not inlining it), then in the interests of making bolt as capable as it can be across many binaries as possible, I think we should do that. Even if there are other areas of bolt where these instructions might cause problems; if it's cheap right now in the implementation of this PR to cope with these, I think we should try (but I'm not going to block this PR on that - it also makes sense to reduce the scope of the PR in the interests of making regular progress).
3. If it's a programming bug you might defend with an assertion, then `llvm_unreachable`.
https://github.com/llvm/llvm-project/pull/162458
More information about the llvm-commits
mailing list