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