Merge commit 'edf21314c98a' from llvm.org/main into next

Author: git apple-llvm automerger

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