maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/PowerPC/fast-isel-conversion-p5.ll

131 lines
2.9 KiB
LLVM
Raw Normal View History

Change the fast-isel-abort option from bool to int to enable "levels" Summary: Currently fast-isel-abort will only abort for regular instructions, and just warn for function calls, terminators, function arguments. There is already fast-isel-abort-args but nothing for calls and terminators. This change turns the fast-isel-abort options into an integer option, so that multiple levels of strictness can be defined. This will help no being surprised when the "abort" option indeed does not abort, and enables the possibility to write test that verifies that no intrinsics are forgotten by fast-isel. Reviewers: resistor, echristo Subscribers: jfb, llvm-commits Differential Revision: http://reviews.llvm.org/D7941 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 230775
2015-02-28 02:32:11 +08:00
; RUN: llc < %s -O0 -verify-machineinstrs -fast-isel-abort=1 -mtriple=powerpc64-unknown-linux-gnu -mcpu=pwr5 | FileCheck %s --check-prefix=ELF64
Fix PR19144: Incorrect offset generated for int-to-fp conversion at -O0. When converting a signed 32-bit integer to double-precision floating point on hardware without a lfiwax instruction, we have to instead use a lfd followed by fcfid. We were erroneously offsetting the address by 4 bytes in preparation for either a lfiwax or lfiwzx when generating the lfd. This fixes that silly error. This was not caught in the test suite since the conversion tests were run with -mcpu=pwr7, which implies availability of lfiwax. I've added another test case for older hardware that checks the code we expect in the absence of lfiwax and other flavors of fcfid. There are fewer tests in this test case because we punt to DAG selection in more cases on older hardware. (We must generate complex fiddly sequences in those cases, and there is marginal benefit in duplicating that logic in fast-isel.) llvm-svn: 204155
2014-03-18 22:32:50 +08:00
; Test sitofp
Clean up function attributes on PPC fast-isel tests. llvm-svn: 243079
2015-07-24 09:07:50 +08:00
define void @sitofp_double_i32(i32 %a, double %b) nounwind {
Fix PR19144: Incorrect offset generated for int-to-fp conversion at -O0. When converting a signed 32-bit integer to double-precision floating point on hardware without a lfiwax instruction, we have to instead use a lfd followed by fcfid. We were erroneously offsetting the address by 4 bytes in preparation for either a lfiwax or lfiwzx when generating the lfd. This fixes that silly error. This was not caught in the test suite since the conversion tests were run with -mcpu=pwr7, which implies availability of lfiwax. I've added another test case for older hardware that checks the code we expect in the absence of lfiwax and other flavors of fcfid. There are fewer tests in this test case because we punt to DAG selection in more cases on older hardware. (We must generate complex fiddly sequences in those cases, and there is marginal benefit in duplicating that logic in fast-isel.) llvm-svn: 204155
2014-03-18 22:32:50 +08:00
entry:
; ELF64: sitofp_double_i32
%b.addr = alloca double, align 8
%conv = sitofp i32 %a to double
; ELF64: std {{[0-9]+}}, -[[OFFSET:[0-9]+]](1)
; ELF64: lfd {{[0-9]+}}, -[[OFFSET]](1)
; ELF64: fcfid
store double %conv, double* %b.addr, align 8
ret void
}
Clean up function attributes on PPC fast-isel tests. llvm-svn: 243079
2015-07-24 09:07:50 +08:00
define void @sitofp_double_i64(i64 %a, double %b) nounwind {
Fix PR19144: Incorrect offset generated for int-to-fp conversion at -O0. When converting a signed 32-bit integer to double-precision floating point on hardware without a lfiwax instruction, we have to instead use a lfd followed by fcfid. We were erroneously offsetting the address by 4 bytes in preparation for either a lfiwax or lfiwzx when generating the lfd. This fixes that silly error. This was not caught in the test suite since the conversion tests were run with -mcpu=pwr7, which implies availability of lfiwax. I've added another test case for older hardware that checks the code we expect in the absence of lfiwax and other flavors of fcfid. There are fewer tests in this test case because we punt to DAG selection in more cases on older hardware. (We must generate complex fiddly sequences in those cases, and there is marginal benefit in duplicating that logic in fast-isel.) llvm-svn: 204155
2014-03-18 22:32:50 +08:00
entry:
; ELF64: sitofp_double_i64
%b.addr = alloca double, align 8
%conv = sitofp i64 %a to double
; ELF64: std {{[0-9]+}}, -[[OFFSET:[0-9]+]](1)
; ELF64: lfd {{[0-9]+}}, -[[OFFSET]](1)
; ELF64: fcfid
store double %conv, double* %b.addr, align 8
ret void
}
Clean up function attributes on PPC fast-isel tests. llvm-svn: 243079
2015-07-24 09:07:50 +08:00
define void @sitofp_double_i16(i16 %a, double %b) nounwind {
Fix PR19144: Incorrect offset generated for int-to-fp conversion at -O0. When converting a signed 32-bit integer to double-precision floating point on hardware without a lfiwax instruction, we have to instead use a lfd followed by fcfid. We were erroneously offsetting the address by 4 bytes in preparation for either a lfiwax or lfiwzx when generating the lfd. This fixes that silly error. This was not caught in the test suite since the conversion tests were run with -mcpu=pwr7, which implies availability of lfiwax. I've added another test case for older hardware that checks the code we expect in the absence of lfiwax and other flavors of fcfid. There are fewer tests in this test case because we punt to DAG selection in more cases on older hardware. (We must generate complex fiddly sequences in those cases, and there is marginal benefit in duplicating that logic in fast-isel.) llvm-svn: 204155
2014-03-18 22:32:50 +08:00
entry:
; ELF64: sitofp_double_i16
%b.addr = alloca double, align 8
%conv = sitofp i16 %a to double
; ELF64: extsh
; ELF64: std {{[0-9]+}}, -[[OFFSET:[0-9]+]](1)
; ELF64: lfd {{[0-9]+}}, -[[OFFSET]](1)
; ELF64: fcfid
store double %conv, double* %b.addr, align 8
ret void
}
Clean up function attributes on PPC fast-isel tests. llvm-svn: 243079
2015-07-24 09:07:50 +08:00
define void @sitofp_double_i8(i8 %a, double %b) nounwind {
Fix PR19144: Incorrect offset generated for int-to-fp conversion at -O0. When converting a signed 32-bit integer to double-precision floating point on hardware without a lfiwax instruction, we have to instead use a lfd followed by fcfid. We were erroneously offsetting the address by 4 bytes in preparation for either a lfiwax or lfiwzx when generating the lfd. This fixes that silly error. This was not caught in the test suite since the conversion tests were run with -mcpu=pwr7, which implies availability of lfiwax. I've added another test case for older hardware that checks the code we expect in the absence of lfiwax and other flavors of fcfid. There are fewer tests in this test case because we punt to DAG selection in more cases on older hardware. (We must generate complex fiddly sequences in those cases, and there is marginal benefit in duplicating that logic in fast-isel.) llvm-svn: 204155
2014-03-18 22:32:50 +08:00
entry:
; ELF64: sitofp_double_i8
%b.addr = alloca double, align 8
%conv = sitofp i8 %a to double
; ELF64: extsb
; ELF64: std {{[0-9]+}}, -[[OFFSET:[0-9]+]](1)
; ELF64: lfd {{[0-9]+}}, -[[OFFSET]](1)
; ELF64: fcfid
store double %conv, double* %b.addr, align 8
ret void
}
; Test fptosi
Clean up function attributes on PPC fast-isel tests. llvm-svn: 243079
2015-07-24 09:07:50 +08:00
define void @fptosi_float_i32(float %a) nounwind {
Fix PR19144: Incorrect offset generated for int-to-fp conversion at -O0. When converting a signed 32-bit integer to double-precision floating point on hardware without a lfiwax instruction, we have to instead use a lfd followed by fcfid. We were erroneously offsetting the address by 4 bytes in preparation for either a lfiwax or lfiwzx when generating the lfd. This fixes that silly error. This was not caught in the test suite since the conversion tests were run with -mcpu=pwr7, which implies availability of lfiwax. I've added another test case for older hardware that checks the code we expect in the absence of lfiwax and other flavors of fcfid. There are fewer tests in this test case because we punt to DAG selection in more cases on older hardware. (We must generate complex fiddly sequences in those cases, and there is marginal benefit in duplicating that logic in fast-isel.) llvm-svn: 204155
2014-03-18 22:32:50 +08:00
entry:
; ELF64: fptosi_float_i32
%b.addr = alloca i32, align 4
%conv = fptosi float %a to i32
; ELF64: fctiwz
; ELF64: stfd
; ELF64: lwa
store i32 %conv, i32* %b.addr, align 4
ret void
}
Clean up function attributes on PPC fast-isel tests. llvm-svn: 243079
2015-07-24 09:07:50 +08:00
define void @fptosi_float_i64(float %a) nounwind {
Fix PR19144: Incorrect offset generated for int-to-fp conversion at -O0. When converting a signed 32-bit integer to double-precision floating point on hardware without a lfiwax instruction, we have to instead use a lfd followed by fcfid. We were erroneously offsetting the address by 4 bytes in preparation for either a lfiwax or lfiwzx when generating the lfd. This fixes that silly error. This was not caught in the test suite since the conversion tests were run with -mcpu=pwr7, which implies availability of lfiwax. I've added another test case for older hardware that checks the code we expect in the absence of lfiwax and other flavors of fcfid. There are fewer tests in this test case because we punt to DAG selection in more cases on older hardware. (We must generate complex fiddly sequences in those cases, and there is marginal benefit in duplicating that logic in fast-isel.) llvm-svn: 204155
2014-03-18 22:32:50 +08:00
entry:
; ELF64: fptosi_float_i64
%b.addr = alloca i64, align 4
%conv = fptosi float %a to i64
; ELF64: fctidz
; ELF64: stfd
; ELF64: ld
store i64 %conv, i64* %b.addr, align 4
ret void
}
Clean up function attributes on PPC fast-isel tests. llvm-svn: 243079
2015-07-24 09:07:50 +08:00
define void @fptosi_double_i32(double %a) nounwind {
Fix PR19144: Incorrect offset generated for int-to-fp conversion at -O0. When converting a signed 32-bit integer to double-precision floating point on hardware without a lfiwax instruction, we have to instead use a lfd followed by fcfid. We were erroneously offsetting the address by 4 bytes in preparation for either a lfiwax or lfiwzx when generating the lfd. This fixes that silly error. This was not caught in the test suite since the conversion tests were run with -mcpu=pwr7, which implies availability of lfiwax. I've added another test case for older hardware that checks the code we expect in the absence of lfiwax and other flavors of fcfid. There are fewer tests in this test case because we punt to DAG selection in more cases on older hardware. (We must generate complex fiddly sequences in those cases, and there is marginal benefit in duplicating that logic in fast-isel.) llvm-svn: 204155
2014-03-18 22:32:50 +08:00
entry:
; ELF64: fptosi_double_i32
%b.addr = alloca i32, align 8
%conv = fptosi double %a to i32
; ELF64: fctiwz
; ELF64: stfd
; ELF64: lwa
store i32 %conv, i32* %b.addr, align 8
ret void
}
Clean up function attributes on PPC fast-isel tests. llvm-svn: 243079
2015-07-24 09:07:50 +08:00
define void @fptosi_double_i64(double %a) nounwind {
Fix PR19144: Incorrect offset generated for int-to-fp conversion at -O0. When converting a signed 32-bit integer to double-precision floating point on hardware without a lfiwax instruction, we have to instead use a lfd followed by fcfid. We were erroneously offsetting the address by 4 bytes in preparation for either a lfiwax or lfiwzx when generating the lfd. This fixes that silly error. This was not caught in the test suite since the conversion tests were run with -mcpu=pwr7, which implies availability of lfiwax. I've added another test case for older hardware that checks the code we expect in the absence of lfiwax and other flavors of fcfid. There are fewer tests in this test case because we punt to DAG selection in more cases on older hardware. (We must generate complex fiddly sequences in those cases, and there is marginal benefit in duplicating that logic in fast-isel.) llvm-svn: 204155
2014-03-18 22:32:50 +08:00
entry:
; ELF64: fptosi_double_i64
%b.addr = alloca i64, align 8
%conv = fptosi double %a to i64
; ELF64: fctidz
; ELF64: stfd
; ELF64: ld
store i64 %conv, i64* %b.addr, align 8
ret void
}
; Test fptoui
Clean up function attributes on PPC fast-isel tests. llvm-svn: 243079
2015-07-24 09:07:50 +08:00
define void @fptoui_float_i32(float %a) nounwind {
Fix PR19144: Incorrect offset generated for int-to-fp conversion at -O0. When converting a signed 32-bit integer to double-precision floating point on hardware without a lfiwax instruction, we have to instead use a lfd followed by fcfid. We were erroneously offsetting the address by 4 bytes in preparation for either a lfiwax or lfiwzx when generating the lfd. This fixes that silly error. This was not caught in the test suite since the conversion tests were run with -mcpu=pwr7, which implies availability of lfiwax. I've added another test case for older hardware that checks the code we expect in the absence of lfiwax and other flavors of fcfid. There are fewer tests in this test case because we punt to DAG selection in more cases on older hardware. (We must generate complex fiddly sequences in those cases, and there is marginal benefit in duplicating that logic in fast-isel.) llvm-svn: 204155
2014-03-18 22:32:50 +08:00
entry:
; ELF64: fptoui_float_i32
%b.addr = alloca i32, align 4
%conv = fptoui float %a to i32
; ELF64: fctidz
; ELF64: stfd
; ELF64: lwz
store i32 %conv, i32* %b.addr, align 4
ret void
}
Clean up function attributes on PPC fast-isel tests. llvm-svn: 243079
2015-07-24 09:07:50 +08:00
define void @fptoui_double_i32(double %a) nounwind {
Fix PR19144: Incorrect offset generated for int-to-fp conversion at -O0. When converting a signed 32-bit integer to double-precision floating point on hardware without a lfiwax instruction, we have to instead use a lfd followed by fcfid. We were erroneously offsetting the address by 4 bytes in preparation for either a lfiwax or lfiwzx when generating the lfd. This fixes that silly error. This was not caught in the test suite since the conversion tests were run with -mcpu=pwr7, which implies availability of lfiwax. I've added another test case for older hardware that checks the code we expect in the absence of lfiwax and other flavors of fcfid. There are fewer tests in this test case because we punt to DAG selection in more cases on older hardware. (We must generate complex fiddly sequences in those cases, and there is marginal benefit in duplicating that logic in fast-isel.) llvm-svn: 204155
2014-03-18 22:32:50 +08:00
entry:
; ELF64: fptoui_double_i32
%b.addr = alloca i32, align 8
%conv = fptoui double %a to i32
; ELF64: fctidz
; ELF64: stfd
; ELF64: lwz
store i32 %conv, i32* %b.addr, align 8
ret void
}