de393329b9
Summary: The backend has no reason to behave like a driver and should generally do as it's told (and error out if it can't) instead of trying to figure out what the API user meant. The default ABI is still derived from the arch component as a concession to backwards compatibility. API-users that previously passed an explicit CPU and a triple that was inconsistent with the CPU (e.g. mips-linux-gnu and mips64r2) may get a different ABI to what they got before. However, it's expected that there are no such users on the basis that CodeGen has been asserting that the triple is consistent with the selected ABI for several releases. API-users that were consistent or passed '' or 'generic' as the CPU will see no difference. Reviewers: sdardis, rafael Subscribers: rafael, dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D21466 llvm-svn: 273557
33 lines
977 B
LLVM
33 lines
977 B
LLVM
; RUN: llc < %s -march=mips -mcpu=mips32r2 -mattr=+micromips -relocation-model=pic | FileCheck %s
|
|
; RUN: llc < %s -march=mips -mcpu=mips32r3 -mattr=+micromips -relocation-model=pic | FileCheck %s
|
|
; RUN: llc < %s -march=mips -mcpu=mips32r6 -mattr=+micromips -relocation-model=pic | FileCheck %s
|
|
; RUN: llc < %s -march=mips -mcpu=mips64r6 -target-abi n64 -mattr=+micromips -relocation-model=pic | FileCheck %s
|
|
|
|
@us = global i16 0, align 2
|
|
|
|
define i32 @lhfunc() {
|
|
entry:
|
|
; CHECK-LABEL: lhfunc
|
|
; CHECK: lh $[[REG1:[0-9]+]], 0(${{[0-9]+}})
|
|
%0 = load i16, i16* @us, align 2
|
|
%conv = sext i16 %0 to i32
|
|
ret i32 %conv
|
|
}
|
|
|
|
define i16 @lhfunc_atomic() {
|
|
entry:
|
|
; CHECK-LABEL: lhfunc_atomic
|
|
; CHECK: lh $[[REG1:[0-9]+]], 0(${{[0-9]+}})
|
|
%0 = load atomic i16, i16* @us acquire, align 2
|
|
ret i16 %0
|
|
}
|
|
|
|
define i32 @lhufunc() {
|
|
entry:
|
|
; CHECK-LABEL: lhufunc
|
|
; CHECK: lhu $[[REG1:[0-9]+]], 0(${{[0-9]+}})
|
|
%0 = load i16, i16* @us, align 2
|
|
%conv = zext i16 %0 to i32
|
|
ret i32 %conv
|
|
}
|