[llvm] [AArch64][PAC] Move emission of LR checks in tail calls to AsmPrinter (PR #110705)

[Anatoly Trosinenko via llvm-commits]

================
@@ -0,0 +1,59 @@
+; RUN: llc -mtriple aarch64-linux-pauthtest -o - %s \
+; RUN:     -aarch64-authenticated-lr-check-method=xpac-hint \
+; RUN:     -stop-before=aarch64-ptrauth \
+; RUN:     | FileCheck --check-prefix=MIR %s
+
+; RUN: llc -mtriple aarch64-linux-pauthtest -o - %s \
+; RUN:     -aarch64-authenticated-lr-check-method=xpac-hint \
+; RUN:     | FileCheck --check-prefix=ASM %s
+
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128-Fn32"
+
+; Test that expansion of AUTH_TCRETURN does not crash due to unavailability of
+; neither x16 nor x17 as a scratch register.
+define i32 @test_scratch_reg_nobti(ptr %callee, ptr %addr) #0 {
+entry:
+  ; Force spilling of LR
+  tail call void asm sideeffect "", "~{lr}"()
+  ; Clobber x0-x15 and x18-x29
----------------
atrosinenko wrote:

> I'm not sure if I get the reason why x16 and x17 should not be clobbered for this test. Could you please clarify why?

Frankly speaking, I don't have strict explanation either. Maybe this tricks register allocator into allocating precisely x16 and x17 as operands of `blraa` because they end up being "the most free" registers among the GPRs, but this is definitely hackish (I guess I have to at least update the inline comments with this explanation, though).

I'm not sure how to make this more robust - maybe pre-committing XFAILing tests could help.

> BTW, when I locally tried to add them to clobber list, I got braa x18, x17, where both x18 and x17 are not spilled/restored while being temporary non-callee-saved clobbered registers (see https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#general-purpose-registers) - this does not look correct, but I might be missing smth.

IIUC one of the ways x16 and x17 are special is that they can be clobbered by linker-generated code when transferring control from caller to callee, so absence of spill/restore code for x17 looks correct: it has unspecified value on function entry as well as after being _clobbered_ by inline asm, so looks like there is no reason to preserve its value. x18 is trickier, but I guess we observe the case "... then it should use r18 as an additional temporary register", so it is probably handled the same way as x9-x15.

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