[RISCV] Add intrinsic for Zbt extension

[Chenbing.Zheng]

Summary

RV32: fsl, fsr, fsri

RV64: fsl, fsr, fsri, fslw, fsrw, fsriw

[craig.topper]

clang/include/clang/Basic/BuiltinsRISCV.def

65

cmov and cmix don't builtins don't seem very useful. The compiler can already match them from IR operations that can be expressed in C.

clang/lib/CodeGen/CGBuiltin.cpp

18967

We shouldn't have an fsri builtin. The fsr builtin is sufficient. And riscv_fsri looks unhandled in the backend.

llvm/lib/Target/RISCV/RISCVInstrInfoZb.td

907 ↗

(On Diff #400496)

Need to also handle fsl with a constant argument.

[Chenbing.Zheng]

del cmov，cmix，fsri in clang

[Chenbing.Zheng]

llvm/lib/Target/RISCV/RISCVInstrInfoZb.td

907 ↗

(On Diff #400496)

Emm.... but there is no fsli in zbt.

[craig.topper]

llvm/lib/Target/RISCV/RISCVInstrInfoZb.td

907 ↗

(On Diff #400496)

Yes because the compiler can change the constant to turn fsli into fsri. We do this on line 903.

If the user uses fsl with a constant we should give them good code by turning it into fsri.

[craig.topper]

llvm/lib/Target/RISCV/RISCVISelLowering.cpp

4262

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.

[craig.topper]

llvm/lib/Target/RISCV/RISCVISelLowering.cpp

4262

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.

[craig.topper]

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

llvm/lib/Target/RISCV/RISCVISelLowering.cpp

4262

I pushed a patch to change the operand order of RISCVISD::FSL/FSR

llvm/lib/Target/RISCV/RISCVInstrInfoZb.td

900 ↗

(On Diff #400768)

I made this change in the repo and handled the riscv_fsl with constant case.

[Chenbing.Zheng]

rebase main

[Chenbing.Zheng]

In D117468#3253493, @craig.topper wrote:

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

My company has not implementing this extension，but may be in the future. I'm just doing a pre-research.

llvm/lib/Target/RISCV/RISCVISelLowering.cpp

4262

I think change swap op2 and op3 in Pat, so shall i keep the order op1, op2, op3 here?

def : Pat<(riscv_fsl GPR:$rs1, GPR:$rs3, GPR:$rs2),

(FSL GPR:$rs1, GPR:$rs2, GPR:$rs3)>;

def : Pat<(riscv_fsr GPR:$rs1, GPR:$rs3, GPR:$rs2),

(FSR GPR:$rs1, GPR:$rs2, GPR:$rs3)>;

[craig.topper]

llvm/test/CodeGen/RISCV/rv32zbt-intrinsic.ll

22

This should have the same register order as the fsl test case. I think the test just needs to be re-generated.

28

Please add an fsli test case using llvm.riscv.fsl.i32 and a constant shift amount

31

This should be fsri a0, a0, a1, 5

llvm/test/CodeGen/RISCV/rv64zbt-intrinsic.ll

28

Please add an fsli test case.

59

Please add a fsri test case.

[craig.topper]

In D117468#3253879, @Chenbing.Zheng wrote:

In D117468#3253493, @craig.topper wrote:

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

My company has not implementing this extension，but may be in the future. I'm just doing a pre-research.

The Zbt extensions and the other un-ratified extension from the old Bitmanip spec have not seen any active discussion for at least the last 6-9 months. If that continues, it starts to raise questions about whether llvm should continue to support and extension that does not appear to be on a path to ratification. I've asked for a discussion on this topic at the next RISCV LLVM bi-weekly sync meeting tomorrow morning US time. calendar link here https://llvm.org/docs/GettingInvolved.html#online-sync-ups

[Chenbing.Zheng]

modify tests

[Chenbing.Zheng]

In D117468#3255546, @craig.topper wrote:

In D117468#3253879, @Chenbing.Zheng wrote:

In D117468#3253493, @craig.topper wrote:

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

My company has not implementing this extension，but may be in the future. I'm just doing a pre-research.

The Zbt extensions and the other un-ratified extension from the old Bitmanip spec have not seen any active discussion for at least the last 6-9 months. If that continues, it starts to raise questions about whether llvm should continue to support and extension that does not appear to be on a path to ratification. I've asked for a discussion on this topic at the next RISCV LLVM bi-weekly sync meeting tomorrow morning US time. calendar link here https://llvm.org/docs/GettingInvolved.html#online-sync-ups

Thanks a lot, I will keep watching it.

[craig.topper]

LGTM