mirror of
https://github.com/c64scene-ar/llvm-6502.git
synced 2024-06-30 23:30:28 +00:00
adadf887cb
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
23 lines
686 B
LLVM
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)
|