1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-29 23:12:55 +01:00
llvm-mirror/test/CodeGen/X86/frame-base.ll
Tim Northover 89d57eb12b X86: FrameIndex addressing modes do have a base register.
When selecting the DAG (add (WrapperRIP ...), (FrameIndex ...)), X86 code had
spotted the FrameIndex possibility and was working out whether it could fold
the WrapperRIP into this.

The test for forming a %rip version is notionally whether we already have a
base or index register (%rip precludes both), but we were forgetting to account
for the register that would be inserted later to access the frame.

rdar://problem/15024520

llvm-svn: 190995
2013-09-19 11:33:53 +00:00

23 lines
686 B
LLVM

; RUN: llc -mtriple=x86_64-apple-macosx -o - %s | FileCheck %s
; The issue here was a conflict between forming a %rip-relative lea and a
; FrameIndex lea. The %rip sanity-checks didn't consider that a base register
; had been set if we'd already matched a FrameIndex, when it has in reality.
@var = global i32 0
define void @test_frame_rip_conflict() {
; CHECK-LABEL: test_frame_rip_conflict:
; CHECK: leaq _var(%rip), [[TMPADDR:%r.*]]
; CHECK: leaq {{-?[0-9]+}}(%rsp,[[TMPADDR]]),
%stackvar = alloca i32
%stackint = ptrtoint i32* %stackvar to i64
%addr = add i64 ptrtoint(i32* @var to i64), %stackint
call void @eat_i64(i64 %addr)
ret void
}
declare void @eat_i64(i64)