llvm/test/CodeGen/X86/tls-addr-non-leaf-function.ll

   1 ; RUN: llc < %s -relocation-model=pic -O2 -frame-pointer=all -o - | FileCheck %s
   2 ; RUN: llc < %s -relocation-model=pic -O2 -o - | FileCheck %s
   3
   4 ; This test runs twice with different options regarding the frame pointer:
   5 ; first the elimination is disabled, then it is enabled. The disabled case is
   6 ; the "control group".
   7 ; The function 'foo' below is marked with the "frame-pointer"="non-leaf"
   8 ; attribute which dictates that the frame pointer should not be eliminated
   9 ; unless the function is a leaf (i.e. it doesn't call any other function).
  10 ; Now, 'foo' is not a leaf function, because it performs a TLS access which on
  11 ; X86 ELF in PIC mode is expanded as a library call.
  12 ; This call is represented with a pseudo-instruction which doesn't appear to be
  13 ; a call when inspected by the analysis passes (it doesn't have the "isCall"
  14 ; flag), and the ISel lowering code creating the pseudo was not informing the
  15 ; MachineFrameInfo that the function contained calls. This affected the decision
  16 ; whether to eliminate the frame pointer.
  17 ; With the fix, the "hasCalls" flag is set in the MFI for the function whenever
  18 ; a TLS access pseudo-instruction is created, so 'foo' appears to be a non-leaf
  19 ; function, and the difference in the options does not affect codegen: both
  20 ; versions will have a frame pointer.
  21
  22 ; Test that there's some frame pointer usage in 'foo'...
  23 ; CHECK: foo:
  24 ; CHECK: pushq %rbp
  25 ; CHECK: movq %rsp, %rbp
  26 ; ... and the TLS library call is also present.
  27 ; CHECK: leaq x@TLSGD(%rip), %rdi
  28 ; CHECK: callq __tls_get_addr@PLT
  29
  30 target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
  31 target triple = "x86_64-unknown-linux-gnu"
  32
  33 @x = thread_local global i32 0
  34 define i32 @foo() "frame-pointer"="non-leaf" {
  35   %a = load i32, ptr @x, align 4
  36   ret i32 %a
  37 }