RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 03:02:36 +01:00
Code Issues Projects Releases Wiki Activity
fca643847d
llvm-mirror/test/CodeGen/RISCV/copysign-casts.ll

531 lines
16 KiB
LLVM
Raw Normal View History

[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
2019-11-26 15:24:59 +01:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc -mtriple=riscv32 -verify-machineinstrs < %s \
; RUN: | FileCheck %s -check-prefix=RV32I
; RUN: llc -mtriple=riscv64 -verify-machineinstrs < %s \
; RUN: | FileCheck %s -check-prefix=RV64I
[LegalizeTypes][RISCV] Soften FCOPYSIGN operand Summary: Adds support for softening FCOPYSIGN operands. Adds RISC-V tests that exercise the new softening code. Reviewers: asb, lenary, efriedma Reviewed By: efriedma Tags: #llvm Differential Revision: https://reviews.llvm.org/D70679
2019-11-24 16:23:29 +01:00
; RUN: llc -mtriple=riscv32 -verify-machineinstrs -mattr=+f \
; RUN: -target-abi ilp32f < %s | FileCheck %s -check-prefix=RV32IF
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
2019-11-26 15:24:59 +01:00
; RUN: llc -mtriple=riscv32 -verify-machineinstrs -mattr=+f -mattr=+d \
; RUN: -target-abi ilp32d < %s | FileCheck %s -check-prefix=RV32IFD
; RUN: llc -mtriple=riscv64 -verify-machineinstrs -mattr=+f -mattr=+d \
; RUN: -target-abi lp64d < %s | FileCheck %s -check-prefix=RV64IFD
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RUN: llc -mtriple=riscv32 -verify-machineinstrs -mattr=+f \
; RUN: -mattr=+experimental-zfh -target-abi ilp32f < %s \
; RUN: | FileCheck %s -check-prefix=RV32IFZFH
; RUN: llc -mtriple=riscv32 -verify-machineinstrs -mattr=+f -mattr=+d \
; RUN: -mattr=+experimental-zfh -target-abi ilp32d < %s \
; RUN: | FileCheck %s -check-prefix=RV32IFDZFH
; RUN: llc -mtriple=riscv64 -verify-machineinstrs -mattr=+f -mattr=+d \
; RUN: -mattr=+experimental-zfh -target-abi lp64d < %s \
; RUN: | FileCheck %s -check-prefix=RV64IFDZFH
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
2019-11-26 15:24:59 +01:00
; Test fcopysign scenarios where the sign argument is casted to the type of the
; magnitude argument. Those casts can be folded away by the DAGCombiner.
declare double @llvm.copysign.f64(double, double)
declare float @llvm.copysign.f32(float, float)
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
declare half @llvm.copysign.f16(half, half)
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
2019-11-26 15:24:59 +01:00
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
define double @fold_promote_d_s(double %a, float %b) nounwind {
; RV32I-LABEL: fold_promote_d_s:
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
2019-11-26 15:24:59 +01:00
; RV32I: # %bb.0:
; RV32I-NEXT: lui a3, 524288
; RV32I-NEXT: and a2, a2, a3
; RV32I-NEXT: addi a3, a3, -1
; RV32I-NEXT: and a1, a1, a3
; RV32I-NEXT: or a1, a1, a2
; RV32I-NEXT: ret
;
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV64I-LABEL: fold_promote_d_s:
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
2019-11-26 15:24:59 +01:00
; RV64I: # %bb.0:
; RV64I-NEXT: addi a2, zero, -1
[RISCV] Improve 64-bit integer materialization for some cases. This adds a new integer materialization strategy mainly targeted at 64-bit constants like 0xffffffff where there are 32 or more trailing ones with leading zeros. We can materialize these by using an addi -1 and srli to restore the leading zeros. This matches what gcc does. I haven't limited to just these cases though. The implementation here takes the constant, shifts out all the leading zeros and shifts ones into the LSBs, creates the new sequence, adds an srli, and checks if this is shorter than our original strategy. I've separated the recursive portion into a standalone function so I could append the new strategy outside of the recursion. Since external users are no longer using the recursive function, I've cleaned up the external interface to return the sequence instead of taking a vector by reference. Reviewed By: asb Differential Revision: https://reviews.llvm.org/D98821
2021-04-01 17:51:28 +02:00
; RV64I-NEXT: srli a2, a2, 1
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
2019-11-26 15:24:59 +01:00
; RV64I-NEXT: and a0, a0, a2
[RISCV] Add implementation of targetShrinkDemandedConstant to optimize AND immediates. SimplifyDemandedBits can remove set bits from immediates from instructions like AND/OR/XOR. This can prevent them from being efficiently codegened on RISCV. This adds an initial version that tries to keep or form 12 bit sign extended immediates for AND operations to enable use of ANDI. If that doesn't work we'll try to create a 32 bit sign extended immediate to use LUI+ADDIW. More optimizations are possible for different size immediates or different operations. But this is a good starting point that already has test coverage. Reviewed By: frasercrmck Differential Revision: https://reviews.llvm.org/D94628
2021-01-15 19:54:26 +01:00
; RV64I-NEXT: lui a2, 524288
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
2019-11-26 15:24:59 +01:00
; RV64I-NEXT: and a1, a1, a2
; RV64I-NEXT: slli a1, a1, 32
; RV64I-NEXT: or a0, a0, a1
; RV64I-NEXT: ret
;
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV32IF-LABEL: fold_promote_d_s:
[LegalizeTypes][RISCV] Soften FCOPYSIGN operand Summary: Adds support for softening FCOPYSIGN operands. Adds RISC-V tests that exercise the new softening code. Reviewers: asb, lenary, efriedma Reviewed By: efriedma Tags: #llvm Differential Revision: https://reviews.llvm.org/D70679
2019-11-24 16:23:29 +01:00
; RV32IF: # %bb.0:
; RV32IF-NEXT: fmv.x.w a2, fa0
; RV32IF-NEXT: lui a3, 524288
; RV32IF-NEXT: and a2, a2, a3
; RV32IF-NEXT: addi a3, a3, -1
; RV32IF-NEXT: and a1, a1, a3
; RV32IF-NEXT: or a1, a1, a2
; RV32IF-NEXT: ret
;
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV32IFD-LABEL: fold_promote_d_s:
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
2019-11-26 15:24:59 +01:00
; RV32IFD: # %bb.0:
; RV32IFD-NEXT: fcvt.d.s ft0, fa1
; RV32IFD-NEXT: fsgnj.d fa0, fa0, ft0
; RV32IFD-NEXT: ret
;
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV64IFD-LABEL: fold_promote_d_s:
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
2019-11-26 15:24:59 +01:00
; RV64IFD: # %bb.0:
; RV64IFD-NEXT: fcvt.d.s ft0, fa1
; RV64IFD-NEXT: fsgnj.d fa0, fa0, ft0
; RV64IFD-NEXT: ret
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
;
; RV32IFZFH-LABEL: fold_promote_d_s:
; RV32IFZFH: # %bb.0:
; RV32IFZFH-NEXT: fmv.x.w a2, fa0
; RV32IFZFH-NEXT: lui a3, 524288
; RV32IFZFH-NEXT: and a2, a2, a3
; RV32IFZFH-NEXT: addi a3, a3, -1
; RV32IFZFH-NEXT: and a1, a1, a3
; RV32IFZFH-NEXT: or a1, a1, a2
; RV32IFZFH-NEXT: ret
;
; RV32IFDZFH-LABEL: fold_promote_d_s:
; RV32IFDZFH: # %bb.0:
; RV32IFDZFH-NEXT: fcvt.d.s ft0, fa1
; RV32IFDZFH-NEXT: fsgnj.d fa0, fa0, ft0
; RV32IFDZFH-NEXT: ret
;
; RV64IFDZFH-LABEL: fold_promote_d_s:
; RV64IFDZFH: # %bb.0:
; RV64IFDZFH-NEXT: fcvt.d.s ft0, fa1
; RV64IFDZFH-NEXT: fsgnj.d fa0, fa0, ft0
; RV64IFDZFH-NEXT: ret
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
2019-11-26 15:24:59 +01:00
%c = fpext float %b to double
%t = call double @llvm.copysign.f64(double %a, double %c)
ret double %t
}
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
define double @fold_promote_d_h(double %a, half %b) nounwind {
; RV32I-LABEL: fold_promote_d_h:
; RV32I: # %bb.0:
; RV32I-NEXT: lui a3, 524288
; RV32I-NEXT: addi a3, a3, -1
; RV32I-NEXT: and a1, a1, a3
; RV32I-NEXT: lui a3, 8
; RV32I-NEXT: and a2, a2, a3
; RV32I-NEXT: slli a2, a2, 16
; RV32I-NEXT: or a1, a1, a2
; RV32I-NEXT: ret
;
; RV64I-LABEL: fold_promote_d_h:
; RV64I: # %bb.0:
; RV64I-NEXT: addi a2, zero, -1
[RISCV] Improve 64-bit integer materialization for some cases. This adds a new integer materialization strategy mainly targeted at 64-bit constants like 0xffffffff where there are 32 or more trailing ones with leading zeros. We can materialize these by using an addi -1 and srli to restore the leading zeros. This matches what gcc does. I haven't limited to just these cases though. The implementation here takes the constant, shifts out all the leading zeros and shifts ones into the LSBs, creates the new sequence, adds an srli, and checks if this is shorter than our original strategy. I've separated the recursive portion into a standalone function so I could append the new strategy outside of the recursion. Since external users are no longer using the recursive function, I've cleaned up the external interface to return the sequence instead of taking a vector by reference. Reviewed By: asb Differential Revision: https://reviews.llvm.org/D98821
2021-04-01 17:51:28 +02:00
; RV64I-NEXT: srli a2, a2, 1
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV64I-NEXT: and a0, a0, a2
; RV64I-NEXT: lui a2, 8
; RV64I-NEXT: and a1, a1, a2
; RV64I-NEXT: slli a1, a1, 48
; RV64I-NEXT: or a0, a0, a1
; RV64I-NEXT: ret
;
; RV32IF-LABEL: fold_promote_d_h:
; RV32IF: # %bb.0:
; RV32IF-NEXT: fmv.x.w a2, fa0
; RV32IF-NEXT: lui a3, 524288
; RV32IF-NEXT: addi a3, a3, -1
; RV32IF-NEXT: and a1, a1, a3
[RISCV] Pass 'half' in the lower 16 bits of an f32 value when F extension is enabled, but Zfh is not. Without Zfh the half type isn't legal, but it could still be used as an argument/return in IR. Clang will not generate this today. Previously we promoted the half value to float for arguments and returns if the F extension is enabled but Zfh isn't. Then depending on which ABI is enabled we would pass it in either an FPR or a GPR in float format. If the F extension isn't enabled, it would get passed in the lower 16 bits of a GPR in half format. With this patch the value will always in half format and will be in the lower bits of a GPR or FPR. This should be consistent with where the bits are located when Zfh is enabled. I've based this implementation off of how this is done on ARM. I've manually nan-boxed the value to 32 bits using integer ops. It looks like flw, fsw, fmv.s, fmv.w.x, fmf.x.w won't canonicalize nans so should leave the value alone. I think those are the instructions that could get used on this value. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D98670
2021-03-30 18:34:56 +02:00
; RV32IF-NEXT: lui a3, 8
; RV32IF-NEXT: and a2, a2, a3
; RV32IF-NEXT: slli a2, a2, 16
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV32IF-NEXT: or a1, a1, a2
; RV32IF-NEXT: ret
;
; RV32IFD-LABEL: fold_promote_d_h:
; RV32IFD: # %bb.0:
[RISCV] Pass 'half' in the lower 16 bits of an f32 value when F extension is enabled, but Zfh is not. Without Zfh the half type isn't legal, but it could still be used as an argument/return in IR. Clang will not generate this today. Previously we promoted the half value to float for arguments and returns if the F extension is enabled but Zfh isn't. Then depending on which ABI is enabled we would pass it in either an FPR or a GPR in float format. If the F extension isn't enabled, it would get passed in the lower 16 bits of a GPR in half format. With this patch the value will always in half format and will be in the lower bits of a GPR or FPR. This should be consistent with where the bits are located when Zfh is enabled. I've based this implementation off of how this is done on ARM. I've manually nan-boxed the value to 32 bits using integer ops. It looks like flw, fsw, fmv.s, fmv.w.x, fmf.x.w won't canonicalize nans so should leave the value alone. I think those are the instructions that could get used on this value. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D98670
2021-03-30 18:34:56 +02:00
; RV32IFD-NEXT: addi sp, sp, -16
; RV32IFD-NEXT: sw ra, 12(sp) # 4-byte Folded Spill
; RV32IFD-NEXT: fsd fs0, 0(sp) # 8-byte Folded Spill
; RV32IFD-NEXT: fmv.d fs0, fa0
; RV32IFD-NEXT: fmv.x.w a0, fa1
; RV32IFD-NEXT: call __gnu_h2f_ieee@plt
; RV32IFD-NEXT: fcvt.d.s ft0, fa0
; RV32IFD-NEXT: fsgnj.d fa0, fs0, ft0
; RV32IFD-NEXT: fld fs0, 0(sp) # 8-byte Folded Reload
; RV32IFD-NEXT: lw ra, 12(sp) # 4-byte Folded Reload
; RV32IFD-NEXT: addi sp, sp, 16
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV32IFD-NEXT: ret
;
; RV64IFD-LABEL: fold_promote_d_h:
; RV64IFD: # %bb.0:
[RISCV] Pass 'half' in the lower 16 bits of an f32 value when F extension is enabled, but Zfh is not. Without Zfh the half type isn't legal, but it could still be used as an argument/return in IR. Clang will not generate this today. Previously we promoted the half value to float for arguments and returns if the F extension is enabled but Zfh isn't. Then depending on which ABI is enabled we would pass it in either an FPR or a GPR in float format. If the F extension isn't enabled, it would get passed in the lower 16 bits of a GPR in half format. With this patch the value will always in half format and will be in the lower bits of a GPR or FPR. This should be consistent with where the bits are located when Zfh is enabled. I've based this implementation off of how this is done on ARM. I've manually nan-boxed the value to 32 bits using integer ops. It looks like flw, fsw, fmv.s, fmv.w.x, fmf.x.w won't canonicalize nans so should leave the value alone. I think those are the instructions that could get used on this value. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D98670
2021-03-30 18:34:56 +02:00
; RV64IFD-NEXT: addi sp, sp, -16
; RV64IFD-NEXT: sd ra, 8(sp) # 8-byte Folded Spill
; RV64IFD-NEXT: fsd fs0, 0(sp) # 8-byte Folded Spill
; RV64IFD-NEXT: fmv.d fs0, fa0
; RV64IFD-NEXT: fmv.x.w a0, fa1
; RV64IFD-NEXT: call __gnu_h2f_ieee@plt
; RV64IFD-NEXT: fcvt.d.s ft0, fa0
; RV64IFD-NEXT: fsgnj.d fa0, fs0, ft0
; RV64IFD-NEXT: fld fs0, 0(sp) # 8-byte Folded Reload
; RV64IFD-NEXT: ld ra, 8(sp) # 8-byte Folded Reload
; RV64IFD-NEXT: addi sp, sp, 16
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV64IFD-NEXT: ret
;
; RV32IFZFH-LABEL: fold_promote_d_h:
; RV32IFZFH: # %bb.0:
; RV32IFZFH-NEXT: fmv.x.h a2, fa0
; RV32IFZFH-NEXT: lui a3, 524288
; RV32IFZFH-NEXT: addi a3, a3, -1
; RV32IFZFH-NEXT: and a1, a1, a3
; RV32IFZFH-NEXT: lui a3, 8
; RV32IFZFH-NEXT: and a2, a2, a3
; RV32IFZFH-NEXT: slli a2, a2, 16
; RV32IFZFH-NEXT: or a1, a1, a2
; RV32IFZFH-NEXT: ret
;
; RV32IFDZFH-LABEL: fold_promote_d_h:
; RV32IFDZFH: # %bb.0:
; RV32IFDZFH-NEXT: fcvt.d.h ft0, fa1
; RV32IFDZFH-NEXT: fsgnj.d fa0, fa0, ft0
; RV32IFDZFH-NEXT: ret
;
; RV64IFDZFH-LABEL: fold_promote_d_h:
; RV64IFDZFH: # %bb.0:
; RV64IFDZFH-NEXT: fcvt.d.h ft0, fa1
; RV64IFDZFH-NEXT: fsgnj.d fa0, fa0, ft0
; RV64IFDZFH-NEXT: ret
%c = fpext half %b to double
%t = call double @llvm.copysign.f64(double %a, double %c)
ret double %t
}
define float @fold_promote_f_h(float %a, half %b) nounwind {
; RV32I-LABEL: fold_promote_f_h:
; RV32I: # %bb.0:
; RV32I-NEXT: lui a2, 524288
; RV32I-NEXT: addi a2, a2, -1
; RV32I-NEXT: and a0, a0, a2
; RV32I-NEXT: lui a2, 8
; RV32I-NEXT: and a1, a1, a2
; RV32I-NEXT: slli a1, a1, 16
; RV32I-NEXT: or a0, a0, a1
; RV32I-NEXT: ret
;
; RV64I-LABEL: fold_promote_f_h:
; RV64I: # %bb.0:
; RV64I-NEXT: lui a2, 524288
; RV64I-NEXT: addiw a2, a2, -1
; RV64I-NEXT: and a0, a0, a2
[RISCV] Add implementation of targetShrinkDemandedConstant to optimize AND immediates. SimplifyDemandedBits can remove set bits from immediates from instructions like AND/OR/XOR. This can prevent them from being efficiently codegened on RISCV. This adds an initial version that tries to keep or form 12 bit sign extended immediates for AND operations to enable use of ANDI. If that doesn't work we'll try to create a 32 bit sign extended immediate to use LUI+ADDIW. More optimizations are possible for different size immediates or different operations. But this is a good starting point that already has test coverage. Reviewed By: frasercrmck Differential Revision: https://reviews.llvm.org/D94628
2021-01-15 19:54:26 +01:00
; RV64I-NEXT: lui a2, 1048568
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV64I-NEXT: and a1, a1, a2
; RV64I-NEXT: slli a1, a1, 16
; RV64I-NEXT: or a0, a0, a1
; RV64I-NEXT: ret
;
; RV32IF-LABEL: fold_promote_f_h:
; RV32IF: # %bb.0:
[RISCV] Pass 'half' in the lower 16 bits of an f32 value when F extension is enabled, but Zfh is not. Without Zfh the half type isn't legal, but it could still be used as an argument/return in IR. Clang will not generate this today. Previously we promoted the half value to float for arguments and returns if the F extension is enabled but Zfh isn't. Then depending on which ABI is enabled we would pass it in either an FPR or a GPR in float format. If the F extension isn't enabled, it would get passed in the lower 16 bits of a GPR in half format. With this patch the value will always in half format and will be in the lower bits of a GPR or FPR. This should be consistent with where the bits are located when Zfh is enabled. I've based this implementation off of how this is done on ARM. I've manually nan-boxed the value to 32 bits using integer ops. It looks like flw, fsw, fmv.s, fmv.w.x, fmf.x.w won't canonicalize nans so should leave the value alone. I think those are the instructions that could get used on this value. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D98670
2021-03-30 18:34:56 +02:00
; RV32IF-NEXT: addi sp, sp, -16
; RV32IF-NEXT: sw ra, 12(sp) # 4-byte Folded Spill
; RV32IF-NEXT: fsw fs0, 8(sp) # 4-byte Folded Spill
; RV32IF-NEXT: fmv.s fs0, fa0
; RV32IF-NEXT: fmv.x.w a0, fa1
; RV32IF-NEXT: call __gnu_h2f_ieee@plt
; RV32IF-NEXT: fsgnj.s fa0, fs0, fa0
; RV32IF-NEXT: flw fs0, 8(sp) # 4-byte Folded Reload
; RV32IF-NEXT: lw ra, 12(sp) # 4-byte Folded Reload
; RV32IF-NEXT: addi sp, sp, 16
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV32IF-NEXT: ret
;
; RV32IFD-LABEL: fold_promote_f_h:
; RV32IFD: # %bb.0:
[RISCV] Pass 'half' in the lower 16 bits of an f32 value when F extension is enabled, but Zfh is not. Without Zfh the half type isn't legal, but it could still be used as an argument/return in IR. Clang will not generate this today. Previously we promoted the half value to float for arguments and returns if the F extension is enabled but Zfh isn't. Then depending on which ABI is enabled we would pass it in either an FPR or a GPR in float format. If the F extension isn't enabled, it would get passed in the lower 16 bits of a GPR in half format. With this patch the value will always in half format and will be in the lower bits of a GPR or FPR. This should be consistent with where the bits are located when Zfh is enabled. I've based this implementation off of how this is done on ARM. I've manually nan-boxed the value to 32 bits using integer ops. It looks like flw, fsw, fmv.s, fmv.w.x, fmf.x.w won't canonicalize nans so should leave the value alone. I think those are the instructions that could get used on this value. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D98670
2021-03-30 18:34:56 +02:00
; RV32IFD-NEXT: addi sp, sp, -16
; RV32IFD-NEXT: sw ra, 12(sp) # 4-byte Folded Spill
; RV32IFD-NEXT: fsd fs0, 0(sp) # 8-byte Folded Spill
; RV32IFD-NEXT: fmv.s fs0, fa0
; RV32IFD-NEXT: fmv.x.w a0, fa1
; RV32IFD-NEXT: call __gnu_h2f_ieee@plt
; RV32IFD-NEXT: fsgnj.s fa0, fs0, fa0
; RV32IFD-NEXT: fld fs0, 0(sp) # 8-byte Folded Reload
; RV32IFD-NEXT: lw ra, 12(sp) # 4-byte Folded Reload
; RV32IFD-NEXT: addi sp, sp, 16
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV32IFD-NEXT: ret
;
; RV64IFD-LABEL: fold_promote_f_h:
; RV64IFD: # %bb.0:
[RISCV] Pass 'half' in the lower 16 bits of an f32 value when F extension is enabled, but Zfh is not. Without Zfh the half type isn't legal, but it could still be used as an argument/return in IR. Clang will not generate this today. Previously we promoted the half value to float for arguments and returns if the F extension is enabled but Zfh isn't. Then depending on which ABI is enabled we would pass it in either an FPR or a GPR in float format. If the F extension isn't enabled, it would get passed in the lower 16 bits of a GPR in half format. With this patch the value will always in half format and will be in the lower bits of a GPR or FPR. This should be consistent with where the bits are located when Zfh is enabled. I've based this implementation off of how this is done on ARM. I've manually nan-boxed the value to 32 bits using integer ops. It looks like flw, fsw, fmv.s, fmv.w.x, fmf.x.w won't canonicalize nans so should leave the value alone. I think those are the instructions that could get used on this value. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D98670
2021-03-30 18:34:56 +02:00
; RV64IFD-NEXT: addi sp, sp, -16
; RV64IFD-NEXT: sd ra, 8(sp) # 8-byte Folded Spill
; RV64IFD-NEXT: fsd fs0, 0(sp) # 8-byte Folded Spill
; RV64IFD-NEXT: fmv.s fs0, fa0
; RV64IFD-NEXT: fmv.x.w a0, fa1
; RV64IFD-NEXT: call __gnu_h2f_ieee@plt
; RV64IFD-NEXT: fsgnj.s fa0, fs0, fa0
; RV64IFD-NEXT: fld fs0, 0(sp) # 8-byte Folded Reload
; RV64IFD-NEXT: ld ra, 8(sp) # 8-byte Folded Reload
; RV64IFD-NEXT: addi sp, sp, 16
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV64IFD-NEXT: ret
;
; RV32IFZFH-LABEL: fold_promote_f_h:
; RV32IFZFH: # %bb.0:
; RV32IFZFH-NEXT: fcvt.s.h ft0, fa1
; RV32IFZFH-NEXT: fsgnj.s fa0, fa0, ft0
; RV32IFZFH-NEXT: ret
;
; RV32IFDZFH-LABEL: fold_promote_f_h:
; RV32IFDZFH: # %bb.0:
; RV32IFDZFH-NEXT: fcvt.s.h ft0, fa1
; RV32IFDZFH-NEXT: fsgnj.s fa0, fa0, ft0
; RV32IFDZFH-NEXT: ret
;
; RV64IFDZFH-LABEL: fold_promote_f_h:
; RV64IFDZFH: # %bb.0:
; RV64IFDZFH-NEXT: fcvt.s.h ft0, fa1
; RV64IFDZFH-NEXT: fsgnj.s fa0, fa0, ft0
; RV64IFDZFH-NEXT: ret
%c = fpext half %b to float
%t = call float @llvm.copysign.f32(float %a, float %c)
ret float %t
}
define float @fold_demote_s_d(float %a, double %b) nounwind {
; RV32I-LABEL: fold_demote_s_d:
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
2019-11-26 15:24:59 +01:00
; RV32I: # %bb.0:
; RV32I-NEXT: lui a1, 524288
; RV32I-NEXT: and a2, a2, a1
; RV32I-NEXT: addi a1, a1, -1
; RV32I-NEXT: and a0, a0, a1
; RV32I-NEXT: or a0, a0, a2
; RV32I-NEXT: ret
;
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV64I-LABEL: fold_demote_s_d:
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
2019-11-26 15:24:59 +01:00
; RV64I: # %bb.0:
; RV64I-NEXT: lui a2, 524288
; RV64I-NEXT: addiw a2, a2, -1
; RV64I-NEXT: and a0, a0, a2
; RV64I-NEXT: addi a2, zero, -1
; RV64I-NEXT: slli a2, a2, 63
; RV64I-NEXT: and a1, a1, a2
; RV64I-NEXT: srli a1, a1, 32
; RV64I-NEXT: or a0, a0, a1
; RV64I-NEXT: ret
;
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV32IF-LABEL: fold_demote_s_d:
[LegalizeTypes][RISCV] Soften FCOPYSIGN operand Summary: Adds support for softening FCOPYSIGN operands. Adds RISC-V tests that exercise the new softening code. Reviewers: asb, lenary, efriedma Reviewed By: efriedma Tags: #llvm Differential Revision: https://reviews.llvm.org/D70679
2019-11-24 16:23:29 +01:00
; RV32IF: # %bb.0:
; RV32IF-NEXT: fmv.w.x ft0, a1
; RV32IF-NEXT: fsgnj.s fa0, fa0, ft0
; RV32IF-NEXT: ret
;
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV32IFD-LABEL: fold_demote_s_d:
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
2019-11-26 15:24:59 +01:00
; RV32IFD: # %bb.0:
; RV32IFD-NEXT: fcvt.s.d ft0, fa1
; RV32IFD-NEXT: fsgnj.s fa0, fa0, ft0
; RV32IFD-NEXT: ret
;
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV64IFD-LABEL: fold_demote_s_d:
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
2019-11-26 15:24:59 +01:00
; RV64IFD: # %bb.0:
; RV64IFD-NEXT: fcvt.s.d ft0, fa1
; RV64IFD-NEXT: fsgnj.s fa0, fa0, ft0
; RV64IFD-NEXT: ret
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
;
; RV32IFZFH-LABEL: fold_demote_s_d:
; RV32IFZFH: # %bb.0:
; RV32IFZFH-NEXT: fmv.w.x ft0, a1
; RV32IFZFH-NEXT: fsgnj.s fa0, fa0, ft0
; RV32IFZFH-NEXT: ret
;
; RV32IFDZFH-LABEL: fold_demote_s_d:
; RV32IFDZFH: # %bb.0:
; RV32IFDZFH-NEXT: fcvt.s.d ft0, fa1
; RV32IFDZFH-NEXT: fsgnj.s fa0, fa0, ft0
; RV32IFDZFH-NEXT: ret
;
; RV64IFDZFH-LABEL: fold_demote_s_d:
; RV64IFDZFH: # %bb.0:
; RV64IFDZFH-NEXT: fcvt.s.d ft0, fa1
; RV64IFDZFH-NEXT: fsgnj.s fa0, fa0, ft0
; RV64IFDZFH-NEXT: ret
[RISCV] Handle fcopysign(f32, f64) and fcopysign(f64, f32) Summary: Adds tablegen patterns to explicitly handle fcopysign where the magnitude and sign arguments have different types, due to the sign value casts being removed the by DAGCombiner. Support for RV32IF follows in a separate commit. Adds tests for all relevant scenarios except RV32IF. Reviewers: lenary Reviewed By: lenary Tags: #llvm Differential Revision: https://reviews.llvm.org/D70678
2019-11-26 15:24:59 +01:00
%c = fptrunc double %b to float
%t = call float @llvm.copysign.f32(float %a, float %c)
ret float %t
}
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
define half @fold_demote_h_s(half %a, float %b) nounwind {
; RV32I-LABEL: fold_demote_h_s:
; RV32I: # %bb.0:
[RISCV] Use softPromoteHalf legalization for fp16 without Zfh rather than PromoteFloat. The default legalization strategy is PromoteFloat which keeps half in single precision format through multiple floating point operations. Conversion to/from float is done at loads, stores, bitcasts, and other places that care about the exact size being 16 bits. This patches switches to the alternative method softPromoteHalf. This aims to keep the type in 16-bit format between every operation. So we promote to float and immediately round for any arithmetic operation. This should be closer to the IR semantics since we are rounding after each operation and not accumulating extra precision across multiple operations. X86 is the only other target that enables this today. See https://reviews.llvm.org/D73749 I had to update getRegisterTypeForCallingConv to force f16 to use f32 when the F extension is enabled. This way we can still pass it in the lower bits of an FPR for ilp32f and lp64f ABIs. The softPromoteHalf would otherwise always give i16 as the argument type. Reviewed By: asb, frasercrmck Differential Revision: https://reviews.llvm.org/D99148
2021-04-01 20:47:11 +02:00
; RV32I-NEXT: lui a2, 8
; RV32I-NEXT: addi a2, a2, -1
; RV32I-NEXT: and a0, a0, a2
; RV32I-NEXT: lui a2, 524288
; RV32I-NEXT: and a1, a1, a2
; RV32I-NEXT: srli a1, a1, 16
; RV32I-NEXT: or a0, a0, a1
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV32I-NEXT: ret
;
; RV64I-LABEL: fold_demote_h_s:
; RV64I: # %bb.0:
[RISCV] Use softPromoteHalf legalization for fp16 without Zfh rather than PromoteFloat. The default legalization strategy is PromoteFloat which keeps half in single precision format through multiple floating point operations. Conversion to/from float is done at loads, stores, bitcasts, and other places that care about the exact size being 16 bits. This patches switches to the alternative method softPromoteHalf. This aims to keep the type in 16-bit format between every operation. So we promote to float and immediately round for any arithmetic operation. This should be closer to the IR semantics since we are rounding after each operation and not accumulating extra precision across multiple operations. X86 is the only other target that enables this today. See https://reviews.llvm.org/D73749 I had to update getRegisterTypeForCallingConv to force f16 to use f32 when the F extension is enabled. This way we can still pass it in the lower bits of an FPR for ilp32f and lp64f ABIs. The softPromoteHalf would otherwise always give i16 as the argument type. Reviewed By: asb, frasercrmck Differential Revision: https://reviews.llvm.org/D99148
2021-04-01 20:47:11 +02:00
; RV64I-NEXT: lui a2, 8
; RV64I-NEXT: addiw a2, a2, -1
; RV64I-NEXT: and a0, a0, a2
; RV64I-NEXT: addi a2, zero, 1
; RV64I-NEXT: slli a2, a2, 31
; RV64I-NEXT: and a1, a1, a2
Revert "[RISCV] Use zexti32/sexti32 in srliw/sraiw isel patterns to improve usage of those instructions." I thought this might help with another optimization I was thinking about, but I don't think it will. So it just wastes compile time calling computeKnownBits for no benefit. This reverts commit 81b2f95971edd47a0057ac4a77b674d7ea620c01.
2021-06-27 19:32:48 +02:00
; RV64I-NEXT: srli a1, a1, 16
[RISCV] Use softPromoteHalf legalization for fp16 without Zfh rather than PromoteFloat. The default legalization strategy is PromoteFloat which keeps half in single precision format through multiple floating point operations. Conversion to/from float is done at loads, stores, bitcasts, and other places that care about the exact size being 16 bits. This patches switches to the alternative method softPromoteHalf. This aims to keep the type in 16-bit format between every operation. So we promote to float and immediately round for any arithmetic operation. This should be closer to the IR semantics since we are rounding after each operation and not accumulating extra precision across multiple operations. X86 is the only other target that enables this today. See https://reviews.llvm.org/D73749 I had to update getRegisterTypeForCallingConv to force f16 to use f32 when the F extension is enabled. This way we can still pass it in the lower bits of an FPR for ilp32f and lp64f ABIs. The softPromoteHalf would otherwise always give i16 as the argument type. Reviewed By: asb, frasercrmck Differential Revision: https://reviews.llvm.org/D99148
2021-04-01 20:47:11 +02:00
; RV64I-NEXT: or a0, a0, a1
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV64I-NEXT: ret
;
; RV32IF-LABEL: fold_demote_h_s:
; RV32IF: # %bb.0:
[RISCV] Use softPromoteHalf legalization for fp16 without Zfh rather than PromoteFloat. The default legalization strategy is PromoteFloat which keeps half in single precision format through multiple floating point operations. Conversion to/from float is done at loads, stores, bitcasts, and other places that care about the exact size being 16 bits. This patches switches to the alternative method softPromoteHalf. This aims to keep the type in 16-bit format between every operation. So we promote to float and immediately round for any arithmetic operation. This should be closer to the IR semantics since we are rounding after each operation and not accumulating extra precision across multiple operations. X86 is the only other target that enables this today. See https://reviews.llvm.org/D73749 I had to update getRegisterTypeForCallingConv to force f16 to use f32 when the F extension is enabled. This way we can still pass it in the lower bits of an FPR for ilp32f and lp64f ABIs. The softPromoteHalf would otherwise always give i16 as the argument type. Reviewed By: asb, frasercrmck Differential Revision: https://reviews.llvm.org/D99148
2021-04-01 20:47:11 +02:00
; RV32IF-NEXT: fmv.x.w a0, fa1
; RV32IF-NEXT: fmv.x.w a1, fa0
; RV32IF-NEXT: lui a2, 8
; RV32IF-NEXT: addi a2, a2, -1
; RV32IF-NEXT: and a1, a1, a2
; RV32IF-NEXT: lui a2, 524288
; RV32IF-NEXT: and a0, a0, a2
; RV32IF-NEXT: srli a0, a0, 16
; RV32IF-NEXT: or a0, a1, a0
[RISCV] Pass 'half' in the lower 16 bits of an f32 value when F extension is enabled, but Zfh is not. Without Zfh the half type isn't legal, but it could still be used as an argument/return in IR. Clang will not generate this today. Previously we promoted the half value to float for arguments and returns if the F extension is enabled but Zfh isn't. Then depending on which ABI is enabled we would pass it in either an FPR or a GPR in float format. If the F extension isn't enabled, it would get passed in the lower 16 bits of a GPR in half format. With this patch the value will always in half format and will be in the lower bits of a GPR or FPR. This should be consistent with where the bits are located when Zfh is enabled. I've based this implementation off of how this is done on ARM. I've manually nan-boxed the value to 32 bits using integer ops. It looks like flw, fsw, fmv.s, fmv.w.x, fmf.x.w won't canonicalize nans so should leave the value alone. I think those are the instructions that could get used on this value. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D98670
2021-03-30 18:34:56 +02:00
; RV32IF-NEXT: lui a1, 1048560
; RV32IF-NEXT: or a0, a0, a1
; RV32IF-NEXT: fmv.w.x fa0, a0
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV32IF-NEXT: ret
;
; RV32IFD-LABEL: fold_demote_h_s:
; RV32IFD: # %bb.0:
[RISCV] Use softPromoteHalf legalization for fp16 without Zfh rather than PromoteFloat. The default legalization strategy is PromoteFloat which keeps half in single precision format through multiple floating point operations. Conversion to/from float is done at loads, stores, bitcasts, and other places that care about the exact size being 16 bits. This patches switches to the alternative method softPromoteHalf. This aims to keep the type in 16-bit format between every operation. So we promote to float and immediately round for any arithmetic operation. This should be closer to the IR semantics since we are rounding after each operation and not accumulating extra precision across multiple operations. X86 is the only other target that enables this today. See https://reviews.llvm.org/D73749 I had to update getRegisterTypeForCallingConv to force f16 to use f32 when the F extension is enabled. This way we can still pass it in the lower bits of an FPR for ilp32f and lp64f ABIs. The softPromoteHalf would otherwise always give i16 as the argument type. Reviewed By: asb, frasercrmck Differential Revision: https://reviews.llvm.org/D99148
2021-04-01 20:47:11 +02:00
; RV32IFD-NEXT: fmv.x.w a0, fa1
; RV32IFD-NEXT: fmv.x.w a1, fa0
; RV32IFD-NEXT: lui a2, 8
; RV32IFD-NEXT: addi a2, a2, -1
; RV32IFD-NEXT: and a1, a1, a2
; RV32IFD-NEXT: lui a2, 524288
; RV32IFD-NEXT: and a0, a0, a2
; RV32IFD-NEXT: srli a0, a0, 16
; RV32IFD-NEXT: or a0, a1, a0
[RISCV] Pass 'half' in the lower 16 bits of an f32 value when F extension is enabled, but Zfh is not. Without Zfh the half type isn't legal, but it could still be used as an argument/return in IR. Clang will not generate this today. Previously we promoted the half value to float for arguments and returns if the F extension is enabled but Zfh isn't. Then depending on which ABI is enabled we would pass it in either an FPR or a GPR in float format. If the F extension isn't enabled, it would get passed in the lower 16 bits of a GPR in half format. With this patch the value will always in half format and will be in the lower bits of a GPR or FPR. This should be consistent with where the bits are located when Zfh is enabled. I've based this implementation off of how this is done on ARM. I've manually nan-boxed the value to 32 bits using integer ops. It looks like flw, fsw, fmv.s, fmv.w.x, fmf.x.w won't canonicalize nans so should leave the value alone. I think those are the instructions that could get used on this value. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D98670
2021-03-30 18:34:56 +02:00
; RV32IFD-NEXT: lui a1, 1048560
; RV32IFD-NEXT: or a0, a0, a1
; RV32IFD-NEXT: fmv.w.x fa0, a0
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV32IFD-NEXT: ret
;
; RV64IFD-LABEL: fold_demote_h_s:
; RV64IFD: # %bb.0:
[RISCV] Use softPromoteHalf legalization for fp16 without Zfh rather than PromoteFloat. The default legalization strategy is PromoteFloat which keeps half in single precision format through multiple floating point operations. Conversion to/from float is done at loads, stores, bitcasts, and other places that care about the exact size being 16 bits. This patches switches to the alternative method softPromoteHalf. This aims to keep the type in 16-bit format between every operation. So we promote to float and immediately round for any arithmetic operation. This should be closer to the IR semantics since we are rounding after each operation and not accumulating extra precision across multiple operations. X86 is the only other target that enables this today. See https://reviews.llvm.org/D73749 I had to update getRegisterTypeForCallingConv to force f16 to use f32 when the F extension is enabled. This way we can still pass it in the lower bits of an FPR for ilp32f and lp64f ABIs. The softPromoteHalf would otherwise always give i16 as the argument type. Reviewed By: asb, frasercrmck Differential Revision: https://reviews.llvm.org/D99148
2021-04-01 20:47:11 +02:00
; RV64IFD-NEXT: fmv.x.w a0, fa1
; RV64IFD-NEXT: fmv.x.w a1, fa0
; RV64IFD-NEXT: lui a2, 8
; RV64IFD-NEXT: addiw a2, a2, -1
; RV64IFD-NEXT: and a1, a1, a2
; RV64IFD-NEXT: lui a2, 524288
; RV64IFD-NEXT: and a0, a0, a2
; RV64IFD-NEXT: srli a0, a0, 16
; RV64IFD-NEXT: or a0, a1, a0
[RISCV] Pass 'half' in the lower 16 bits of an f32 value when F extension is enabled, but Zfh is not. Without Zfh the half type isn't legal, but it could still be used as an argument/return in IR. Clang will not generate this today. Previously we promoted the half value to float for arguments and returns if the F extension is enabled but Zfh isn't. Then depending on which ABI is enabled we would pass it in either an FPR or a GPR in float format. If the F extension isn't enabled, it would get passed in the lower 16 bits of a GPR in half format. With this patch the value will always in half format and will be in the lower bits of a GPR or FPR. This should be consistent with where the bits are located when Zfh is enabled. I've based this implementation off of how this is done on ARM. I've manually nan-boxed the value to 32 bits using integer ops. It looks like flw, fsw, fmv.s, fmv.w.x, fmf.x.w won't canonicalize nans so should leave the value alone. I think those are the instructions that could get used on this value. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D98670
2021-03-30 18:34:56 +02:00
; RV64IFD-NEXT: lui a1, 1048560
; RV64IFD-NEXT: or a0, a0, a1
; RV64IFD-NEXT: fmv.w.x fa0, a0
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV64IFD-NEXT: ret
;
; RV32IFZFH-LABEL: fold_demote_h_s:
; RV32IFZFH: # %bb.0:
; RV32IFZFH-NEXT: fcvt.h.s ft0, fa1
; RV32IFZFH-NEXT: fsgnj.h fa0, fa0, ft0
; RV32IFZFH-NEXT: ret
;
; RV32IFDZFH-LABEL: fold_demote_h_s:
; RV32IFDZFH: # %bb.0:
; RV32IFDZFH-NEXT: fcvt.h.s ft0, fa1
; RV32IFDZFH-NEXT: fsgnj.h fa0, fa0, ft0
; RV32IFDZFH-NEXT: ret
;
; RV64IFDZFH-LABEL: fold_demote_h_s:
; RV64IFDZFH: # %bb.0:
; RV64IFDZFH-NEXT: fcvt.h.s ft0, fa1
; RV64IFDZFH-NEXT: fsgnj.h fa0, fa0, ft0
; RV64IFDZFH-NEXT: ret
%c = fptrunc float %b to half
%t = call half @llvm.copysign.f16(half %a, half %c)
ret half %t
}
define half @fold_demote_h_d(half %a, double %b) nounwind {
; RV32I-LABEL: fold_demote_h_d:
; RV32I: # %bb.0:
[RISCV] Use softPromoteHalf legalization for fp16 without Zfh rather than PromoteFloat. The default legalization strategy is PromoteFloat which keeps half in single precision format through multiple floating point operations. Conversion to/from float is done at loads, stores, bitcasts, and other places that care about the exact size being 16 bits. This patches switches to the alternative method softPromoteHalf. This aims to keep the type in 16-bit format between every operation. So we promote to float and immediately round for any arithmetic operation. This should be closer to the IR semantics since we are rounding after each operation and not accumulating extra precision across multiple operations. X86 is the only other target that enables this today. See https://reviews.llvm.org/D73749 I had to update getRegisterTypeForCallingConv to force f16 to use f32 when the F extension is enabled. This way we can still pass it in the lower bits of an FPR for ilp32f and lp64f ABIs. The softPromoteHalf would otherwise always give i16 as the argument type. Reviewed By: asb, frasercrmck Differential Revision: https://reviews.llvm.org/D99148
2021-04-01 20:47:11 +02:00
; RV32I-NEXT: lui a1, 8
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV32I-NEXT: addi a1, a1, -1
; RV32I-NEXT: and a0, a0, a1
; RV32I-NEXT: lui a1, 524288
[RISCV] Use softPromoteHalf legalization for fp16 without Zfh rather than PromoteFloat. The default legalization strategy is PromoteFloat which keeps half in single precision format through multiple floating point operations. Conversion to/from float is done at loads, stores, bitcasts, and other places that care about the exact size being 16 bits. This patches switches to the alternative method softPromoteHalf. This aims to keep the type in 16-bit format between every operation. So we promote to float and immediately round for any arithmetic operation. This should be closer to the IR semantics since we are rounding after each operation and not accumulating extra precision across multiple operations. X86 is the only other target that enables this today. See https://reviews.llvm.org/D73749 I had to update getRegisterTypeForCallingConv to force f16 to use f32 when the F extension is enabled. This way we can still pass it in the lower bits of an FPR for ilp32f and lp64f ABIs. The softPromoteHalf would otherwise always give i16 as the argument type. Reviewed By: asb, frasercrmck Differential Revision: https://reviews.llvm.org/D99148
2021-04-01 20:47:11 +02:00
; RV32I-NEXT: and a1, a2, a1
; RV32I-NEXT: srli a1, a1, 16
; RV32I-NEXT: or a0, a0, a1
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV32I-NEXT: ret
;
; RV64I-LABEL: fold_demote_h_d:
; RV64I: # %bb.0:
[RISCV] Use softPromoteHalf legalization for fp16 without Zfh rather than PromoteFloat. The default legalization strategy is PromoteFloat which keeps half in single precision format through multiple floating point operations. Conversion to/from float is done at loads, stores, bitcasts, and other places that care about the exact size being 16 bits. This patches switches to the alternative method softPromoteHalf. This aims to keep the type in 16-bit format between every operation. So we promote to float and immediately round for any arithmetic operation. This should be closer to the IR semantics since we are rounding after each operation and not accumulating extra precision across multiple operations. X86 is the only other target that enables this today. See https://reviews.llvm.org/D73749 I had to update getRegisterTypeForCallingConv to force f16 to use f32 when the F extension is enabled. This way we can still pass it in the lower bits of an FPR for ilp32f and lp64f ABIs. The softPromoteHalf would otherwise always give i16 as the argument type. Reviewed By: asb, frasercrmck Differential Revision: https://reviews.llvm.org/D99148
2021-04-01 20:47:11 +02:00
; RV64I-NEXT: lui a2, 8
; RV64I-NEXT: addiw a2, a2, -1
; RV64I-NEXT: and a0, a0, a2
; RV64I-NEXT: addi a2, zero, -1
; RV64I-NEXT: slli a2, a2, 63
; RV64I-NEXT: and a1, a1, a2
; RV64I-NEXT: srli a1, a1, 48
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV64I-NEXT: or a0, a0, a1
; RV64I-NEXT: ret
;
; RV32IF-LABEL: fold_demote_h_d:
; RV32IF: # %bb.0:
[RISCV] Pass 'half' in the lower 16 bits of an f32 value when F extension is enabled, but Zfh is not. Without Zfh the half type isn't legal, but it could still be used as an argument/return in IR. Clang will not generate this today. Previously we promoted the half value to float for arguments and returns if the F extension is enabled but Zfh isn't. Then depending on which ABI is enabled we would pass it in either an FPR or a GPR in float format. If the F extension isn't enabled, it would get passed in the lower 16 bits of a GPR in half format. With this patch the value will always in half format and will be in the lower bits of a GPR or FPR. This should be consistent with where the bits are located when Zfh is enabled. I've based this implementation off of how this is done on ARM. I've manually nan-boxed the value to 32 bits using integer ops. It looks like flw, fsw, fmv.s, fmv.w.x, fmf.x.w won't canonicalize nans so should leave the value alone. I think those are the instructions that could get used on this value. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D98670
2021-03-30 18:34:56 +02:00
; RV32IF-NEXT: fmv.x.w a0, fa0
[RISCV] Use softPromoteHalf legalization for fp16 without Zfh rather than PromoteFloat. The default legalization strategy is PromoteFloat which keeps half in single precision format through multiple floating point operations. Conversion to/from float is done at loads, stores, bitcasts, and other places that care about the exact size being 16 bits. This patches switches to the alternative method softPromoteHalf. This aims to keep the type in 16-bit format between every operation. So we promote to float and immediately round for any arithmetic operation. This should be closer to the IR semantics since we are rounding after each operation and not accumulating extra precision across multiple operations. X86 is the only other target that enables this today. See https://reviews.llvm.org/D73749 I had to update getRegisterTypeForCallingConv to force f16 to use f32 when the F extension is enabled. This way we can still pass it in the lower bits of an FPR for ilp32f and lp64f ABIs. The softPromoteHalf would otherwise always give i16 as the argument type. Reviewed By: asb, frasercrmck Differential Revision: https://reviews.llvm.org/D99148
2021-04-01 20:47:11 +02:00
; RV32IF-NEXT: lui a2, 8
; RV32IF-NEXT: addi a2, a2, -1
; RV32IF-NEXT: and a0, a0, a2
; RV32IF-NEXT: lui a2, 524288
; RV32IF-NEXT: and a1, a1, a2
; RV32IF-NEXT: srli a1, a1, 16
; RV32IF-NEXT: or a0, a0, a1
[RISCV] Pass 'half' in the lower 16 bits of an f32 value when F extension is enabled, but Zfh is not. Without Zfh the half type isn't legal, but it could still be used as an argument/return in IR. Clang will not generate this today. Previously we promoted the half value to float for arguments and returns if the F extension is enabled but Zfh isn't. Then depending on which ABI is enabled we would pass it in either an FPR or a GPR in float format. If the F extension isn't enabled, it would get passed in the lower 16 bits of a GPR in half format. With this patch the value will always in half format and will be in the lower bits of a GPR or FPR. This should be consistent with where the bits are located when Zfh is enabled. I've based this implementation off of how this is done on ARM. I've manually nan-boxed the value to 32 bits using integer ops. It looks like flw, fsw, fmv.s, fmv.w.x, fmf.x.w won't canonicalize nans so should leave the value alone. I think those are the instructions that could get used on this value. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D98670
2021-03-30 18:34:56 +02:00
; RV32IF-NEXT: lui a1, 1048560
; RV32IF-NEXT: or a0, a0, a1
; RV32IF-NEXT: fmv.w.x fa0, a0
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV32IF-NEXT: ret
;
; RV32IFD-LABEL: fold_demote_h_d:
; RV32IFD: # %bb.0:
; RV32IFD-NEXT: addi sp, sp, -16
[RISCV] Use softPromoteHalf legalization for fp16 without Zfh rather than PromoteFloat. The default legalization strategy is PromoteFloat which keeps half in single precision format through multiple floating point operations. Conversion to/from float is done at loads, stores, bitcasts, and other places that care about the exact size being 16 bits. This patches switches to the alternative method softPromoteHalf. This aims to keep the type in 16-bit format between every operation. So we promote to float and immediately round for any arithmetic operation. This should be closer to the IR semantics since we are rounding after each operation and not accumulating extra precision across multiple operations. X86 is the only other target that enables this today. See https://reviews.llvm.org/D73749 I had to update getRegisterTypeForCallingConv to force f16 to use f32 when the F extension is enabled. This way we can still pass it in the lower bits of an FPR for ilp32f and lp64f ABIs. The softPromoteHalf would otherwise always give i16 as the argument type. Reviewed By: asb, frasercrmck Differential Revision: https://reviews.llvm.org/D99148
2021-04-01 20:47:11 +02:00
; RV32IFD-NEXT: fsd fa1, 8(sp)
[RISCV] Pass 'half' in the lower 16 bits of an f32 value when F extension is enabled, but Zfh is not. Without Zfh the half type isn't legal, but it could still be used as an argument/return in IR. Clang will not generate this today. Previously we promoted the half value to float for arguments and returns if the F extension is enabled but Zfh isn't. Then depending on which ABI is enabled we would pass it in either an FPR or a GPR in float format. If the F extension isn't enabled, it would get passed in the lower 16 bits of a GPR in half format. With this patch the value will always in half format and will be in the lower bits of a GPR or FPR. This should be consistent with where the bits are located when Zfh is enabled. I've based this implementation off of how this is done on ARM. I've manually nan-boxed the value to 32 bits using integer ops. It looks like flw, fsw, fmv.s, fmv.w.x, fmf.x.w won't canonicalize nans so should leave the value alone. I think those are the instructions that could get used on this value. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D98670
2021-03-30 18:34:56 +02:00
; RV32IFD-NEXT: fmv.x.w a0, fa0
[RISCV] Use softPromoteHalf legalization for fp16 without Zfh rather than PromoteFloat. The default legalization strategy is PromoteFloat which keeps half in single precision format through multiple floating point operations. Conversion to/from float is done at loads, stores, bitcasts, and other places that care about the exact size being 16 bits. This patches switches to the alternative method softPromoteHalf. This aims to keep the type in 16-bit format between every operation. So we promote to float and immediately round for any arithmetic operation. This should be closer to the IR semantics since we are rounding after each operation and not accumulating extra precision across multiple operations. X86 is the only other target that enables this today. See https://reviews.llvm.org/D73749 I had to update getRegisterTypeForCallingConv to force f16 to use f32 when the F extension is enabled. This way we can still pass it in the lower bits of an FPR for ilp32f and lp64f ABIs. The softPromoteHalf would otherwise always give i16 as the argument type. Reviewed By: asb, frasercrmck Differential Revision: https://reviews.llvm.org/D99148
2021-04-01 20:47:11 +02:00
; RV32IFD-NEXT: lw a1, 12(sp)
; RV32IFD-NEXT: lui a2, 8
; RV32IFD-NEXT: addi a2, a2, -1
; RV32IFD-NEXT: and a0, a0, a2
; RV32IFD-NEXT: lui a2, 524288
; RV32IFD-NEXT: and a1, a1, a2
; RV32IFD-NEXT: srli a1, a1, 16
; RV32IFD-NEXT: or a0, a0, a1
[RISCV] Pass 'half' in the lower 16 bits of an f32 value when F extension is enabled, but Zfh is not. Without Zfh the half type isn't legal, but it could still be used as an argument/return in IR. Clang will not generate this today. Previously we promoted the half value to float for arguments and returns if the F extension is enabled but Zfh isn't. Then depending on which ABI is enabled we would pass it in either an FPR or a GPR in float format. If the F extension isn't enabled, it would get passed in the lower 16 bits of a GPR in half format. With this patch the value will always in half format and will be in the lower bits of a GPR or FPR. This should be consistent with where the bits are located when Zfh is enabled. I've based this implementation off of how this is done on ARM. I've manually nan-boxed the value to 32 bits using integer ops. It looks like flw, fsw, fmv.s, fmv.w.x, fmf.x.w won't canonicalize nans so should leave the value alone. I think those are the instructions that could get used on this value. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D98670
2021-03-30 18:34:56 +02:00
; RV32IFD-NEXT: lui a1, 1048560
; RV32IFD-NEXT: or a0, a0, a1
; RV32IFD-NEXT: fmv.w.x fa0, a0
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV32IFD-NEXT: addi sp, sp, 16
; RV32IFD-NEXT: ret
;
; RV64IFD-LABEL: fold_demote_h_d:
; RV64IFD: # %bb.0:
[RISCV] Use softPromoteHalf legalization for fp16 without Zfh rather than PromoteFloat. The default legalization strategy is PromoteFloat which keeps half in single precision format through multiple floating point operations. Conversion to/from float is done at loads, stores, bitcasts, and other places that care about the exact size being 16 bits. This patches switches to the alternative method softPromoteHalf. This aims to keep the type in 16-bit format between every operation. So we promote to float and immediately round for any arithmetic operation. This should be closer to the IR semantics since we are rounding after each operation and not accumulating extra precision across multiple operations. X86 is the only other target that enables this today. See https://reviews.llvm.org/D73749 I had to update getRegisterTypeForCallingConv to force f16 to use f32 when the F extension is enabled. This way we can still pass it in the lower bits of an FPR for ilp32f and lp64f ABIs. The softPromoteHalf would otherwise always give i16 as the argument type. Reviewed By: asb, frasercrmck Differential Revision: https://reviews.llvm.org/D99148
2021-04-01 20:47:11 +02:00
; RV64IFD-NEXT: fmv.x.d a0, fa1
; RV64IFD-NEXT: fmv.x.w a1, fa0
; RV64IFD-NEXT: lui a2, 8
; RV64IFD-NEXT: addiw a2, a2, -1
; RV64IFD-NEXT: and a1, a1, a2
; RV64IFD-NEXT: addi a2, zero, -1
; RV64IFD-NEXT: slli a2, a2, 63
; RV64IFD-NEXT: and a0, a0, a2
; RV64IFD-NEXT: srli a0, a0, 48
; RV64IFD-NEXT: or a0, a1, a0
[RISCV] Pass 'half' in the lower 16 bits of an f32 value when F extension is enabled, but Zfh is not. Without Zfh the half type isn't legal, but it could still be used as an argument/return in IR. Clang will not generate this today. Previously we promoted the half value to float for arguments and returns if the F extension is enabled but Zfh isn't. Then depending on which ABI is enabled we would pass it in either an FPR or a GPR in float format. If the F extension isn't enabled, it would get passed in the lower 16 bits of a GPR in half format. With this patch the value will always in half format and will be in the lower bits of a GPR or FPR. This should be consistent with where the bits are located when Zfh is enabled. I've based this implementation off of how this is done on ARM. I've manually nan-boxed the value to 32 bits using integer ops. It looks like flw, fsw, fmv.s, fmv.w.x, fmf.x.w won't canonicalize nans so should leave the value alone. I think those are the instructions that could get used on this value. Reviewed By: kito-cheng Differential Revision: https://reviews.llvm.org/D98670
2021-03-30 18:34:56 +02:00
; RV64IFD-NEXT: lui a1, 1048560
; RV64IFD-NEXT: or a0, a0, a1
; RV64IFD-NEXT: fmv.w.x fa0, a0
[RISCV] Support Zfh half-precision floating-point extension. Support "Zfh" extension according to https://github.com/riscv/riscv-isa-manual/blob/zfh/src/zfh.tex Differential Revision: https://reviews.llvm.org/D90738
2020-07-03 16:57:59 +02:00
; RV64IFD-NEXT: ret
;
; RV32IFZFH-LABEL: fold_demote_h_d:
; RV32IFZFH: # %bb.0:
; RV32IFZFH-NEXT: srli a0, a1, 16
; RV32IFZFH-NEXT: fmv.h.x ft0, a0
; RV32IFZFH-NEXT: fsgnj.h fa0, fa0, ft0
; RV32IFZFH-NEXT: ret
;
; RV32IFDZFH-LABEL: fold_demote_h_d:
; RV32IFDZFH: # %bb.0:
; RV32IFDZFH-NEXT: fcvt.h.d ft0, fa1
; RV32IFDZFH-NEXT: fsgnj.h fa0, fa0, ft0
; RV32IFDZFH-NEXT: ret
;
; RV64IFDZFH-LABEL: fold_demote_h_d:
; RV64IFDZFH: # %bb.0:
; RV64IFDZFH-NEXT: fcvt.h.d ft0, fa1
; RV64IFDZFH-NEXT: fsgnj.h fa0, fa0, ft0
; RV64IFDZFH-NEXT: ret
%c = fptrunc double %b to half
%t = call half @llvm.copysign.f16(half %a, half %c)
ret half %t
}
Reference in New Issue Copy Permalink