On 10/23/26 4:36 AM, Michiel Derhaeg wrote:
From: Loeka Rogge <[email protected]> This removes the guards that disables the clmulr pattern added by patch r17-4206-ge91f79891fc657: Use clmulr for reversed crc32 on rv32 from being used on rv64. This changes the calculation of the reflected quotient (on the host) to fit inside 64 bits. gf2n_poly_long_div_quotient calculates x^128 / (x^64 + lower order terms) = x^64 + lower order terms. Meaning the result is missing an implicit 1 in front of the msb. After reversing, this missing 1 should be after the lsb. This is re-added with a shift and an or. This causes the msb to fall outside the result stored in t0. The value in t0 is only used by the emitted clmul or vclmul instructions. Clmul only emits the bottom 64 bits, representing x^63 and lower order terms. This is unaffected by the missing bit that represents x^64, because it would always fall outside the result. Regtested on rv32gc, rv32gc_zbc, rv64gc, and rv64gc_zbc. gcc/ChangeLog: * config/riscv/bitmanip.md: Remove 64 bit guard. * config/riscv/riscv.cc (riscv_optab_supported_p): Likewise. 64 bit guard. (expand_reversed_crc_using_clmul): Adapt quotient calculation for 65 bits gcc/testsuite/ChangeLog: * gcc.target/riscv/crc-builtin-zbc64.c: test whether clmulr is applied for crc64 Signed-off-by: Loeka Rogge <[email protected]> --- Changes since v1: - Clarified the comment in crc_rev pattern - expand_reversed_crc_using_clmul's assert now uses BITS_PER_WORD - the change in expr.cc is removed, has been addressed in a previous commit addressing the same problem for i386 - Added a run test
THanks. No concerns from me and Sashiko clean. Pushed to the trunk. jeff
