[RISCV][CodeGen] Add codegen pattern for FLI instruction in experimental zfa extension

[joshua-arch1]

Summary

This patch implements experimental support for the RISCV Zfa extension as specified here: https://github.com/riscv/riscv-isa-manual/releases/download/draft-20221119-5234c63/riscv-spec.pdf, Ch. 25. This extension has not been ratified. Once ratified, it'll move out of experimental status.

This change adds codegen support for load-immediate instructions (fli.s/fli.d/fli.h).

[joshua-arch1]

Since the assmebly support patch for Zfa instructions except FLI has been accepted, could anyone please review this codegen patch?

[craig.topper]

llvm/lib/Target/RISCV/RISCVISelLowering.cpp

1501–1514

I think we can't reach this line when Zfa is enabled now? getLoadFP32Imm/getLoadFP64Imm/getLoadFP16Imm return -1 for 0.0 and -0.0 right?

2025

FCVTMOD does not saturate. It returns the lower bits of the overflowed value. These instruction cannot be used to lower saturating conversion.

3837

Does this need to be qualified with Zfa?

8055

Does this need to be qualified with Zfa?

llvm/lib/Target/RISCV/RISCVISelLowering.h

114 ↗

(On Diff #493508)

This description is incorrect. The FCVTMOD instructions do not saturate.

llvm/lib/Target/RISCV/RISCVInstrInfoZfa.td

138

This name is misleading. There is no fmvh.x.w instruction. FMV_X_W_FPR64 would be better.

174

Why do you need a COPY_TO_REGCLASS?

191

What is giving these patterns priority over the ones in RISCVInstrInfoF.td?

llvm/test/CodeGen/RISCV/double-zfa.ll

108

This doesn't look like the minimum value for normal value for double. I would expect the mantissa bits to be 0.

So it should be 0x0010000000000000 I think?

llvm/test/CodeGen/RISCV/rvv/fixed-vectors-bitcast.ll

422 ↗

(On Diff #493508)

Why does this test change? It doesn't use Zfa.

[craig.topper]

llvm/lib/Target/RISCV/RISCVInstrInfoZfa.td

191

I think this works because patterns with UsesCustomInserter=1 have lower priority than patterns that don't use CustomInserter.

[craig.topper]

llvm/lib/Target/RISCV/RISCVISelLowering.cpp

1502

This needs to be rebased.

llvm/lib/Target/RISCV/RISCVInstrInfoZfa.td

160

This isn't a "bitcast". It's an encoding conversion.

fpimm is now handled with custom code in RISCVISelDAGToDAG.cpp so this needs to be moved there.

[reames]

In D141560#4120971, @joshua-arch1 wrote:

Since the assmebly support patch for Zfa instructions except FLI has been accepted, could anyone please review this codegen patch?

I'd encourage you to land the underlying approved review. I can't speak for others, but I certainty prioritize review for changes which have fewer outstanding blocking issues. You could also split this into an FLI and non-FLI part with the same reasoning.

[joshua-arch1]

In D141560#4122948, @reames wrote:

In D141560#4120971, @joshua-arch1 wrote:

Since the assmebly support patch for Zfa instructions except FLI has been accepted, could anyone please review this codegen patch?

I'd encourage you to land the underlying approved review. I can't speak for others, but I certainty prioritize review for changes which have fewer outstanding blocking issues. You could also split this into an FLI and non-FLI part with the same reasoning.

Different from assembly support, I think there is nothing special with the codegen pattern for FLI instruction. It's unnecessory to split the codegen patch into an FLI and non-FLI part.

llvm/lib/Target/RISCV/RISCVISelLowering.cpp

2025

So what's the difference between FCVTMOD and normal FP_TO_INT? Is NaN converted to zero in normal FP_TO_INT?

2025

What instruction sequence does FCVTMOD need to replace? I'm a bit confused.

llvm/test/CodeGen/RISCV/double-zfa.ll

108

It is IR syntax. I have written a simple case to confirm that this value is used to express 0x0010000000000000 in IR level.

[craig.topper]

In D141560#4124863, @joshua-arch1 wrote:

In D141560#4122948, @reames wrote:

In D141560#4120971, @joshua-arch1 wrote:

Since the assmebly support patch for Zfa instructions except FLI has been accepted, could anyone please review this codegen patch?

I'd encourage you to land the underlying approved review. I can't speak for others, but I certainty prioritize review for changes which have fewer outstanding blocking issues. You could also split this into an FLI and non-FLI part with the same reasoning.

Different from assembly support, I think there is nothing special with the codegen pattern for FLI instruction. It's unnecessory to split the codegen patch into an FLI and non-FLI part.

The suggestion to split is to unblock parts of the patch. We would rather have small pieces make progress than stalling a whole patch when one part of it that can be isolated needs additional work. Smaller patches are much easier to review and re-review.

llvm/lib/Target/RISCV/RISCVISelLowering.cpp

2025

FCVTMOD follows the semantics of JavaScript. It’s for being able writing JavaScript JITs for RISC-V. It’s not useful for C or Rust.

llvm/test/CodeGen/RISCV/double-zfa.ll

108

It’s the IR syntax for double just the hex representation of double.

[joshua-arch1]

In D141560#4124967, @craig.topper wrote:

In D141560#4124863, @joshua-arch1 wrote:

In D141560#4122948, @reames wrote:

In D141560#4120971, @joshua-arch1 wrote:

Since the assmebly support patch for Zfa instructions except FLI has been accepted, could anyone please review this codegen patch?

I'd encourage you to land the underlying approved review. I can't speak for others, but I certainty prioritize review for changes which have fewer outstanding blocking issues. You could also split this into an FLI and non-FLI part with the same reasoning.

Different from assembly support, I think there is nothing special with the codegen pattern for FLI instruction. It's unnecessory to split the codegen patch into an FLI and non-FLI part.

The suggestion to split is to unblock parts of the patch. We would rather have small pieces make progress than stalling a whole patch when one part of it that can be isolated needs additional work. Smaller patches are much easier to review and re-review.

I see. I will split these patch into three small ones. One for FLI, one for FCVMOD and another for other instructions.

[joshua-arch1]

Codegen patch for instructions except FLI and FCVTMOD has been commited. https://reviews.llvm.org/D143982

[reames]

In D141560#4125173, @joshua-arch1 wrote:

Codegen patch for instructions except FLI and FCVTMOD has been commited. https://reviews.llvm.org/D143982

Important English point here. The patch has been *posted* not *committed*. Saying it's committed means that it was landed to the git repository. That appears to not be what you meant, and was actively confusing in this case.

[craig.topper]

llvm/test/CodeGen/RISCV/float-zfa.ll

123

Why 255.0? Is this a negative test?

[joshua-arch1]

Ping.

llvm/test/CodeGen/RISCV/float-zfa.ll

123

Yep. I just want to ensure load floating-point immediates of other values will not generate FLI.

[craig.topper]

LGTM

[joshua-arch1]

In D141560#4137896, @craig.topper wrote:

LGTM

This CodeGen patch depends on some functions in https://reviews.llvm.org/D140460.

[craig.topper]

This comment was removed by craig.topper.

[craig.topper]

llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp

711

Why was this isPosZero check added? It wasn't there when the patch was approved.

[joshua-arch1]

Anyone knows how to generate FLI from C-code? If I compile the following program, I cannot get FlI. ConstantFP will be converted to Constant in DAG.

void foo_double64 ()
{
  volatile double a;
  a = 0.0625;
}

llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp

711

Just in order to make sure loading +0.0 will not use fli.s.

[craig.topper]

In D141560#4198220, @joshua-arch1 wrote:

Anyone knows how to generate FLI from C-code? If I compile the following program, I cannot get FlI. ConstantFP will be converted to Constant in DAG.

void foo_double64 ()
{
  volatile double a;
  a = 0.0625;
}

You just need to use it to do some floating point arithmetic

void foo_double64 (double x)
{
  volatile double a;
  a = x + 0.0625;
}

or return a floating point value

double foo_double64 ()
{
  return 0.0625;
}

llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp

711

But why treat fli.s different than fli.h or fli.d?

[joshua-arch1]

In D141560#4198233, @craig.topper wrote:

In D141560#4198220, @joshua-arch1 wrote:

Anyone knows how to generate FLI from C-code? If I compile the following program, I cannot get FlI. ConstantFP will be converted to Constant in DAG.

void foo_double64 ()
{
  volatile double a;
  a = 0.0625;
}

You just need to use it to do some floating point arithmetic

void foo_double64 (double x)
{
  volatile double a;
  a = x + 0.0625;
}

or return a floating point value

double foo_double64 ()
{
  return 0.0625;
}

Is that because we cannot directly store a ConstantFP in DAG?

[craig.topper]

In D141560#4198252, @joshua-arch1 wrote:

In D141560#4198233, @craig.topper wrote:

In D141560#4198220, @joshua-arch1 wrote:

Anyone knows how to generate FLI from C-code? If I compile the following program, I cannot get FlI. ConstantFP will be converted to Constant in DAG.

void foo_double64 ()
{
  volatile double a;
  a = 0.0625;
}

You just need to use it to do some floating point arithmetic

void foo_double64 (double x)
{
  volatile double a;
  a = x + 0.0625;
}

or return a floating point value

double foo_double64 ()
{
  return 0.0625;
}

Is that because we cannot directly store a ConstantFP in DAG?

The change is done in DAGCombiner::replaceStoreOfFPConstant. I think the idea is that FP constants are usually harder to create in registers than integer constants. Also CPUs usually have more integer resources than FP resources. It doesn't look like it can be disabled currently. I think all of the constants FLI handles can be done in 1 or 2 integer instructions so I'm not very concerned about this. It was more than that I might be concerned.

[joshua-arch1]

This comment was removed by joshua-arch1.

[joshua-arch1]

In D141560#4198257, @craig.topper wrote:

In D141560#4198252, @joshua-arch1 wrote:

In D141560#4198233, @craig.topper wrote:

In D141560#4198220, @joshua-arch1 wrote:

Anyone knows how to generate FLI from C-code? If I compile the following program, I cannot get FlI. ConstantFP will be converted to Constant in DAG.

void foo_double64 ()
{
  volatile double a;
  a = 0.0625;
}

You just need to use it to do some floating point arithmetic

void foo_double64 (double x)
{
  volatile double a;
  a = x + 0.0625;
}

or return a floating point value

double foo_double64 ()
{
  return 0.0625;
}

Is that because we cannot directly store a ConstantFP in DAG?

The change is done in DAGCombiner::replaceStoreOfFPConstant. I think the idea is that FP constants are usually harder to create in registers than integer constants. Also CPUs usually have more integer resources than FP resources. It doesn't look like it can be disabled currently. I think all of the constants FLI handles can be done in 1 or 2 integer instructions so I'm not very concerned about this. It was more than that I might be concerned.

Will one FLI instruction have less cycles and perform better than two integer instructions?

[craig.topper]

In D141560#4201276, @joshua-arch1 wrote:

In D141560#4198257, @craig.topper wrote:

In D141560#4198252, @joshua-arch1 wrote:

In D141560#4198233, @craig.topper wrote:

In D141560#4198220, @joshua-arch1 wrote:

Anyone knows how to generate FLI from C-code? If I compile the following program, I cannot get FlI. ConstantFP will be converted to Constant in DAG.

void foo_double64 ()
{
  volatile double a;
  a = 0.0625;
}

You just need to use it to do some floating point arithmetic

void foo_double64 (double x)
{
  volatile double a;
  a = x + 0.0625;
}

or return a floating point value

double foo_double64 ()
{
  return 0.0625;
}

Is that because we cannot directly store a ConstantFP in DAG?

The change is done in DAGCombiner::replaceStoreOfFPConstant. I think the idea is that FP constants are usually harder to create in registers than integer constants. Also CPUs usually have more integer resources than FP resources. It doesn't look like it can be disabled currently. I think all of the constants FLI handles can be done in 1 or 2 integer instructions so I'm not very concerned about this. It was more than that I might be concerned.

Will one FLI instruction have less cycles and perform better than two integer instructions?

Maybe, but it will probably be microarchitecture dependent.

Delaying a store by an extra cycle doesn't seem like a big deal. Other instructions don't directly depend on a store except later loads. The compiler would often be able to see the load is to the same location as the store and forward the data without the load.

If we're storing the same value in a loop we should be hoisting the 2 integer instructions out of the loop. So they wouldn't be executed many times.

[joshua-arch1]

Maybe, but it will probably be microarchitecture dependent.

Delaying a store by an extra cycle doesn't seem like a big deal. Other instructions don't directly depend on a store except later loads. The compiler would often be able to see the load is to the same location as the store and forward the data without the load.

If we're storing the same value in a loop we should be hoisting the 2 integer instructions out of the loop. So they wouldn't be executed many times.

Even if we disable replaceStoreOfFPConstant in DAGCombiner, FP constant will still be converted to integer in OptimizeFloatStore() when legalizing.

[joshua-arch1]

This comment was removed by joshua-arch1.

[craig.topper]

In D141560#4212001, @joshua-arch1 wrote:

In D141560#4198257, @craig.topper wrote:

In D141560#4198252, @joshua-arch1 wrote:

In D141560#4198233, @craig.topper wrote:

In D141560#4198220, @joshua-arch1 wrote:

Anyone knows how to generate FLI from C-code? If I compile the following program, I cannot get FlI. ConstantFP will be converted to Constant in DAG.

void foo_double64 ()
{
  volatile double a;
  a = 0.0625;
}

You just need to use it to do some floating point arithmetic

void foo_double64 (double x)
{
  volatile double a;
  a = x + 0.0625;
}

or return a floating point value

double foo_double64 ()
{
  return 0.0625;
}

Is that because we cannot directly store a ConstantFP in DAG?

The change is done in DAGCombiner::replaceStoreOfFPConstant. I think the idea is that FP constants are usually harder to create in registers than integer constants. Also CPUs usually have more integer resources than FP resources. It doesn't look like it can be disabled currently. I think all of the constants FLI handles can be done in 1 or 2 integer instructions so I'm not very concerned about this. It was more than that I might be concerned.

For rv64 in O0, replaceStoreOfFPConstant will not convert FP constant into integers. However, for rv32, FP constant will be changed to integers both in O0 and O2. Is there any special consideration?

I can see that it won't ever do it for f32 on rv64 because it doesn't consider the possibility of using an i32 store when i32 isn't a legal type.

Beyond that I would need to see your test cases.

llvm/lib/Target/RISCV/RISCVISelDAGToDAG.cpp

case ISD::Constant: {
     if (!isInt<32>(Imm) && isUInt<32>(Imm) && hasAllWUsers(Node))
       Imm = SignExtend64<32>(Imm);
 
     ReplaceNode(Node, selectImm(CurDAG, DL, VT, Imm, *Subtarget).getNode());
     return;
   }
   case ISD::ConstantFP: {
     const APFloat &APF = cast<ConstantFPSDNode>(Node)->getValueAPF();
+    if (Subtarget->hasStdExtZfa()) {
+      if ((VT == MVT::f32 && RISCVLoadFPImm::getLoadFP32Imm(APF) != -1) || 
+          (VT == MVT::f64 && RISCVLoadFPImm::getLoadFP64Imm(APF) != -1) ||
+          (VT == MVT::f16 && RISCVLoadFPImm::getLoadFP16Imm(APF) != -1))
+        break;
+    }
+    
     bool NegZeroF64 = APF.isNegZero() && VT == MVT::f64;
     SDValue Imm;
     // For +0.0 or f64 -0.0 we need to start from X0. For all others, we will
     // create an integer immediate.
     if (APF.isPosZero() || NegZeroF64)
       Imm = CurDAG->getRegister(RISCV::X0, XLenVT);
     else
       Imm = selectImm(CurDAG, DL, XLenVT, APF.bitcastToAPInt().getSExtValue(),

llvm/lib/Target/RISCV/RISCVISelLowering.cpp

bool RISCVTargetLowering::isOffsetFoldingLegal(
   // keep a separate ADD node for the global address offset instead of folding
   // it in the global address node. Later peephole optimisations may choose to
   // fold it back in when profitable.
   return false;
 }
 
 bool RISCVTargetLowering::isFPImmLegal(const APFloat &Imm, EVT VT,
                                        bool ForCodeSize) const {
+  if (Subtarget.hasStdExtZfa()) {
+    if ((VT == MVT::f32 && RISCVLoadFPImm::getLoadFP32Imm(Imm) != -1) || 
+        (VT == MVT::f64 && RISCVLoadFPImm::getLoadFP64Imm(Imm) != -1) ||
+        (VT == MVT::f16 && RISCVLoadFPImm::getLoadFP16Imm(Imm) != -1))
+      return true;
+  }
+  
   if (VT == MVT::f16 && !Subtarget.hasStdExtZfhOrZfhmin())
     return false;
   if (VT == MVT::f32 && !Subtarget.hasStdExtF())
     return false;
   if (VT == MVT::f64 && !Subtarget.hasStdExtD())
     return false;
   // Cannot create a 64 bit floating-point immediate value for rv32.
   if (Subtarget.getXLen() < VT.getScalarSizeInBits()) {
     // td can handle +0.0 or -0.0 already.
     // -0.0 can be created by fmv + fneg.
     return Imm.isZero();
   }
   // Special case: the cost for -0.0 is 1.
   int Cost = Imm.isNegZero()
                  ? 1
                  : RISCVMatInt::getIntMatCost(Imm.bitcastToAPInt(),
                                               Subtarget.getXLen(),
                                               Subtarget.getFeatureBits());
   // If the constantpool data is already in cache, only Cost 1 is cheaper.
   return Cost < FPImmCost;
 }
 
 // TODO: This is very conservative.
 bool RISCVTargetLowering::isExtractSubvectorCheap(EVT ResVT, EVT SrcVT,
                                                   unsigned Index) const {
   if (!isOperationLegalOrCustom(ISD::EXTRACT_SUBVECTOR, ResVT))
     return false;
 
if (!DstVT.isVector()) {
     if (Src.getSimpleValueType() == MVT::f16 && !Subtarget.hasStdExtZfh()) {
       Src = DAG.getNode(ISD::FP_EXTEND, SDLoc(Op), MVT::f32, Src);
     }
 
     unsigned Opc;
     if (SatVT == DstVT)
       Opc = IsSigned ? RISCVISD::FCVT_X : RISCVISD::FCVT_XU;
     else if (DstVT == MVT::i64 && SatVT == MVT::i32)
       Opc = IsSigned ? RISCVISD::FCVT_W_RV64 : RISCVISD::FCVT_WU_RV64;
     else
       return SDValue();
     // FIXME: Support other SatVTs by clamping before or after the conversion.
 
     SDLoc DL(Op);
     SDValue FpToInt = DAG.getNode(
         Opc, DL, DstVT, Src,
         DAG.getTargetConstant(RISCVFPRndMode::RTZ, DL, Subtarget.getXLenVT()));
case ISD::BITCAST: {
     }
     if (VT == MVT::f32 && Op0VT == MVT::i32 && Subtarget.is64Bit() &&
         Subtarget.hasStdExtF()) {
       SDValue NewOp0 = DAG.getNode(ISD::ANY_EXTEND, DL, MVT::i64, Op0);
       SDValue FPConv =
           DAG.getNode(RISCVISD::FMV_W_X_RV64, DL, MVT::f32, NewOp0);
       return FPConv;
     }
     if (VT == MVT::f64 && Op0VT == MVT::i64 && XLenVT == MVT::i32 &&
         Subtarget.hasStdExtZfa()) {
       SDValue Lo = DAG.getNode(ISD::EXTRACT_ELEMENT, DL, MVT::i32, Op0,
                                DAG.getConstant(0, DL, MVT::i32));
       SDValue Hi = DAG.getNode(ISD::EXTRACT_ELEMENT, DL, MVT::i32, Op0,
                                DAG.getConstant(1, DL, MVT::i32));
       SDValue RetReg =
           DAG.getNode(RISCVISD::BuildPairF64, DL, MVT::f64, Lo, Hi);
       return RetReg;
if (VT == MVT::i16 && Op0VT == MVT::f16 &&
         Subtarget.hasStdExtZfhOrZfhmin()) {
       SDValue FPConv = DAG.getNode(RISCVISD::FMV_X_ANYEXTH, DL, XLenVT, Op0);
       Results.push_back(DAG.getNode(ISD::TRUNCATE, DL, MVT::i16, FPConv));
     } else if (VT == MVT::i32 && Op0VT == MVT::f32 && Subtarget.is64Bit() &&
                Subtarget.hasStdExtF()) {
       SDValue FPConv =
           DAG.getNode(RISCVISD::FMV_X_ANYEXTW_RV64, DL, MVT::i64, Op0);
       Results.push_back(DAG.getNode(ISD::TRUNCATE, DL, MVT::i32, FPConv));
     } else if (VT == MVT::i64 && Op0VT == MVT::f64 && XLenVT == MVT::i32 &&
                Subtarget.hasStdExtZfa()) {
         SDValue NewReg = DAG.getNode(RISCVISD::SplitF64, DL,
                                      DAG.getVTList(MVT::i32, MVT::i32), Op0);
         SDValue Lo = NewReg.getValue(0);
         SDValue Hi = NewReg.getValue(1);
         SDValue RetReg = DAG.getNode(ISD::BUILD_PAIR, DL, MVT::i64, Lo, Hi);
         Results.push_back(RetReg);
     } else if (!VT.isVector() && Op0VT.isFixedLengthVector() &&

llvm/lib/Target/RISCV/RISCVInstrInfoZfa.td

 def FMVH_X_D : FPUnaryOp_r<0b1110001, 0b00001, 0b000, GPR, FPR64, "fmvh.x.d">,
                Sched<[WriteFMovF32ToI32, ReadFMovF32ToI32]>;
 def FMVP_D_X : FPBinaryOp_rr<0b1011001, 0b000, FPR64, GPR, "fmvp.d.x">,
                Sched<[WriteFMovI32ToF32, ReadFMovI32ToF32]>;
 let isCodeGenOnly = 1, mayRaiseFPException = 0 in {
     def FMV_X_W_FPR64 : FPUnaryOp_r<0b1110000, 0b00000, 0b000, GPR, FPR64, "fmv.x.w">,
                         Sched<[WriteFMovF32ToI32, ReadFMovF32ToI32]>;
 }
 } // Predicates = [HasStdExtZfa, HasStdExtD, IsRV32]
 
 let Predicates = [HasStdExtZfa, HasStdExtZfh] in {
 def FLI_H : FPUnaryOp_imm<0b1111010, 0b00001, 0b000, OPC_OP_FP, (outs FPR16:$rd),
             (ins loadfp16imm:$imm), "fli.h", "$rd, $imm">,
             Sched<[WriteFMovI16ToF16, ReadFMovI16ToF16]>;
 
 def FMINM_H: FPALU_rr<0b0010110, 0b010, "fminm.h", FPR16, /*Commutable*/ 1>;
 def FMAXM_H: FPALU_rr<0b0010110, 0b011, "fmaxm.h", FPR16, /*Commutable*/ 1>;
 
 def FROUND_H : FPUnaryOp_r_frm<0b0100010, 0b00100, FPR16, FPR16, "fround.h">;
 def FROUNDNX_H : FPUnaryOp_r_frm<0b0100010, 0b00101, FPR16, FPR16, "froundnx.h">;
 
 def FLTQ_H : FPCmp_rr<0b1010010, 0b101, "fltq.h", FPR16, /*Commutable*/ 1>;
 def FLEQ_H : FPCmp_rr<0b1010010, 0b100, "fleq.h", FPR16, /*Commutable*/ 1>;
 } // Predicates = [HasStdExtZfa, HasStdExtZfh]
 
 
 //===----------------------------------------------------------------------===//
 // Codegen patterns
 //===----------------------------------------------------------------------===//
 
+def fp32imm_to_loadfpimm : SDNodeXForm<fpimm, [{
+  return CurDAG->getTargetConstant(RISCVLoadFPImm::getLoadFP32Imm(N->getValueAPF()), 
+                                   SDLoc(N), Subtarget->getXLenVT());}]>;
+
+def fp64imm_to_loadfpimm : SDNodeXForm<fpimm, [{
+  return CurDAG->getTargetConstant(RISCVLoadFPImm::getLoadFP64Imm(N->getValueAPF()), 
+                                   SDLoc(N), Subtarget->getXLenVT());}]>;
+
+def fp16imm_to_loadfpimm : SDNodeXForm<fpimm, [{
+  return CurDAG->getTargetConstant(RISCVLoadFPImm::getLoadFP16Imm(N->getValueAPF()), 
+                                   SDLoc(N), Subtarget->getXLenVT());}]>;
+
 let Predicates = [HasStdExtZfa] in {
+def : Pat<(f32 fpimm:$imm), (FLI_S (fp32imm_to_loadfpimm fpimm:$imm))>;
+
 def: PatFprFpr<fminimum, FMINM_S, FPR32>;
 def: PatFprFpr<fmaximum, FMAXM_S, FPR32>;
 
 // frint rounds according to the current rounding mode and detects
 // inexact conditions.
 def: Pat<(any_frint FPR32 : $rs1), (FROUNDNX_S FPR32 : $rs1, 0b111)>;
 
 // fnearbyint is like frint but does not detect inexact conditions.
 def: Pat<(any_fnearbyint FPR32 : $rs1), (FROUND_S FPR32 : $rs1, 0b111)>;
 
 def: Pat<(any_fround FPR32 : $rs1), (FROUND_S FPR32 : $rs1, 0b100)>;
 def: Pat<(any_ffloor FPR32 : $rs1), (FROUND_S FPR32 : $rs1, 0b011)>;
 def: Pat<(any_fceil FPR32 : $rs1), (FROUND_S FPR32 : $rs1, 0b010)>;
 def: Pat<(any_ftrunc FPR32 : $rs1), (FROUND_S FPR32 : $rs1, 0b001)>;
 
 def: PatSetCC<FPR32, strict_fsetcc, SETLT, FLTQ_S>;
 def: PatSetCC<FPR32, strict_fsetcc, SETOLT, FLTQ_S>;
 def: PatSetCC<FPR32, strict_fsetcc, SETLE, FLEQ_S>;
 def: PatSetCC<FPR32, strict_fsetcc, SETOLE, FLEQ_S>;
 } // Predicates = [HasStdExtZfa]
 
 let Predicates = [HasStdExtZfa, HasStdExtD] in {
+def : Pat<(f64 fpimm:$imm), (FLI_D (fp64imm_to_loadfpimm fpimm:$imm))>;
+
 def: PatFprFpr<fminimum, FMINM_D, FPR64>;
 def: PatFprFpr<fmaximum, FMAXM_D, FPR64>;
 
 // frint rounds according to the current rounding mode and detects
 // inexact conditions.
 def: Pat<(any_frint FPR64 : $rs1), (FROUNDNX_D FPR64 : $rs1, 0b111)>;
 
 // fnearbyint is like frint but does not detect inexact conditions.
 def: Pat<(any_fnearbyint FPR64 : $rs1), (FROUND_D FPR64 : $rs1, 0b111)>;
 
 def: Pat<(any_fround FPR64 : $rs1), (FROUND_D FPR64 : $rs1, 0b100)>;
 def: Pat<(any_froundeven FPR64 : $rs1), (FROUND_D FPR64 : $rs1, 0b000)>;
 def: Pat<(any_ffloor FPR64 : $rs1), (FROUND_D FPR64 : $rs1, 0b011)>;
 def: Pat<(any_fceil FPR64 : $rs1), (FROUND_D FPR64 : $rs1, 0b010)>;
 def: Pat<(any_ftrunc FPR64 : $rs1), (FROUND_D FPR64 : $rs1, 0b001)>;
 
 def: PatSetCC<FPR64, strict_fsetcc, SETLT, FLTQ_D>;
 def: PatSetCC<FPR64, strict_fsetcc, SETOLT, FLTQ_D>;
 def: PatSetCC<FPR64, strict_fsetcc, SETLE, FLEQ_D>;
 def: PatSetCC<FPR64, strict_fsetcc, SETOLE, FLEQ_D>;
 } // Predicates = [HasStdExtZfa, HasStdExtD]
 
 let Predicates = [HasStdExtZfa, HasStdExtZfh] in {
+def : Pat<(f16 fpimm:$imm), (FLI_H (fp16imm_to_loadfpimm fpimm:$imm))>;
+
 def: PatFprFpr<fminimum, FMINM_H, FPR16>;
 def: PatFprFpr<fmaximum, FMAXM_H, FPR16>;
 
 // frint rounds according to the current rounding mode and detects
 // inexact conditions.
 def: Pat<(any_frint FPR16 : $rs1), (FROUNDNX_H FPR16 : $rs1, 0b111)>;
 
 // fnearbyint is like frint but does not detect inexact conditions.

llvm/test/CodeGen/RISCV/double-zfa.ll

 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
 ; RUN: llc -mtriple=riscv32 -target-abi ilp32d -mattr=+experimental-zfa,+d < %s \
 ; RUN:     | FileCheck --check-prefix=RV32IDZFA %s
 ; RUN: llc -mtriple=riscv64 -target-abi lp64d -mattr=+experimental-zfa,+d < %s \
 ; RUN:     | FileCheck --check-prefix=RV64DZFA %s
 
+define double @loadfpimm1() {
+; RV32IDZFA-LABEL: loadfpimm1:
+; RV32IDZFA:       # %bb.0:
+; RV32IDZFA-NEXT:    fli.d fa0, 6.250000e-02
+; RV32IDZFA-NEXT:    ret
+;
+; RV64DZFA-LABEL: loadfpimm1:
+; RV64DZFA:       # %bb.0:
+; RV64DZFA-NEXT:    fli.d fa0, 6.250000e-02
+; RV64DZFA-NEXT:    ret
+  ret double 0.0625
+}
+
+define double @loadfpimm2() {
+; RV32IDZFA-LABEL: loadfpimm2:
+; RV32IDZFA:       # %bb.0:
+; RV32IDZFA-NEXT:    fli.d fa0, 7.500000e-01
+; RV32IDZFA-NEXT:    ret
+;
+; RV64DZFA-LABEL: loadfpimm2:
+; RV64DZFA:       # %bb.0:
+; RV64DZFA-NEXT:    fli.d fa0, 7.500000e-01
+; RV64DZFA-NEXT:    ret
+  ret double 0.75
+}
+
+define double @loadfpimm3() {
+; RV32IDZFA-LABEL: loadfpimm3:
+; RV32IDZFA:       # %bb.0:
+; RV32IDZFA-NEXT:    fli.d fa0, 1.250000e+00
+; RV32IDZFA-NEXT:    ret
+;
+; RV64DZFA-LABEL: loadfpimm3:
+; RV64DZFA:       # %bb.0:
+; RV64DZFA-NEXT:    fli.d fa0, 1.250000e+00
+; RV64DZFA-NEXT:    ret
+  ret double 1.25
+}
+
+define double @loadfpimm4() {
+; RV32IDZFA-LABEL: loadfpimm4:
+; RV32IDZFA:       # %bb.0:
+; RV32IDZFA-NEXT:    fli.d fa0, 3.000000e+00
+; RV32IDZFA-NEXT:    ret
+;
+; RV64DZFA-LABEL: loadfpimm4:
+; RV64DZFA:       # %bb.0:
+; RV64DZFA-NEXT:    fli.d fa0, 3.000000e+00
+; RV64DZFA-NEXT:    ret
+  ret double 3.0
+}
+
+define double @loadfpimm5() {
+; RV32IDZFA-LABEL: loadfpimm5:
+; RV32IDZFA:       # %bb.0:
+; RV32IDZFA-NEXT:    fli.d fa0, 2.560000e+02
+; RV32IDZFA-NEXT:    ret
+;
+; RV64DZFA-LABEL: loadfpimm5:
+; RV64DZFA:       # %bb.0:
+; RV64DZFA-NEXT:    fli.d fa0, 2.560000e+02
+; RV64DZFA-NEXT:    ret
+  ret double 256.0
+}
+
+define double @loadfpimm6() {
+; RV32IDZFA-LABEL: loadfpimm6:
+; RV32IDZFA:       # %bb.0:
+; RV32IDZFA-NEXT:    fli.d fa0, inf
+; RV32IDZFA-NEXT:    ret
+;
+; RV64DZFA-LABEL: loadfpimm6:
+; RV64DZFA:       # %bb.0:
+; RV64DZFA-NEXT:    fli.d fa0, inf
+; RV64DZFA-NEXT:    ret
+  ret double 0x7FF0000000000000
+}
+
+define double @loadfpimm7() {
+; RV32IDZFA-LABEL: loadfpimm7:
+; RV32IDZFA:       # %bb.0:
+; RV32IDZFA-NEXT:    fli.d fa0, nan
+; RV32IDZFA-NEXT:    ret
+;
+; RV64DZFA-LABEL: loadfpimm7:
+; RV64DZFA:       # %bb.0:
+; RV64DZFA-NEXT:    fli.d fa0, nan
+; RV64DZFA-NEXT:    ret
+  ret double 0x7FF8000000000000
+}
+
+define double @loadfpimm8() {
+; RV32IDZFA-LABEL: loadfpimm8:
+; RV32IDZFA:       # %bb.0:
+; RV32IDZFA-NEXT:    fli.d fa0, min
+; RV32IDZFA-NEXT:    ret
+;
+; RV64DZFA-LABEL: loadfpimm8:
+; RV64DZFA:       # %bb.0:
+; RV64DZFA-NEXT:    fli.d fa0, min
+; RV64DZFA-NEXT:    ret
+  ret double 0x0010000000000000
+}
+
+define double @loadfpimm9() {
+; RV32IDZFA-LABEL: loadfpimm9:
+; RV32IDZFA:       # %bb.0:
+; RV32IDZFA-NEXT:    lui a0, %hi(.LCPI8_0)
+; RV32IDZFA-NEXT:    fld fa0, %lo(.LCPI8_0)(a0)
+; RV32IDZFA-NEXT:    ret
+;
+; RV64DZFA-LABEL: loadfpimm9:
+; RV64DZFA:       # %bb.0:
+; RV64DZFA-NEXT:    lui a0, %hi(.LCPI8_0)
+; RV64DZFA-NEXT:    fld fa0, %lo(.LCPI8_0)(a0)
+; RV64DZFA-NEXT:    ret
+  ret double 255.0
+}
+
 declare double @llvm.minimum.f64(double, double)
 
 define double @fminm_d(double %a, double %b) nounwind {
 ; RV32IDZFA-LABEL: fminm_d:
 ; RV32IDZFA:       # %bb.0:
 ; RV32IDZFA-NEXT:    fminm.d fa0, fa0, fa1
 ; RV32IDZFA-NEXT:    ret
 ;

llvm/test/CodeGen/RISCV/float-zfa.ll

 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
 ; RUN: llc -mtriple=riscv32 -target-abi ilp32f -mattr=+experimental-zfa < %s \
 ; RUN:     | FileCheck --check-prefix=RV32IZFA %s
 ; RUN: llc -mtriple=riscv64 -target-abi lp64f -mattr=+experimental-zfa < %s \
 ; RUN:     | FileCheck --check-prefix=RV64IZFA %s
 
+define float @loadfpimm1() {
+; RV32IZFA-LABEL: loadfpimm1:
+; RV32IZFA:       # %bb.0:
+; RV32IZFA-NEXT:    fli.s fa0, 6.250000e-02
+; RV32IZFA-NEXT:    ret
+;
+; RV64IZFA-LABEL: loadfpimm1:
+; RV64IZFA:       # %bb.0:
+; RV64IZFA-NEXT:    fli.s fa0, 6.250000e-02
+; RV64IZFA-NEXT:    ret
+  ret float 0.0625
+}
+
+define float @loadfpimm2() {
+; RV32IZFA-LABEL: loadfpimm2:
+; RV32IZFA:       # %bb.0:
+; RV32IZFA-NEXT:    fli.s fa0, 7.500000e-01
+; RV32IZFA-NEXT:    ret
+;
+; RV64IZFA-LABEL: loadfpimm2:
+; RV64IZFA:       # %bb.0:
+; RV64IZFA-NEXT:    fli.s fa0, 7.500000e-01
+; RV64IZFA-NEXT:    ret
+  ret float 0.75
+}
+
+define float @loadfpimm3() {
+; RV32IZFA-LABEL: loadfpimm3:
+; RV32IZFA:       # %bb.0:
+; RV32IZFA-NEXT:    fli.s fa0, 1.250000e+00
+; RV32IZFA-NEXT:    ret
+;
+; RV64IZFA-LABEL: loadfpimm3:
+; RV64IZFA:       # %bb.0:
+; RV64IZFA-NEXT:    fli.s fa0, 1.250000e+00
+; RV64IZFA-NEXT:    ret
+  ret float 1.25
+}
+
+define float @loadfpimm4() {
+; RV32IZFA-LABEL: loadfpimm4:
+; RV32IZFA:       # %bb.0:
+; RV32IZFA-NEXT:    fli.s fa0, 3.000000e+00
+; RV32IZFA-NEXT:    ret
+;
+; RV64IZFA-LABEL: loadfpimm4:
+; RV64IZFA:       # %bb.0:
+; RV64IZFA-NEXT:    fli.s fa0, 3.000000e+00
+; RV64IZFA-NEXT:    ret
+  ret float 3.0
+}
+
+define float @loadfpimm5() {
+; RV32IZFA-LABEL: loadfpimm5:
+; RV32IZFA:       # %bb.0:
+; RV32IZFA-NEXT:    fli.s fa0, 2.560000e+02
+; RV32IZFA-NEXT:    ret
+;
+; RV64IZFA-LABEL: loadfpimm5:
+; RV64IZFA:       # %bb.0:
+; RV64IZFA-NEXT:    fli.s fa0, 2.560000e+02
+; RV64IZFA-NEXT:    ret
+  ret float 256.0
+}
+
+define float @loadfpimm6() {
+; RV32IZFA-LABEL: loadfpimm6:
+; RV32IZFA:       # %bb.0:
+; RV32IZFA-NEXT:    fli.s fa0, inf
+; RV32IZFA-NEXT:    ret
+;
+; RV64IZFA-LABEL: loadfpimm6:
+; RV64IZFA:       # %bb.0:
+; RV64IZFA-NEXT:    fli.s fa0, inf
+; RV64IZFA-NEXT:    ret
+  ret float 0x7FF0000000000000
+}
+
+define float @loadfpimm7() {
+; RV32IZFA-LABEL: loadfpimm7:
+; RV32IZFA:       # %bb.0:
+; RV32IZFA-NEXT:    fli.s fa0, nan
+; RV32IZFA-NEXT:    ret
+;
+; RV64IZFA-LABEL: loadfpimm7:
+; RV64IZFA:       # %bb.0:
+; RV64IZFA-NEXT:    fli.s fa0, nan
+; RV64IZFA-NEXT:    ret
+  ret float 0x7FF8000000000000
+}
+
+define float @loadfpimm8() {
+; RV32IZFA-LABEL: loadfpimm8:
+; RV32IZFA:       # %bb.0:
+; RV32IZFA-NEXT:    fli.s fa0, min
+; RV32IZFA-NEXT:    ret
+;
+; RV64IZFA-LABEL: loadfpimm8:
+; RV64IZFA:       # %bb.0:
+; RV64IZFA-NEXT:    fli.s fa0, min
+; RV64IZFA-NEXT:    ret
+  ret float 0x3810000000000000
+}
+
+define float @loadfpimm9() {
+; RV32IZFA-LABEL: loadfpimm9:
+; RV32IZFA:       # %bb.0:
+; RV32IZFA-NEXT:    lui a0, 276464
+; RV32IZFA-NEXT:    fmv.w.x fa0, a0
+; RV32IZFA-NEXT:    ret
+;
+; RV64IZFA-LABEL: loadfpimm9:
+; RV64IZFA:       # %bb.0:
+; RV64IZFA-NEXT:    lui a0, 276464
+; RV64IZFA-NEXT:    fmv.w.x fa0, a0
+; RV64IZFA-NEXT:    ret
+  ret float 255.0
+}
+
 declare float @llvm.minimum.f32(float, float)
 
 define float @fminm_s(float %a, float %b) nounwind {
 ; RV32IZFA-LABEL: fminm_s:
 ; RV32IZFA:       # %bb.0:
 ; RV32IZFA-NEXT:    fminm.s fa0, fa0, fa1
 ; RV32IZFA-NEXT:    ret
 ;

llvm/test/CodeGen/RISCV/half-zfa.ll

 ; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
 ; RUN: llc -mtriple=riscv32 -target-abi ilp32f -mattr=+experimental-zfa,+zfh < %s \
 ; RUN:     | FileCheck --check-prefix=RV32IHZFA %s
 ; RUN: llc -mtriple=riscv64 -target-abi lp64f -mattr=+experimental-zfa,+zfh < %s \
 ; RUN:     | FileCheck --check-prefix=RV64HZFA %s
 
+define half @loadfpimm1() {
+; RV32IHZFA-LABEL: loadfpimm1:
+; RV32IHZFA:       # %bb.0:
+; RV32IHZFA-NEXT:    fli.h fa0, 6.250000e-02
+; RV32IHZFA-NEXT:    ret
+;
+; RV64HZFA-LABEL: loadfpimm1:
+; RV64HZFA:       # %bb.0:
+; RV64HZFA-NEXT:    fli.h fa0, 6.250000e-02
+; RV64HZFA-NEXT:    ret
+  ret half 0.0625
+}
+
+define half @loadfpimm2() {
+; RV32IHZFA-LABEL: loadfpimm2:
+; RV32IHZFA:       # %bb.0:
+; RV32IHZFA-NEXT:    fli.h fa0, 7.500000e-01
+; RV32IHZFA-NEXT:    ret
+;
+; RV64HZFA-LABEL: loadfpimm2:
+; RV64HZFA:       # %bb.0:
+; RV64HZFA-NEXT:    fli.h fa0, 7.500000e-01
+; RV64HZFA-NEXT:    ret
+  ret half 0.75
+}
+
+define half @loadfpimm3() {
+; RV32IHZFA-LABEL: loadfpimm3:
+; RV32IHZFA:       # %bb.0:
+; RV32IHZFA-NEXT:    fli.h fa0, 1.250000e+00
+; RV32IHZFA-NEXT:    ret
+;
+; RV64HZFA-LABEL: loadfpimm3:
+; RV64HZFA:       # %bb.0:
+; RV64HZFA-NEXT:    fli.h fa0, 1.250000e+00
+; RV64HZFA-NEXT:    ret
+  ret half 1.25
+}
+
+define half @loadfpimm4() {
+; RV32IHZFA-LABEL: loadfpimm4:
+; RV32IHZFA:       # %bb.0:
+; RV32IHZFA-NEXT:    fli.h fa0, 3.000000e+00
+; RV32IHZFA-NEXT:    ret
+;
+; RV64HZFA-LABEL: loadfpimm4:
+; RV64HZFA:       # %bb.0:
+; RV64HZFA-NEXT:    fli.h fa0, 3.000000e+00
+; RV64HZFA-NEXT:    ret
+  ret half 3.0
+}
+
+define half @loadfpimm5() {
+; RV32IHZFA-LABEL: loadfpimm5:
+; RV32IHZFA:       # %bb.0:
+; RV32IHZFA-NEXT:    fli.h fa0, 2.560000e+02
+; RV32IHZFA-NEXT:    ret
+;
+; RV64HZFA-LABEL: loadfpimm5:
+; RV64HZFA:       # %bb.0:
+; RV64HZFA-NEXT:    fli.h fa0, 2.560000e+02
+; RV64HZFA-NEXT:    ret
+  ret half 256.0
+}
+
+define half @loadfpimm6() {
+; RV32IHZFA-LABEL: loadfpimm6:
+; RV32IHZFA:       # %bb.0:
+; RV32IHZFA-NEXT:    fli.h fa0, inf
+; RV32IHZFA-NEXT:    ret
+;
+; RV64HZFA-LABEL: loadfpimm6:
+; RV64HZFA:       # %bb.0:
+; RV64HZFA-NEXT:    fli.h fa0, inf
+; RV64HZFA-NEXT:    ret
+  ret half 0xH7C00
+}
+
+define half @loadfpimm7() {
+; RV32IHZFA-LABEL: loadfpimm7:
+; RV32IHZFA:       # %bb.0:
+; RV32IHZFA-NEXT:    fli.h fa0, nan
+; RV32IHZFA-NEXT:    ret
+;
+; RV64HZFA-LABEL: loadfpimm7:
+; RV64HZFA:       # %bb.0:
+; RV64HZFA-NEXT:    fli.h fa0, nan
+; RV64HZFA-NEXT:    ret
+  ret half 0xH7E00
+}
+
+define half @loadfpimm8() {
+; RV32IHZFA-LABEL: loadfpimm8:
+; RV32IHZFA:       # %bb.0:
+; RV32IHZFA-NEXT:    fli.h fa0, min
+; RV32IHZFA-NEXT:    ret
+;
+; RV64HZFA-LABEL: loadfpimm8:
+; RV64HZFA:       # %bb.0:
+; RV64HZFA-NEXT:    fli.h fa0, min
+; RV64HZFA-NEXT:    ret
+  ret half 0xH0400
+}
+
+define half @loadfpimm9() {
+; RV32IHZFA-LABEL: loadfpimm9:
+; RV32IHZFA:       # %bb.0:
+; RV32IHZFA-NEXT:    lui a0, %hi(.LCPI8_0)
+; RV32IHZFA-NEXT:    flh fa0, %lo(.LCPI8_0)(a0)
+; RV32IHZFA-NEXT:    ret
+;
+; RV64HZFA-LABEL: loadfpimm9:
+; RV64HZFA:       # %bb.0:
+; RV64HZFA-NEXT:    lui a0, %hi(.LCPI8_0)
+; RV64HZFA-NEXT:    flh fa0, %lo(.LCPI8_0)(a0)
+; RV64HZFA-NEXT:    ret
+  ret half 255.0
+}
+
 declare half @llvm.minimum.f16(half, half)
 
 define half @fminm_h(half %a, half %b) nounwind {
 ; RV32IHZFA-LABEL: fminm_h:
 ; RV32IHZFA:       # %bb.0:
 ; RV32IHZFA-NEXT:    fminm.h fa0, fa0, fa1
 ; RV32IHZFA-NEXT:    ret
 ;