From adadf887cb57f8281ec23f846a946fb59bd0a0d7 Mon Sep 17 00:00:00 2001 From: Tim Northover Date: Thu, 19 Sep 2013 11:33:53 +0000 Subject: 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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190995 91177308-0d34-0410-b5e6-96231b3b80d8 --- test/CodeGen/X86/frame-base.ll | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 test/CodeGen/X86/frame-base.ll (limited to 'test/CodeGen/X86/frame-base.ll') diff --git a/test/CodeGen/X86/frame-base.ll b/test/CodeGen/X86/frame-base.ll new file mode 100644 index 0000000000..a6bd2a51c9 --- /dev/null +++ b/test/CodeGen/X86/frame-base.ll @@ -0,0 +1,22 @@ +; 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) -- cgit v1.2.3