1 # This reproduces a bug with shrink wrapping when trying to move
2 # push-pops where restores were not validated to be POPs (and could be
3 # a regular load, which violated our assumptions). Check that we
4 # identify those cases.
6 # REQUIRES: system-linux
8 # RUN: llvm-mc -filetype=obj -triple x86_64-unknown-unknown \
10 # RUN: link_fdata %s %t.o %t.fdata
11 # Delete our BB symbols so BOLT doesn't mark them as entry points
12 # RUN: llvm-strip --strip-unneeded %t.o
13 # RUN: %clang %cflags -no-pie %t.o -o %t.exe -Wl,-q
15 # RUN: llvm-bolt %t.exe --relocs=1 --frame-opt=all --print-finalized \
16 # RUN: --print-only=main --data %t.fdata -o %t.out | FileCheck %s
20 # CHECK: BOLT-INFO: Shrink wrapping moved 1 spills inserting load/stores and 0 spills inserting push/pops
27 # FDATA: 0 [unknown] 0 1 main 0 0 510
30 pushq
%rbx
# We save rbx here, but there is an
31 # opportunity to move it to .LBB2
36 # FDATA: 1 main #.J1# 1 main #.BB2# 0 10
37 # FDATA: 1 main #.J1# 1 main #.BBend# 0 500
39 movq $
2, %rbx
# Use rbx in a cold block
45 # Avoid making the actual call here to allow push-pop mode to operate
46 # without fear of an unknown function that may require aligned stack
50 mov
-0x08(%rbp
), %rbx
# Original restore is here. Instead of a pop
51 # we use a load to reproduce gcc behavior while
52 # using leave in epilogue. Ordinarily it would
53 # addq $0x18, %rsp followed by pop %rbx
60 mystring
: .asciz "0 is rbx mod 10 contents in decimal\n"