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/AArch64/vector-fcopysign.ll

179 lines
6.0 KiB
LLVM
Raw Normal View History

[AArch64] Enable PostRAScheduler for AArch64 generic build. Disable post-ra scheduler for perturbed tests to appease the bots and to preserve the history of the tests. http://reviews.llvm.org/D15652 llvm-svn: 256158
2015-12-21 22:43:45 +08:00
; RUN: llc < %s -mtriple aarch64-apple-darwin -asm-verbose=false -disable-post-ra | FileCheck %s
[CodeGen] Fix FCOPYSIGN legalization to account for mismatched types. We used to legalize it like it's any other binary operations. It's not, because it accepts mismatched operand types. Because of that, we used to hit various asserts and miscompiles. Specialize vector legalizations to, in the worst case, unroll, or, when possible, to just legalize the operand that needs legalization. Scalarization isn't covered, because I can't think of a target where some but not all of the 1-element vector types are to be scalarized. llvm-svn: 243924
2015-08-04 08:32:55 +08:00
target datalayout = "e-m:o-i64:64-i128:128-n32:64-S128"
;============ v1f32
; WidenVecRes same
define <1 x float> @test_copysign_v1f32_v1f32(<1 x float> %a, <1 x float> %b) #0 {
; CHECK-LABEL: test_copysign_v1f32_v1f32:
add support for -print-imm-hex for AArch64 Most immediates are printed in Aarch64InstPrinter using 'formatImm' macro, but not all of them. Implementation contains following rules: - floating point immediates are always printed as decimal - signed integer immediates are printed depends on flag settings (for negative values 'formatImm' macro prints the value as i.e -0x01 which may be convenient when imm is an address or offset) - logical immediates are always printed as hex - the 64-bit immediate for advSIMD, encoded in "a:b:c:d:e:f:g:h" is always printed as hex - the 64-bit immedaite in exception generation instructions like: brk, dcps1, dcps2, dcps3, hlt, hvc, smc, svc is always printed as hex - the rest of immediates is printed depends on availability of -print-imm-hex Signed-off-by: Maciej Gabka <maciej.gabka@arm.com> Signed-off-by: Paul Osmialowski <pawel.osmialowski@arm.com> Differential Revision: http://reviews.llvm.org/D16929 llvm-svn: 269446
2016-05-14 02:00:09 +08:00
; CHECK-NEXT: movi.2s v2, #128, lsl #24
[AArch64] Vector FCOPYSIGN supports Custom-lowering: mark it as such. There's a bunch of code in LowerFCOPYSIGN that does smart lowering, and is actually already vector-aware; let's use it instead of scalarizing! The only interesting change is that for v2f32, we previously always used use v4i32 as the integer vector type. Use v2i32 instead, and mark FCOPYSIGN as Custom. llvm-svn: 243926
2015-08-04 08:42:34 +08:00
; CHECK-NEXT: bit.8b v0, v1, v2
[CodeGen] Fix FCOPYSIGN legalization to account for mismatched types. We used to legalize it like it's any other binary operations. It's not, because it accepts mismatched operand types. Because of that, we used to hit various asserts and miscompiles. Specialize vector legalizations to, in the worst case, unroll, or, when possible, to just legalize the operand that needs legalization. Scalarization isn't covered, because I can't think of a target where some but not all of the 1-element vector types are to be scalarized. llvm-svn: 243924
2015-08-04 08:32:55 +08:00
; CHECK-NEXT: ret
%r = call <1 x float> @llvm.copysign.v1f32(<1 x float> %a, <1 x float> %b)
ret <1 x float> %r
}
; WidenVecRes mismatched
define <1 x float> @test_copysign_v1f32_v1f64(<1 x float> %a, <1 x double> %b) #0 {
; CHECK-LABEL: test_copysign_v1f32_v1f64:
; CHECK-NEXT: fcvt s1, d1
add support for -print-imm-hex for AArch64 Most immediates are printed in Aarch64InstPrinter using 'formatImm' macro, but not all of them. Implementation contains following rules: - floating point immediates are always printed as decimal - signed integer immediates are printed depends on flag settings (for negative values 'formatImm' macro prints the value as i.e -0x01 which may be convenient when imm is an address or offset) - logical immediates are always printed as hex - the 64-bit immediate for advSIMD, encoded in "a:b:c:d:e:f:g:h" is always printed as hex - the 64-bit immedaite in exception generation instructions like: brk, dcps1, dcps2, dcps3, hlt, hvc, smc, svc is always printed as hex - the rest of immediates is printed depends on availability of -print-imm-hex Signed-off-by: Maciej Gabka <maciej.gabka@arm.com> Signed-off-by: Paul Osmialowski <pawel.osmialowski@arm.com> Differential Revision: http://reviews.llvm.org/D16929 llvm-svn: 269446
2016-05-14 02:00:09 +08:00
; CHECK-NEXT: movi.4s v2, #128, lsl #24
[CodeGen] Fix FCOPYSIGN legalization to account for mismatched types. We used to legalize it like it's any other binary operations. It's not, because it accepts mismatched operand types. Because of that, we used to hit various asserts and miscompiles. Specialize vector legalizations to, in the worst case, unroll, or, when possible, to just legalize the operand that needs legalization. Scalarization isn't covered, because I can't think of a target where some but not all of the 1-element vector types are to be scalarized. llvm-svn: 243924
2015-08-04 08:32:55 +08:00
; CHECK-NEXT: bit.16b v0, v1, v2
; CHECK-NEXT: ret
%tmp0 = fptrunc <1 x double> %b to <1 x float>
%r = call <1 x float> @llvm.copysign.v1f32(<1 x float> %a, <1 x float> %tmp0)
ret <1 x float> %r
}
declare <1 x float> @llvm.copysign.v1f32(<1 x float> %a, <1 x float> %b) #0
;============ v1f64
; WidenVecOp #1
define <1 x double> @test_copysign_v1f64_v1f32(<1 x double> %a, <1 x float> %b) #0 {
; CHECK-LABEL: test_copysign_v1f64_v1f32:
; CHECK-NEXT: fcvt d1, s1
; CHECK-NEXT: movi.2d v2, #0000000000000000
; CHECK-NEXT: fneg.2d v2, v2
; CHECK-NEXT: bit.16b v0, v1, v2
; CHECK-NEXT: ret
%tmp0 = fpext <1 x float> %b to <1 x double>
%r = call <1 x double> @llvm.copysign.v1f64(<1 x double> %a, <1 x double> %tmp0)
ret <1 x double> %r
}
define <1 x double> @test_copysign_v1f64_v1f64(<1 x double> %a, <1 x double> %b) #0 {
; CHECK-LABEL: test_copysign_v1f64_v1f64:
; CHECK-NEXT: movi.2d v2, #0000000000000000
; CHECK-NEXT: fneg.2d v2, v2
; CHECK-NEXT: bit.16b v0, v1, v2
; CHECK-NEXT: ret
%r = call <1 x double> @llvm.copysign.v1f64(<1 x double> %a, <1 x double> %b)
ret <1 x double> %r
}
declare <1 x double> @llvm.copysign.v1f64(<1 x double> %a, <1 x double> %b) #0
;============ v2f32
define <2 x float> @test_copysign_v2f32_v2f32(<2 x float> %a, <2 x float> %b) #0 {
; CHECK-LABEL: test_copysign_v2f32_v2f32:
add support for -print-imm-hex for AArch64 Most immediates are printed in Aarch64InstPrinter using 'formatImm' macro, but not all of them. Implementation contains following rules: - floating point immediates are always printed as decimal - signed integer immediates are printed depends on flag settings (for negative values 'formatImm' macro prints the value as i.e -0x01 which may be convenient when imm is an address or offset) - logical immediates are always printed as hex - the 64-bit immediate for advSIMD, encoded in "a:b:c:d:e:f:g:h" is always printed as hex - the 64-bit immedaite in exception generation instructions like: brk, dcps1, dcps2, dcps3, hlt, hvc, smc, svc is always printed as hex - the rest of immediates is printed depends on availability of -print-imm-hex Signed-off-by: Maciej Gabka <maciej.gabka@arm.com> Signed-off-by: Paul Osmialowski <pawel.osmialowski@arm.com> Differential Revision: http://reviews.llvm.org/D16929 llvm-svn: 269446
2016-05-14 02:00:09 +08:00
; CHECK-NEXT: movi.2s v2, #128, lsl #24
[AArch64] Vector FCOPYSIGN supports Custom-lowering: mark it as such. There's a bunch of code in LowerFCOPYSIGN that does smart lowering, and is actually already vector-aware; let's use it instead of scalarizing! The only interesting change is that for v2f32, we previously always used use v4i32 as the integer vector type. Use v2i32 instead, and mark FCOPYSIGN as Custom. llvm-svn: 243926
2015-08-04 08:42:34 +08:00
; CHECK-NEXT: bit.8b v0, v1, v2
[CodeGen] Fix FCOPYSIGN legalization to account for mismatched types. We used to legalize it like it's any other binary operations. It's not, because it accepts mismatched operand types. Because of that, we used to hit various asserts and miscompiles. Specialize vector legalizations to, in the worst case, unroll, or, when possible, to just legalize the operand that needs legalization. Scalarization isn't covered, because I can't think of a target where some but not all of the 1-element vector types are to be scalarized. llvm-svn: 243924
2015-08-04 08:32:55 +08:00
; CHECK-NEXT: ret
%r = call <2 x float> @llvm.copysign.v2f32(<2 x float> %a, <2 x float> %b)
ret <2 x float> %r
}
define <2 x float> @test_copysign_v2f32_v2f64(<2 x float> %a, <2 x double> %b) #0 {
; CHECK-LABEL: test_copysign_v2f32_v2f64:
[AArch64] Also custom-lowering mismatched vector/f16 FCOPYSIGN. We can lower them using our cool tricks if we fpext/fptrunc the second input, like we do for f32/f64. Follow-up to r243924, r243926, and r244858. llvm-svn: 244860
2015-08-13 09:13:56 +08:00
; CHECK-NEXT: fcvtn v1.2s, v1.2d
add support for -print-imm-hex for AArch64 Most immediates are printed in Aarch64InstPrinter using 'formatImm' macro, but not all of them. Implementation contains following rules: - floating point immediates are always printed as decimal - signed integer immediates are printed depends on flag settings (for negative values 'formatImm' macro prints the value as i.e -0x01 which may be convenient when imm is an address or offset) - logical immediates are always printed as hex - the 64-bit immediate for advSIMD, encoded in "a:b:c:d:e:f:g:h" is always printed as hex - the 64-bit immedaite in exception generation instructions like: brk, dcps1, dcps2, dcps3, hlt, hvc, smc, svc is always printed as hex - the rest of immediates is printed depends on availability of -print-imm-hex Signed-off-by: Maciej Gabka <maciej.gabka@arm.com> Signed-off-by: Paul Osmialowski <pawel.osmialowski@arm.com> Differential Revision: http://reviews.llvm.org/D16929 llvm-svn: 269446
2016-05-14 02:00:09 +08:00
; CHECK-NEXT: movi.2s v2, #128, lsl #24
[AArch64] Also custom-lowering mismatched vector/f16 FCOPYSIGN. We can lower them using our cool tricks if we fpext/fptrunc the second input, like we do for f32/f64. Follow-up to r243924, r243926, and r244858. llvm-svn: 244860
2015-08-13 09:13:56 +08:00
; CHECK-NEXT: bit.8b v0, v1, v2
[CodeGen] Fix FCOPYSIGN legalization to account for mismatched types. We used to legalize it like it's any other binary operations. It's not, because it accepts mismatched operand types. Because of that, we used to hit various asserts and miscompiles. Specialize vector legalizations to, in the worst case, unroll, or, when possible, to just legalize the operand that needs legalization. Scalarization isn't covered, because I can't think of a target where some but not all of the 1-element vector types are to be scalarized. llvm-svn: 243924
2015-08-04 08:32:55 +08:00
; CHECK-NEXT: ret
%tmp0 = fptrunc <2 x double> %b to <2 x float>
%r = call <2 x float> @llvm.copysign.v2f32(<2 x float> %a, <2 x float> %tmp0)
ret <2 x float> %r
}
declare <2 x float> @llvm.copysign.v2f32(<2 x float> %a, <2 x float> %b) #0
;============ v4f32
define <4 x float> @test_copysign_v4f32_v4f32(<4 x float> %a, <4 x float> %b) #0 {
; CHECK-LABEL: test_copysign_v4f32_v4f32:
add support for -print-imm-hex for AArch64 Most immediates are printed in Aarch64InstPrinter using 'formatImm' macro, but not all of them. Implementation contains following rules: - floating point immediates are always printed as decimal - signed integer immediates are printed depends on flag settings (for negative values 'formatImm' macro prints the value as i.e -0x01 which may be convenient when imm is an address or offset) - logical immediates are always printed as hex - the 64-bit immediate for advSIMD, encoded in "a:b:c:d:e:f:g:h" is always printed as hex - the 64-bit immedaite in exception generation instructions like: brk, dcps1, dcps2, dcps3, hlt, hvc, smc, svc is always printed as hex - the rest of immediates is printed depends on availability of -print-imm-hex Signed-off-by: Maciej Gabka <maciej.gabka@arm.com> Signed-off-by: Paul Osmialowski <pawel.osmialowski@arm.com> Differential Revision: http://reviews.llvm.org/D16929 llvm-svn: 269446
2016-05-14 02:00:09 +08:00
; CHECK-NEXT: movi.4s v2, #128, lsl #24
[AArch64] Vector FCOPYSIGN supports Custom-lowering: mark it as such. There's a bunch of code in LowerFCOPYSIGN that does smart lowering, and is actually already vector-aware; let's use it instead of scalarizing! The only interesting change is that for v2f32, we previously always used use v4i32 as the integer vector type. Use v2i32 instead, and mark FCOPYSIGN as Custom. llvm-svn: 243926
2015-08-04 08:42:34 +08:00
; CHECK-NEXT: bit.16b v0, v1, v2
[CodeGen] Fix FCOPYSIGN legalization to account for mismatched types. We used to legalize it like it's any other binary operations. It's not, because it accepts mismatched operand types. Because of that, we used to hit various asserts and miscompiles. Specialize vector legalizations to, in the worst case, unroll, or, when possible, to just legalize the operand that needs legalization. Scalarization isn't covered, because I can't think of a target where some but not all of the 1-element vector types are to be scalarized. llvm-svn: 243924
2015-08-04 08:32:55 +08:00
; CHECK-NEXT: ret
%r = call <4 x float> @llvm.copysign.v4f32(<4 x float> %a, <4 x float> %b)
ret <4 x float> %r
}
; SplitVecOp #1
define <4 x float> @test_copysign_v4f32_v4f64(<4 x float> %a, <4 x double> %b) #0 {
; CHECK-LABEL: test_copysign_v4f32_v4f64:
; CHECK-NEXT: mov s3, v0[1]
MachineScheduler: Fully compare top/bottom candidates In bidirectional scheduling this gives more stable results than just comparing the "reason" fields of the top/bottom node because the reason field may be higher depending on what other nodes are in the queue. Differential Revision: http://reviews.llvm.org/D19401 llvm-svn: 273755
2016-06-25 08:23:00 +08:00
; CHECK-NEXT: movi.4s v4, #128, lsl #24
; CHECK-NEXT: fcvt s5, d1
[CodeGen] Fix FCOPYSIGN legalization to account for mismatched types. We used to legalize it like it's any other binary operations. It's not, because it accepts mismatched operand types. Because of that, we used to hit various asserts and miscompiles. Specialize vector legalizations to, in the worst case, unroll, or, when possible, to just legalize the operand that needs legalization. Scalarization isn't covered, because I can't think of a target where some but not all of the 1-element vector types are to be scalarized. llvm-svn: 243924
2015-08-04 08:32:55 +08:00
; CHECK-NEXT: mov s6, v0[2]
; CHECK-NEXT: mov s7, v0[3]
MachineScheduler: Fully compare top/bottom candidates In bidirectional scheduling this gives more stable results than just comparing the "reason" fields of the top/bottom node because the reason field may be higher depending on what other nodes are in the queue. Differential Revision: http://reviews.llvm.org/D19401 llvm-svn: 273755
2016-06-25 08:23:00 +08:00
; CHECK-NEXT: bit.16b v0, v5, v4
; CHECK-NEXT: fcvt s5, d2
; CHECK-NEXT: bit.16b v6, v5, v4
; CHECK-NEXT: mov d1, v1[1]
; CHECK-NEXT: fcvt s1, d1
; CHECK-NEXT: bit.16b v3, v1, v4
[CodeGen] Fix FCOPYSIGN legalization to account for mismatched types. We used to legalize it like it's any other binary operations. It's not, because it accepts mismatched operand types. Because of that, we used to hit various asserts and miscompiles. Specialize vector legalizations to, in the worst case, unroll, or, when possible, to just legalize the operand that needs legalization. Scalarization isn't covered, because I can't think of a target where some but not all of the 1-element vector types are to be scalarized. llvm-svn: 243924
2015-08-04 08:32:55 +08:00
; CHECK-NEXT: mov d1, v2[1]
; CHECK-NEXT: fcvt s1, d1
[AArch64][TableGen] Skip tied result operands for InstAlias Summary: This patch fixes an issue so that the right alias is printed when the instruction has tied operands. It checks the number of operands in the resulting instruction as opposed to the alias, and then skips over tied operands that should not be printed in the alias. This allows to generate the preferred assembly syntax for the AArch64 'ins' instruction, which should always be displayed as 'mov' according to the ARM Architecture Reference Manual. Several unit tests have changed as a result, but only to reflect the preferred disassembly. Some other InstAlias patterns (movk/bic/orr) needed a slight adjustment to stop them becoming the default and breaking other unit tests. Please note that the patch is mostly the same as https://reviews.llvm.org/D29219 which was reverted because of an issue found when running TableGen with the Address Sanitizer. That issue has been addressed in this iteration of the patch. Reviewers: rengolin, stoklund, huntergr, SjoerdMeijer, rovka Reviewed By: rengolin, SjoerdMeijer Subscribers: fhahn, aemerson, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D40030 llvm-svn: 318650
2017-11-20 22:36:40 +08:00
; CHECK-NEXT: mov.s v0[1], v3[0]
; CHECK-NEXT: mov.s v0[2], v6[0]
MachineScheduler: Fully compare top/bottom candidates In bidirectional scheduling this gives more stable results than just comparing the "reason" fields of the top/bottom node because the reason field may be higher depending on what other nodes are in the queue. Differential Revision: http://reviews.llvm.org/D19401 llvm-svn: 273755
2016-06-25 08:23:00 +08:00
; CHECK-NEXT: bit.16b v7, v1, v4
[AArch64][TableGen] Skip tied result operands for InstAlias Summary: This patch fixes an issue so that the right alias is printed when the instruction has tied operands. It checks the number of operands in the resulting instruction as opposed to the alias, and then skips over tied operands that should not be printed in the alias. This allows to generate the preferred assembly syntax for the AArch64 'ins' instruction, which should always be displayed as 'mov' according to the ARM Architecture Reference Manual. Several unit tests have changed as a result, but only to reflect the preferred disassembly. Some other InstAlias patterns (movk/bic/orr) needed a slight adjustment to stop them becoming the default and breaking other unit tests. Please note that the patch is mostly the same as https://reviews.llvm.org/D29219 which was reverted because of an issue found when running TableGen with the Address Sanitizer. That issue has been addressed in this iteration of the patch. Reviewers: rengolin, stoklund, huntergr, SjoerdMeijer, rovka Reviewed By: rengolin, SjoerdMeijer Subscribers: fhahn, aemerson, javed.absar, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D40030 llvm-svn: 318650
2017-11-20 22:36:40 +08:00
; CHECK-NEXT: mov.s v0[3], v7[0]
[CodeGen] Fix FCOPYSIGN legalization to account for mismatched types. We used to legalize it like it's any other binary operations. It's not, because it accepts mismatched operand types. Because of that, we used to hit various asserts and miscompiles. Specialize vector legalizations to, in the worst case, unroll, or, when possible, to just legalize the operand that needs legalization. Scalarization isn't covered, because I can't think of a target where some but not all of the 1-element vector types are to be scalarized. llvm-svn: 243924
2015-08-04 08:32:55 +08:00
; CHECK-NEXT: ret
%tmp0 = fptrunc <4 x double> %b to <4 x float>
%r = call <4 x float> @llvm.copysign.v4f32(<4 x float> %a, <4 x float> %tmp0)
ret <4 x float> %r
}
declare <4 x float> @llvm.copysign.v4f32(<4 x float> %a, <4 x float> %b) #0
;============ v2f64
define <2 x double> @test_copysign_v2f64_v232(<2 x double> %a, <2 x float> %b) #0 {
; CHECK-LABEL: test_copysign_v2f64_v232:
[AArch64] Also custom-lowering mismatched vector/f16 FCOPYSIGN. We can lower them using our cool tricks if we fpext/fptrunc the second input, like we do for f32/f64. Follow-up to r243924, r243926, and r244858. llvm-svn: 244860
2015-08-13 09:13:56 +08:00
; CHECK-NEXT: movi.2d v2, #0000000000000000
; CHECK-NEXT: fneg.2d v2, v2
; CHECK-NEXT: fcvtl v1.2d, v1.2s
; CHECK-NEXT: bit.16b v0, v1, v2
[CodeGen] Fix FCOPYSIGN legalization to account for mismatched types. We used to legalize it like it's any other binary operations. It's not, because it accepts mismatched operand types. Because of that, we used to hit various asserts and miscompiles. Specialize vector legalizations to, in the worst case, unroll, or, when possible, to just legalize the operand that needs legalization. Scalarization isn't covered, because I can't think of a target where some but not all of the 1-element vector types are to be scalarized. llvm-svn: 243924
2015-08-04 08:32:55 +08:00
; CHECK-NEXT: ret
%tmp0 = fpext <2 x float> %b to <2 x double>
%r = call <2 x double> @llvm.copysign.v2f64(<2 x double> %a, <2 x double> %tmp0)
ret <2 x double> %r
}
define <2 x double> @test_copysign_v2f64_v2f64(<2 x double> %a, <2 x double> %b) #0 {
; CHECK-LABEL: test_copysign_v2f64_v2f64:
[AArch64] Vector FCOPYSIGN supports Custom-lowering: mark it as such. There's a bunch of code in LowerFCOPYSIGN that does smart lowering, and is actually already vector-aware; let's use it instead of scalarizing! The only interesting change is that for v2f32, we previously always used use v4i32 as the integer vector type. Use v2i32 instead, and mark FCOPYSIGN as Custom. llvm-svn: 243926
2015-08-04 08:42:34 +08:00
; CHECK-NEXT: movi.2d v2, #0000000000000000
; CHECK-NEXT: fneg.2d v2, v2
; CHECK-NEXT: bit.16b v0, v1, v2
[CodeGen] Fix FCOPYSIGN legalization to account for mismatched types. We used to legalize it like it's any other binary operations. It's not, because it accepts mismatched operand types. Because of that, we used to hit various asserts and miscompiles. Specialize vector legalizations to, in the worst case, unroll, or, when possible, to just legalize the operand that needs legalization. Scalarization isn't covered, because I can't think of a target where some but not all of the 1-element vector types are to be scalarized. llvm-svn: 243924
2015-08-04 08:32:55 +08:00
; CHECK-NEXT: ret
%r = call <2 x double> @llvm.copysign.v2f64(<2 x double> %a, <2 x double> %b)
ret <2 x double> %r
}
declare <2 x double> @llvm.copysign.v2f64(<2 x double> %a, <2 x double> %b) #0
;============ v4f64
; SplitVecRes mismatched
define <4 x double> @test_copysign_v4f64_v4f32(<4 x double> %a, <4 x float> %b) #0 {
; CHECK-LABEL: test_copysign_v4f64_v4f32:
[AArch64] Also custom-lowering mismatched vector/f16 FCOPYSIGN. We can lower them using our cool tricks if we fpext/fptrunc the second input, like we do for f32/f64. Follow-up to r243924, r243926, and r244858. llvm-svn: 244860
2015-08-13 09:13:56 +08:00
; CHECK-NEXT: movi.2d v3, #0000000000000000
; CHECK-NEXT: fcvtl2 v4.2d, v2.4s
; CHECK-NEXT: fcvtl v2.2d, v2.2s
; CHECK-NEXT: fneg.2d v3, v3
; CHECK-NEXT: bit.16b v1, v4, v3
; CHECK-NEXT: bit.16b v0, v2, v3
[CodeGen] Fix FCOPYSIGN legalization to account for mismatched types. We used to legalize it like it's any other binary operations. It's not, because it accepts mismatched operand types. Because of that, we used to hit various asserts and miscompiles. Specialize vector legalizations to, in the worst case, unroll, or, when possible, to just legalize the operand that needs legalization. Scalarization isn't covered, because I can't think of a target where some but not all of the 1-element vector types are to be scalarized. llvm-svn: 243924
2015-08-04 08:32:55 +08:00
; CHECK-NEXT: ret
%tmp0 = fpext <4 x float> %b to <4 x double>
%r = call <4 x double> @llvm.copysign.v4f64(<4 x double> %a, <4 x double> %tmp0)
ret <4 x double> %r
}
; SplitVecRes same
define <4 x double> @test_copysign_v4f64_v4f64(<4 x double> %a, <4 x double> %b) #0 {
; CHECK-LABEL: test_copysign_v4f64_v4f64:
[AArch64] Vector FCOPYSIGN supports Custom-lowering: mark it as such. There's a bunch of code in LowerFCOPYSIGN that does smart lowering, and is actually already vector-aware; let's use it instead of scalarizing! The only interesting change is that for v2f32, we previously always used use v4i32 as the integer vector type. Use v2i32 instead, and mark FCOPYSIGN as Custom. llvm-svn: 243926
2015-08-04 08:42:34 +08:00
; CHECK-NEXT: movi.2d v4, #0000000000000000
; CHECK-NEXT: fneg.2d v4, v4
; CHECK-NEXT: bit.16b v0, v2, v4
; CHECK-NEXT: bit.16b v1, v3, v4
[CodeGen] Fix FCOPYSIGN legalization to account for mismatched types. We used to legalize it like it's any other binary operations. It's not, because it accepts mismatched operand types. Because of that, we used to hit various asserts and miscompiles. Specialize vector legalizations to, in the worst case, unroll, or, when possible, to just legalize the operand that needs legalization. Scalarization isn't covered, because I can't think of a target where some but not all of the 1-element vector types are to be scalarized. llvm-svn: 243924
2015-08-04 08:32:55 +08:00
; CHECK-NEXT: ret
%r = call <4 x double> @llvm.copysign.v4f64(<4 x double> %a, <4 x double> %b)
ret <4 x double> %r
}
declare <4 x double> @llvm.copysign.v4f64(<4 x double> %a, <4 x double> %b) #0
attributes #0 = { nounwind }