Fix yet-another bug I introduced into fastisel, this time handling

constant pool references that weren't getting properly rip-relative.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74689 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Chris Lattner 2009-07-02 03:14:25 +00:00
parent 0a93771e4c
commit 27598ec1e2
2 changed files with 20 additions and 1 deletions

View File

@ -1514,7 +1514,9 @@ unsigned X86FastISel::TargetMaterializeConstant(Constant *C) {
} else if (Subtarget->isPICStyleGOT()) {
OpFlag = X86II::MO_GOTOFF;
PICBase = getInstrInfo()->getGlobalBaseReg(&MF);
}
} else if (Subtarget->isPICStyleRIPRel() &&
TM.getCodeModel() == CodeModel::Small)
PICBase = X86::RIP;
}
// Create the load from the constant pool.

View File

@ -0,0 +1,17 @@
; RUN: llvm-as < %s | llc -fast-isel | grep {LCPI1_0(%rip)}
; Make sure fast isel uses rip-relative addressing when required.
target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
target triple = "x86_64-apple-darwin9.0"
define i32 @f0(double %x) nounwind {
entry:
%retval = alloca i32 ; <i32*> [#uses=2]
%x.addr = alloca double ; <double*> [#uses=2]
store double %x, double* %x.addr
%tmp = load double* %x.addr ; <double> [#uses=1]
%cmp = fcmp olt double %tmp, 8.500000e-01 ; <i1> [#uses=1]
%conv = zext i1 %cmp to i32 ; <i32> [#uses=1]
store i32 %conv, i32* %retval
%0 = load i32* %retval ; <i32> [#uses=1]
ret i32 %0
}