On 9/6/26 8:55 PM, Sun Yuechi wrote:
addi+and keeps a 32 bit object sign extended on rv64, bclr does not:
clearing bit 31 leaves 0xffffffff00000000, so the loop
(m = x; m; m &= m - 1) never terminates.
Wrong code since r16-3984-g4f01f39d021; it hangs rte_softrss() in DPDK
built with -march=rva23u64.
gcc/
* config/riscv/riscv-bclr-lowest-set-bit.cc
(pass_bclr_lowest_set_bit::execute): Sign extend the bclr result
for a sub-word operand.
gcc/testsuite/
* gcc.target/riscv/bclr-lowest-set-bit-2.c: New test.
I wonder if we should just skip the optimization for these SIGN_EXTEND
cases. I can't convince myself the bclr based sequence is any better.
In the original we have a ctz+addiw+and, with the new sequence we'd have
ctz+bclr+sext. In the first sequence the ctz+addiw can likely
issue/execute in parallel on a 2+ wide design. While the second
sequence is fully sequential as the bclr is a consumer of the ctz output.
Thoughts?
jeff
