1; RUN: llc < %s -relocation-model=pic -O2 -disable-fp-elim -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 "no-frame-pointer-elim-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
30target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
31target triple = "x86_64-unknown-linux-gnu"
32
33@x = thread_local global i32 0
34define i32 @foo() "no-frame-pointer-elim-non-leaf" {
35  %a = load i32* @x, align 4
36  ret i32 %a
37}
38