[PATCH] D117468: [RISCV] Add intrinsic for Zbt extension

Craig Topper via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Jan 18 19:55:16 PST 2022

craig.topper added a comment.

Out of curiosity, what is your interest in Zbt? Do you work for a company that is implementing this extension in hardware?

Comment at: llvm/lib/Target/RISCV/RISCVISelLowering.cpp:4246
+  case Intrinsic::riscv_fsl:
+    return DAG.getNode(RISCVISD::FSL, DL, XLenVT, Op.getOperand(1),
+                       Op.getOperand(2), Op.getOperand(3));
craig.topper wrote:
> craig.topper wrote:
> > The operand order for RISCVISD::FSL/FSR match llvm.fshl and llvm.fshr rather than rs1, rs2, rs3 order. I think the operand order you want for riscv.fsl and riscv.fsr should be rs1, rs2, rs3.
> > 
> > And the assembly printing for fsl/fsr prints $rd, $rs1, $rs3, $rs2 makes this even more confusing.
> > 
> > I'll put up a patch to change RISCVISD::FSL/FSR and RISCVISD::FSLW/FSRW order to be in rs1, rs2, rs3 order.
> i just noticed the proposed intrinsic order here https://github.com/riscv/riscv-bitmanip/blob/main-history/cproofs/rvintrin.h  uses rs1, rs3, rs2/shamt ordering. Which is different than the order used in the spec pseudo code. But rs1, rs3, rs2/shamt matches how the instructions are printed.
> So I guess we should use rs1, rs3, rs2/shamt order. I'll update the RISCVISD opcodes accordingly.
I pushed a patch to change the operand order of RISCVISD::FSL/FSR

Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoZb.td:900
           (FSR GPR:$rs1, GPR:$rs2, GPR:$rs3)>;
+def : Pat<(riscv_fsr GPR:$rs3, GPR:$rs1, uimmlog2xlen:$shamt),
+          (FSRI GPR:$rs1, GPR:$rs3, uimmlog2xlen:$shamt)>;
I made this change in the repo and handled the riscv_fsl with constant case.

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list