38 lines · plain
1; RUN: llc < %s -relocation-model=pic -O2 -frame-pointer=all -o - | FileCheck %s2; RUN: llc < %s -relocation-model=pic -O2 -o - | FileCheck %s3 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 is6; 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 eliminated9; 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 on11; 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 be13; 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 decision16; whether to eliminate the frame pointer.17; With the fix, the "hasCalls" flag is set in the MFI for the function whenever18; a TLS access pseudo-instruction is created, so 'foo' appears to be a non-leaf19; function, and the difference in the options does not affect codegen: both20; versions will have a frame pointer.21 22; Test that there's some frame pointer usage in 'foo'...23; CHECK: foo:24; CHECK: pushq %rbp25; CHECK: movq %rsp, %rbp26; ... and the TLS library call is also present.27; CHECK: leaq x@TLSGD(%rip), %rdi28; CHECK: callq __tls_get_addr@PLT29 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 034define i32 @foo() "frame-pointer"="non-leaf" {35 %a = load i32, ptr @x, align 436 ret i32 %a37}38