1*9880d681SAndroid Build Coastguard Worker; RUN: llc -mtriple=x86_64-apple-macosx -o - %s | FileCheck %s 2*9880d681SAndroid Build Coastguard Worker 3*9880d681SAndroid Build Coastguard Worker; The issue here was a conflict between forming a %rip-relative lea and a 4*9880d681SAndroid Build Coastguard Worker; FrameIndex lea. The %rip sanity-checks didn't consider that a base register 5*9880d681SAndroid Build Coastguard Worker; had been set if we'd already matched a FrameIndex, when it has in reality. 6*9880d681SAndroid Build Coastguard Worker 7*9880d681SAndroid Build Coastguard Worker@var = global i32 0 8*9880d681SAndroid Build Coastguard Worker 9*9880d681SAndroid Build Coastguard Workerdefine void @test_frame_rip_conflict() { 10*9880d681SAndroid Build Coastguard Worker; CHECK-LABEL: test_frame_rip_conflict: 11*9880d681SAndroid Build Coastguard Worker; CHECK: leaq _var(%rip), [[TMPADDR:%r.*]] 12*9880d681SAndroid Build Coastguard Worker; CHECK: leaq {{-?[0-9]+}}(%rsp,[[TMPADDR]]), 13*9880d681SAndroid Build Coastguard Worker %stackvar = alloca i32 14*9880d681SAndroid Build Coastguard Worker 15*9880d681SAndroid Build Coastguard Worker %stackint = ptrtoint i32* %stackvar to i64 16*9880d681SAndroid Build Coastguard Worker %addr = add i64 ptrtoint(i32* @var to i64), %stackint 17*9880d681SAndroid Build Coastguard Worker 18*9880d681SAndroid Build Coastguard Worker call void @eat_i64(i64 %addr) 19*9880d681SAndroid Build Coastguard Worker ret void 20*9880d681SAndroid Build Coastguard Worker} 21*9880d681SAndroid Build Coastguard Worker 22*9880d681SAndroid Build Coastguard Workerdeclare void @eat_i64(i64) 23