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/RISCV/float-imm.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

45 lines
1.4 KiB
LLVM
Raw Normal View History

[RISCV] Add codegen for RV32F floating point load/store As part of this, add support for load/store from the constant pool. This is used to materialise f32 constants. llvm-svn: 327979
2018-03-20 21:26:12 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc -mtriple=riscv32 -mattr=+f -verify-machineinstrs < %s \
; RUN: | FileCheck -check-prefix=RV32IF %s
[RISCV] Add RV64F codegen support This requires a little extra work due tothe fact i32 is not a legal type. When call lowering happens post-legalisation (e.g. when an intrinsic was inserted during legalisation). A bitcast from f32 to i32 can't be introduced. This is similar to the challenges with RV32D. To handle this, we introduce target-specific DAG nodes that perform bitcast+anyext for f32->i64 and trunc+bitcast for i64->f32. Differential Revision: https://reviews.llvm.org/D53235 llvm-svn: 352807
2019-02-01 06:48:38 +08:00
; RUN: llc -mtriple=riscv64 -mattr=+f -verify-machineinstrs < %s \
; RUN: | FileCheck -check-prefix=RV64IF %s
[RISCV] Add codegen for RV32F floating point load/store As part of this, add support for load/store from the constant pool. This is used to materialise f32 constants. llvm-svn: 327979
2018-03-20 21:26:12 +08:00
[RISCV] Add RV64F codegen support This requires a little extra work due tothe fact i32 is not a legal type. When call lowering happens post-legalisation (e.g. when an intrinsic was inserted during legalisation). A bitcast from f32 to i32 can't be introduced. This is similar to the challenges with RV32D. To handle this, we introduce target-specific DAG nodes that perform bitcast+anyext for f32->i64 and trunc+bitcast for i64->f32. Differential Revision: https://reviews.llvm.org/D53235 llvm-svn: 352807
2019-02-01 06:48:38 +08:00
; TODO: constant pool shouldn't be necessary for RV64IF.
[RISCV] Add codegen for RV32F floating point load/store As part of this, add support for load/store from the constant pool. This is used to materialise f32 constants. llvm-svn: 327979
2018-03-20 21:26:12 +08:00
define float @float_imm() nounwind {
; RV32IF-LABEL: float_imm:
; RV32IF: # %bb.0:
; RV32IF-NEXT: lui a0, 263313
; RV32IF-NEXT: addi a0, a0, -37
; RV32IF-NEXT: ret
[RISCV] Add RV64F codegen support This requires a little extra work due tothe fact i32 is not a legal type. When call lowering happens post-legalisation (e.g. when an intrinsic was inserted during legalisation). A bitcast from f32 to i32 can't be introduced. This is similar to the challenges with RV32D. To handle this, we introduce target-specific DAG nodes that perform bitcast+anyext for f32->i64 and trunc+bitcast for i64->f32. Differential Revision: https://reviews.llvm.org/D53235 llvm-svn: 352807
2019-02-01 06:48:38 +08:00
;
; RV64IF-LABEL: float_imm:
; RV64IF: # %bb.0:
; RV64IF-NEXT: lui a0, %hi(.LCPI0_0)
[RISCV] Support Constant Pools in Load/Store Peephole Summary: RISC-V uses a post-select peephole pass to optimise `(load/store (ADDI $reg, %lo(addr)), 0)` into `(load/store $reg, %lo(addr))`. This peephole wasn't firing for accesses to constant pools, which is how we materialise most floating point constants. This adds support for the constantpool case, which improves code generation for lots of small FP loading examples. I have not added any tests because this structure is well-covered by the `fp-imm.ll` testcases, as well as almost all other uses of floating point constants in the RISC-V backend tests. Reviewed By: luismarques, asb Differential Revision: https://reviews.llvm.org/D79523
2020-05-12 01:52:42 +08:00
; RV64IF-NEXT: flw ft0, %lo(.LCPI0_0)(a0)
[RISCV] Add RV64F codegen support This requires a little extra work due tothe fact i32 is not a legal type. When call lowering happens post-legalisation (e.g. when an intrinsic was inserted during legalisation). A bitcast from f32 to i32 can't be introduced. This is similar to the challenges with RV32D. To handle this, we introduce target-specific DAG nodes that perform bitcast+anyext for f32->i64 and trunc+bitcast for i64->f32. Differential Revision: https://reviews.llvm.org/D53235 llvm-svn: 352807
2019-02-01 06:48:38 +08:00
; RV64IF-NEXT: fmv.x.w a0, ft0
; RV64IF-NEXT: ret
[RISCV] Add codegen for RV32F floating point load/store As part of this, add support for load/store from the constant pool. This is used to materialise f32 constants. llvm-svn: 327979
2018-03-20 21:26:12 +08:00
ret float 3.14159274101257324218750
}
define float @float_imm_op(float %a) nounwind {
; RV32IF-LABEL: float_imm_op:
; RV32IF: # %bb.0:
[RISCV] Switch to the Machine Scheduler Most of the test changes are trivial instruction reorderings and differing register allocations, without any obvious performance impact. Differential Revision: https://reviews.llvm.org/D66973 llvm-svn: 372106
2019-09-17 19:15:35 +08:00
; RV32IF-NEXT: lui a1, %hi(.LCPI1_0)
[RISCV] Support Constant Pools in Load/Store Peephole Summary: RISC-V uses a post-select peephole pass to optimise `(load/store (ADDI $reg, %lo(addr)), 0)` into `(load/store $reg, %lo(addr))`. This peephole wasn't firing for accesses to constant pools, which is how we materialise most floating point constants. This adds support for the constantpool case, which improves code generation for lots of small FP loading examples. I have not added any tests because this structure is well-covered by the `fp-imm.ll` testcases, as well as almost all other uses of floating point constants in the RISC-V backend tests. Reviewed By: luismarques, asb Differential Revision: https://reviews.llvm.org/D79523
2020-05-12 01:52:42 +08:00
; RV32IF-NEXT: flw ft0, %lo(.LCPI1_0)(a1)
[RISCV] Switch to the Machine Scheduler Most of the test changes are trivial instruction reorderings and differing register allocations, without any obvious performance impact. Differential Revision: https://reviews.llvm.org/D66973 llvm-svn: 372106
2019-09-17 19:15:35 +08:00
; RV32IF-NEXT: fmv.w.x ft1, a0
; RV32IF-NEXT: fadd.s ft0, ft1, ft0
[RISCV] Add codegen for RV32F floating point load/store As part of this, add support for load/store from the constant pool. This is used to materialise f32 constants. llvm-svn: 327979
2018-03-20 21:26:12 +08:00
; RV32IF-NEXT: fmv.x.w a0, ft0
; RV32IF-NEXT: ret
[RISCV] Add RV64F codegen support This requires a little extra work due tothe fact i32 is not a legal type. When call lowering happens post-legalisation (e.g. when an intrinsic was inserted during legalisation). A bitcast from f32 to i32 can't be introduced. This is similar to the challenges with RV32D. To handle this, we introduce target-specific DAG nodes that perform bitcast+anyext for f32->i64 and trunc+bitcast for i64->f32. Differential Revision: https://reviews.llvm.org/D53235 llvm-svn: 352807
2019-02-01 06:48:38 +08:00
;
; RV64IF-LABEL: float_imm_op:
; RV64IF: # %bb.0:
[RISCV] Switch to the Machine Scheduler Most of the test changes are trivial instruction reorderings and differing register allocations, without any obvious performance impact. Differential Revision: https://reviews.llvm.org/D66973 llvm-svn: 372106
2019-09-17 19:15:35 +08:00
; RV64IF-NEXT: lui a1, %hi(.LCPI1_0)
[RISCV] Support Constant Pools in Load/Store Peephole Summary: RISC-V uses a post-select peephole pass to optimise `(load/store (ADDI $reg, %lo(addr)), 0)` into `(load/store $reg, %lo(addr))`. This peephole wasn't firing for accesses to constant pools, which is how we materialise most floating point constants. This adds support for the constantpool case, which improves code generation for lots of small FP loading examples. I have not added any tests because this structure is well-covered by the `fp-imm.ll` testcases, as well as almost all other uses of floating point constants in the RISC-V backend tests. Reviewed By: luismarques, asb Differential Revision: https://reviews.llvm.org/D79523
2020-05-12 01:52:42 +08:00
; RV64IF-NEXT: flw ft0, %lo(.LCPI1_0)(a1)
[RISCV] Switch to the Machine Scheduler Most of the test changes are trivial instruction reorderings and differing register allocations, without any obvious performance impact. Differential Revision: https://reviews.llvm.org/D66973 llvm-svn: 372106
2019-09-17 19:15:35 +08:00
; RV64IF-NEXT: fmv.w.x ft1, a0
; RV64IF-NEXT: fadd.s ft0, ft1, ft0
[RISCV] Add RV64F codegen support This requires a little extra work due tothe fact i32 is not a legal type. When call lowering happens post-legalisation (e.g. when an intrinsic was inserted during legalisation). A bitcast from f32 to i32 can't be introduced. This is similar to the challenges with RV32D. To handle this, we introduce target-specific DAG nodes that perform bitcast+anyext for f32->i64 and trunc+bitcast for i64->f32. Differential Revision: https://reviews.llvm.org/D53235 llvm-svn: 352807
2019-02-01 06:48:38 +08:00
; RV64IF-NEXT: fmv.x.w a0, ft0
; RV64IF-NEXT: ret
[RISCV] Add codegen for RV32F floating point load/store As part of this, add support for load/store from the constant pool. This is used to materialise f32 constants. llvm-svn: 327979
2018-03-20 21:26:12 +08:00
%1 = fadd float %a, 1.0
ret float %1
}