[llvm] [AArch64][PAC] Specify Defs and Uses of PAUTH_(PROLOGUE|EPILOGUE) (PR #68205)

[Anatoly Trosinenko via llvm-commits]

atrosinenko wrote:

You are right, I spotted this issue when rebased https://reviews.llvm.org/D156358 onto current mainline. In the `aarch64-signedreturnaddress.ll` test, one of the functions was emitted like this:

```
retaddr_sign_all_0:
        mov     x0, x30
        paciasp
        xpaci   x0
        retaa
```

The instructions were reordered by PostMachineScheduler:

```
# *** IR Dump Before PostRA Machine Instruction Scheduler (postmisched) ***:
# Machine code for function retaddr_sign_all_0: NoPHIs, TracksLiveness, NoVRegs, TiedOpsRewritten, TracksDebugUserValues
Function Live Ins: $lr

bb.0.entry:
  liveins: $lr
  frame-setup PAUTH_PROLOGUE
  $x0 = ORRXrs $xzr, $lr, 0
  renamable $x0 = XPACI killed renamable $x0(tied-def 0)
  frame-destroy PAUTH_EPILOGUE
  RET undef $lr, implicit $x0

# End machine code for function retaddr_sign_all_0.

# *** IR Dump After PostRA Machine Instruction Scheduler (postmisched) ***:
# Machine code for function retaddr_sign_all_0: NoPHIs, TracksLiveness, NoVRegs, TiedOpsRewritten, TracksDebugUserValues
Function Live Ins: $lr

bb.0.entry:
  liveins: $lr
  $x0 = ORRXrs $xzr, $lr, 0
  frame-setup PAUTH_PROLOGUE
  frame-destroy PAUTH_EPILOGUE
  renamable $x0 = XPACI killed renamable $x0(tied-def 0)
  RET undef $lr, implicit killed $x0

# End machine code for function retaddr_sign_all_0.
```

Unfortunately, I doubt this can be used as a MIR-based test: while such test should never **fail** if PAUTH_PROLOGUE has correct Uses and Defs, it seems to me highly fragile w.r.t. reliably catching actual regressions.

Now I plan to upload one more patch that should explicitly disallow reordering PAUTH_PROLOGUE. The above reordering is prevented by explaining to PostMachineScheduler that PAUTH_PROLOGUE changes the register (LR) that is then used by ORRXrs. But moving a PAUTH_PROLOGUE instruction from the very beginning of the function somewhere else seems completely wrong even if it commutes with the other instruction, at least if BTI is enabled. `PACI(A|B)SP` instructions have implicit BTI behavior, so such reordering would likely to cause deterministic run-time crashes. Technically, this could be hidden by AArch64BranchTargets inserting extra `BTI`s after rescheduling takes place, but it is suboptimal at least.

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