[AArch64][v8.5A] Omit BTI for non-addr-taken static fns in ELF (#135043)

This follows up commit 7af2b51, which removed the BTI at the
start of functions with internal linkage (provided they weren't
indirectly called inside the translation unit) for Linux targets.

Now we leave out the BTI for any ELF target, including bare-metal,
because the AAELF64 document in the Arm ABI has been updated to make the
same guarantee as SYSVABI64: if the linker wants to insert an indirect
branch at link time (e.g. as part of a long branch thunk) it's
responsible for making a BTI-equipped landing pad.

That was too difficult to test in the existing codegen test
`patchable-function-entry-bti.ll`, because so much of LLVM's detailed
asm output changes for non-ELF targets. So I've simplified that back to
how it was before 7af2b51 (except that now it expects no BTI in
the disputed function), and made a new test checking specifically the
difference in BTI between the formats.

Author: statham-arm

llvm/lib/Target/AArch64/AArch64BranchTargets.cpp

@@ -86,15 +86,14 @@ bool AArch64BranchTargets::runOnMachineFunction(MachineFunction &MF) {
     // non-guarded pages (which might be non-BTI-aware code) are allowed to
     // branch to a "BTI c" using any register.
     //
-    // For SysV targets, this is enough, because SYSVABI64 says that if the
-    // static linker later wants to use an indirect branch instruction in a
+    // For ELF targets, this is enough, because AAELF64 says that if the static
+    // linker later wants to use an indirect branch instruction in a
     // long-branch thunk, it's also responsible for adding a 'landing pad' with
-    // a BTI, and pointing the indirect branch at that. However, at present
-    // this guarantee only holds for targets complying with SYSVABI64, so for
-    // other targets we must assume that `CouldCall` is _always_ true due to
-    // the risk of long-branch thunks at link time.
+    // a BTI, and pointing the indirect branch at that. For non-ELF targets we
+    // can't rely on that, so we assume that `CouldCall` is _always_ true due
+    // to the risk of long-branch thunks at link time.
     if (&MBB == &*MF.begin() &&
-        (!MF.getSubtarget<AArch64Subtarget>().isTargetLinux() ||
+        (!MF.getSubtarget<AArch64Subtarget>().isTargetELF() ||
          (F.hasAddressTaken() || !F.hasLocalLinkage())))
       CouldCall = true;
 

llvm/test/CodeGen/AArch64/bti-linkage.ll

@@ -0,0 +1,47 @@
+; RUN: llc -mtriple=aarch64-linux-gnu %s -o - | FileCheck %s --check-prefixes=CHECK,NOBTI
+; RUN: llc -mtriple=aarch64-none-elf %s -o - | FileCheck %s --check-prefixes=CHECK,NOBTI
+; RUN: llc -mtriple=aarch64-none-macho %s -o - | FileCheck %s --check-prefixes=CHECK,BTI
+; RUN: llc -mtriple=aarch64-windows-msvc %s -o - | FileCheck %s --check-prefixes=CHECK,BTI
+
+;; This function has internal linkage, and nothing in this translation unit
+;; calls it indirectly. So it doesn't need a BTI at the start ... except that
+;; it might, if at link time if the linker inserts a long-branch thunk using a
+;; BLR instruction.
+;;
+;; For ELF targets, both Linux and bare-metal, we expect no BTI instruction at
+;; the start of the function, because AAELF64 specifies that it's not needed:
+;; if the linker wants to do that then it's responsible for making a 'landing
+;; pad' near the target function which _does_ have a BTI, and pointing the
+;; indirect call at that.
+;;
+;; But this is specified in AAELF64, so non-ELF targets can't rely on that
+;; guarantee, and we expect LLVM to insert the BTI anyway.
+define internal void @internal_linkage() "branch-target-enforcement" {
+; CHECK-LABEL: internal_linkage:
+; BTI:         hint #34
+; NOBTI-NOT:   hint #34
+; CHECK:       ret
+entry:
+  ret void
+}
+
+;; This function has internal linkage but _is_ potentially called indirectly
+;; (its address escapes from the module via external_linkage() below), so it
+;; needs a BTI irrespective of target triple.
+define internal void @indirectly_called() "branch-target-enforcement" {
+; CHECK-LABEL: indirectly_called:
+; CHECK:       hint #34
+; CHECK:       ret
+entry:
+  ret void
+}
+
+;; This function has external linkage, so it needs a BTI in all circumstances.
+define ptr @external_linkage() "branch-target-enforcement" {
+; CHECK-LABEL: external_linkage:
+; CHECK:       hint #34
+; CHECK:       ret
+entry:
+  call void @internal_linkage()
+  ret ptr @indirectly_called
+}

llvm/test/CodeGen/AArch64/patchable-function-entry-bti.ll

@@ -1,5 +1,4 @@
-; RUN: llc -mtriple=aarch64-linux-gnu -aarch64-min-jump-table-entries=4 %s -o - | FileCheck %s --check-prefixes=CHECK,SYSV
-; RUN: llc -mtriple=aarch64-none-elf -aarch64-min-jump-table-entries=4 %s -o - | FileCheck %s --check-prefixes=CHECK,NONSYSV
+; RUN: llc -mtriple=aarch64 -aarch64-min-jump-table-entries=4 %s -o - | FileCheck %s
 
 define void @f0() "patchable-function-entry"="0" "branch-target-enforcement" {
 ; CHECK-LABEL: f0:
@@ -49,25 +48,18 @@ define void @f2_1() "patchable-function-entry"="1" "patchable-function-prefix"="
 }
 
 ;; -fpatchable-function-entry=1 -mbranch-protection=bti
-;; For SysV compliant targets, we don't add BTI (or create the .Lpatch0 symbol)
-;; because the function has internal linkage and isn't address-taken. For
-;; non-SysV targets, we do add the BTI, because outside SYSVABI64 there's no
-;; spec preventing the static linker from using an indirect call instruction in
-;; a long-branch thunk inserted at link time.
+;; We don't add BTI c, because the function has internal linkage
 define internal void @f1i(i64 %v) "patchable-function-entry"="1" "branch-target-enforcement" {
 ; CHECK-LABEL: f1i:
 ; CHECK-NEXT: .Lfunc_begin3:
 ; CHECK:      // %bb.0:
-; NONSYSV-NEXT:  hint #34
-; NONSYSV-NEXT:  .Lpatch1:
 ; CHECK-NEXT:  nop
 ;; Other basic blocks have BTI, but they don't affect our decision to not create .Lpatch0
 ; CHECK:      .LBB{{.+}} // %sw.bb1
 ; CHECK-NEXT:  hint #36
 ; CHECK:      .section __patchable_function_entries,"awo",@progbits,f1i{{$}}
 ; CHECK-NEXT: .p2align 3
-; NONSYSV-NEXT: .xword .Lpatch1
-; SYSV-NEXT: .xword .Lfunc_begin3
+; CHECK-NEXT: .xword .Lfunc_begin3
 entry:
   switch i64 %v, label %sw.bb0 [
     i64 1, label %sw.bb1