48 lines · plain
1; RUN: llc -mtriple=aarch64-linux-gnu %s -o - | FileCheck %s --check-prefixes=CHECK,NOBTI2; RUN: llc -mtriple=aarch64-none-elf %s -o - | FileCheck %s --check-prefixes=CHECK,NOBTI3; RUN: llc -mtriple=aarch64-none-macho %s -o - | FileCheck %s --check-prefixes=CHECK,BTI4; RUN: llc -mtriple=aarch64-windows-msvc %s -o - | FileCheck %s --check-prefixes=CHECK,BTI5 6;; This function has internal linkage, and nothing in this translation unit7;; calls it indirectly. So it doesn't need a BTI at the start ... except that8;; it might, if at link time if the linker inserts a long-branch thunk using a9;; BLR instruction.10;;11;; For ELF targets, both Linux and bare-metal, we expect no BTI instruction at12;; the start of the function, because AAELF64 specifies that it's not needed:13;; if the linker wants to do that then it's responsible for making a 'landing14;; pad' near the target function which _does_ have a BTI, and pointing the15;; indirect call at that.16;;17;; But this is specified in AAELF64, so non-ELF targets can't rely on that18;; guarantee, and we expect LLVM to insert the BTI anyway.19define internal void @internal_linkage() "branch-target-enforcement" {20; CHECK-LABEL: internal_linkage:21; BTI: hint #3422; NOBTI-NOT: hint #3423; CHECK: ret24entry:25 ret void26}27 28;; This function has internal linkage but _is_ potentially called indirectly29;; (its address escapes from the module via external_linkage() below), so it30;; needs a BTI irrespective of target triple.31define internal void @indirectly_called() "branch-target-enforcement" {32; CHECK-LABEL: indirectly_called:33; CHECK: hint #3434; CHECK: ret35entry:36 ret void37}38 39;; This function has external linkage, so it needs a BTI in all circumstances.40define ptr @external_linkage() "branch-target-enforcement" {41; CHECK-LABEL: external_linkage:42; CHECK: hint #3443; CHECK: ret44entry:45 call void @internal_linkage()46 ret ptr @indirectly_called47}48