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/X86/vec_fabs.ll

61 lines
1.7 KiB
LLVM
Raw Normal View History

fix for PR20354 - Miscompile of fabs due to vectorization This is intended to be the minimal change needed to fix PR20354 ( http://llvm.org/bugs/show_bug.cgi?id=20354 ). The check for a vector operation was wrong; we need to check that the fabs itself is not a vector operation. This patch will not generate the optimal code. A constant pool load and 'and' op will be generated instead of just returning a value that we can calculate in advance (as we do for the scalar case). I've put a 'TODO' comment for that here and expect to have that patch ready soon. There is a very similar optimization that we can do in visitFNEG, so I've put another 'TODO' there and expect to have another patch for that too. llvm-svn: 214670
2014-08-04 06:48:23 +08:00
; RUN: llc < %s -march=x86 -mattr=+avx | FileCheck %s
Add support for lowering FABS of vector types. llvm-svn: 163461
2012-09-08 15:31:51 +08:00
define <2 x double> @fabs_v2f64(<2 x double> %p)
{
fix for PR20354 - Miscompile of fabs due to vectorization This is intended to be the minimal change needed to fix PR20354 ( http://llvm.org/bugs/show_bug.cgi?id=20354 ). The check for a vector operation was wrong; we need to check that the fabs itself is not a vector operation. This patch will not generate the optimal code. A constant pool load and 'and' op will be generated instead of just returning a value that we can calculate in advance (as we do for the scalar case). I've put a 'TODO' comment for that here and expect to have that patch ready soon. There is a very similar optimization that we can do in visitFNEG, so I've put another 'TODO' there and expect to have another patch for that too. llvm-svn: 214670
2014-08-04 06:48:23 +08:00
; CHECK-LABEL: fabs_v2f64
Add support for lowering FABS of vector types. llvm-svn: 163461
2012-09-08 15:31:51 +08:00
; CHECK: vandps
%t = call <2 x double> @llvm.fabs.v2f64(<2 x double> %p)
ret <2 x double> %t
}
declare <2 x double> @llvm.fabs.v2f64(<2 x double> %p)
define <4 x float> @fabs_v4f32(<4 x float> %p)
{
fix for PR20354 - Miscompile of fabs due to vectorization This is intended to be the minimal change needed to fix PR20354 ( http://llvm.org/bugs/show_bug.cgi?id=20354 ). The check for a vector operation was wrong; we need to check that the fabs itself is not a vector operation. This patch will not generate the optimal code. A constant pool load and 'and' op will be generated instead of just returning a value that we can calculate in advance (as we do for the scalar case). I've put a 'TODO' comment for that here and expect to have that patch ready soon. There is a very similar optimization that we can do in visitFNEG, so I've put another 'TODO' there and expect to have another patch for that too. llvm-svn: 214670
2014-08-04 06:48:23 +08:00
; CHECK-LABEL: fabs_v4f32
Add support for lowering FABS of vector types. llvm-svn: 163461
2012-09-08 15:31:51 +08:00
; CHECK: vandps
%t = call <4 x float> @llvm.fabs.v4f32(<4 x float> %p)
ret <4 x float> %t
}
declare <4 x float> @llvm.fabs.v4f32(<4 x float> %p)
define <4 x double> @fabs_v4f64(<4 x double> %p)
{
fix for PR20354 - Miscompile of fabs due to vectorization This is intended to be the minimal change needed to fix PR20354 ( http://llvm.org/bugs/show_bug.cgi?id=20354 ). The check for a vector operation was wrong; we need to check that the fabs itself is not a vector operation. This patch will not generate the optimal code. A constant pool load and 'and' op will be generated instead of just returning a value that we can calculate in advance (as we do for the scalar case). I've put a 'TODO' comment for that here and expect to have that patch ready soon. There is a very similar optimization that we can do in visitFNEG, so I've put another 'TODO' there and expect to have another patch for that too. llvm-svn: 214670
2014-08-04 06:48:23 +08:00
; CHECK-LABEL: fabs_v4f64
Add support for lowering FABS of vector types. llvm-svn: 163461
2012-09-08 15:31:51 +08:00
; CHECK: vandps
%t = call <4 x double> @llvm.fabs.v4f64(<4 x double> %p)
ret <4 x double> %t
}
declare <4 x double> @llvm.fabs.v4f64(<4 x double> %p)
define <8 x float> @fabs_v8f32(<8 x float> %p)
{
fix for PR20354 - Miscompile of fabs due to vectorization This is intended to be the minimal change needed to fix PR20354 ( http://llvm.org/bugs/show_bug.cgi?id=20354 ). The check for a vector operation was wrong; we need to check that the fabs itself is not a vector operation. This patch will not generate the optimal code. A constant pool load and 'and' op will be generated instead of just returning a value that we can calculate in advance (as we do for the scalar case). I've put a 'TODO' comment for that here and expect to have that patch ready soon. There is a very similar optimization that we can do in visitFNEG, so I've put another 'TODO' there and expect to have another patch for that too. llvm-svn: 214670
2014-08-04 06:48:23 +08:00
; CHECK-LABEL: fabs_v8f32
Add support for lowering FABS of vector types. llvm-svn: 163461
2012-09-08 15:31:51 +08:00
; CHECK: vandps
%t = call <8 x float> @llvm.fabs.v8f32(<8 x float> %p)
ret <8 x float> %t
}
declare <8 x float> @llvm.fabs.v8f32(<8 x float> %p)
fix for PR20354 - Miscompile of fabs due to vectorization This is intended to be the minimal change needed to fix PR20354 ( http://llvm.org/bugs/show_bug.cgi?id=20354 ). The check for a vector operation was wrong; we need to check that the fabs itself is not a vector operation. This patch will not generate the optimal code. A constant pool load and 'and' op will be generated instead of just returning a value that we can calculate in advance (as we do for the scalar case). I've put a 'TODO' comment for that here and expect to have that patch ready soon. There is a very similar optimization that we can do in visitFNEG, so I've put another 'TODO' there and expect to have another patch for that too. llvm-svn: 214670
2014-08-04 06:48:23 +08:00
; PR20354: when generating code for a vector fabs op,
; make sure the correct mask is used for all vector elements.
; CHECK-LABEL: LCPI4_0
; CHECK: .long 2147483648
; CHECK: .long 2147483648
; CHECK-LABEL: LCPI4_1
; CHECK: .long 2147483647
; CHECK: .long 2147483647
; CHECK-LABEL: fabs_v2f32_1
Account for possible leading '.' in label string. llvm-svn: 214674
2014-08-04 07:20:16 +08:00
; CHECK: vmovdqa {{.*}}LCPI4_0, %xmm0
; CHECK: vpand {{.*}}LCPI4_1, %xmm0, %xmm0
fix for PR20354 - Miscompile of fabs due to vectorization This is intended to be the minimal change needed to fix PR20354 ( http://llvm.org/bugs/show_bug.cgi?id=20354 ). The check for a vector operation was wrong; we need to check that the fabs itself is not a vector operation. This patch will not generate the optimal code. A constant pool load and 'and' op will be generated instead of just returning a value that we can calculate in advance (as we do for the scalar case). I've put a 'TODO' comment for that here and expect to have that patch ready soon. There is a very similar optimization that we can do in visitFNEG, so I've put another 'TODO' there and expect to have another patch for that too. llvm-svn: 214670
2014-08-04 06:48:23 +08:00
; CHECK: vmovd %xmm0, %eax
; CHECK: vpextrd $1, %xmm0, %edx
define i64 @fabs_v2f32_1() {
%highbits = bitcast i64 9223372039002259456 to <2 x float> ; 0x8000_0000_8000_0000
%fabs = call <2 x float> @llvm.fabs.v2f32(<2 x float> %highbits)
%ret = bitcast <2 x float> %fabs to i64
ret i64 %ret
}
declare <2 x float> @llvm.fabs.v2f32(<2 x float> %p)