On 9/4/26 5:27 AM, Jakub Jelinek wrote:
Hi!

The following patch attempts to improve code generation for
__builtin_bitreverse{8,16,32,64} when ZBKB extension is enabled, by using
         brev8   a0,a0
or
         rev8    a0,a0
         brev8   t0,a0
         srli    a0,t0,48       ! 16 for rv32
or (bitreversesi2 if rv64)
         rev8    a0,a0
         brev8   t0,a0
         srai    a0,t0,32
or (bitreversesi2 if rv32 or bitreversedi2 if rv64)
         rev8    a0,a0
         brev8   a0,a0

Only tested in a cross on a testcase with the 4 builtins, hope CI will pick
this up when posted with RISC-V in the subject.

The bswaphi2 change is not strictly necessary, just weird to limit it
only to TARGET_ZBB when bswap<word_mode>2 is also TARGET_ZBKB.

2026-09-04  Jakub Jelinek  <[email protected]>

        PR target/126671
        * config/riscv/bitmanip.md (bswaphi2): Use
        TARGET_ZBB || TARGET_ZBKB condition instead of just
        TARGET_ZBB.
        (bitreverse<mode>2): New expander.
I'm not aware of a design in the wild supporting Zbkb, I've tried a couple times to get that added to our supported set without success (mostly I want the pack family of instructions).



--- a/gcc/config/riscv/bitmanip.md      2026-08-31 17:12:13.964850866 +0200
+++ b/gcc/config/riscv/bitmanip.md      2026-09-04 12:36:05.599948978 +0200
@@ -549,7 +549,7 @@ (define_insn "*bswap<mode>2"
  (define_expand "bswaphi2"
    [(set (match_operand:HI 0 "register_operand" "=r")
          (bswap:HI (match_operand:HI 1 "register_operand" "r")))]
-  "TARGET_ZBB"
+  "TARGET_ZBB || TARGET_ZBKB"
Trivially OK.  If you find others, feel free to just fix them.  Zbkb always implies Zbb.


  {
    rtx tmp = gen_reg_rtx (word_mode);
    rtx newop1 = gen_lowpart (word_mode, operands[1]);
@@ -566,6 +566,41 @@ (define_expand "bswaphi2"
    DONE;
  })
+(define_expand "bitreverse<mode>2"
+  [(match_operand:ANYI 0 "register_operand")
+   (match_operand:ANYI 1 "register_operand")]
+  "TARGET_ZBKB"
I'd be a lot more comfortable with a test in the testsuite that at least verified the code generation via scan-asm or check-function-bodies.   If you look at crc-22-zbkb, I think it has the magic necessary to have a run test which could be run on a suitable design or in QEMU.

jeff

Reply via email to