RFR: 8339738: RISC-V: Vectorize crc32 intrinsic [v6]
Fei Yang
fyang at openjdk.org
Thu Sep 12 03:04:05 UTC 2024
On Wed, 11 Sep 2024 16:39:02 GMT, Hamlin Li <mli at openjdk.org> wrote:
> To your specific question above: we could do it as you suggested, but seems it will not make code clear if we don't do a refactoring first, as in the first `if (UseRVV)` block, it could also jump to `L_unroll_loop_entry` finally as a fallback. So in this way the code will be more complicated rather than clear.
I agree with you in that it's better if we could to separate the refactor and vector version. Here is what I am thinking. I could be wrong as I haven't checked the vector code (`vector_update_crc32`) implementation yet. I suppose it's a performance consideration for the first `if (UseRVV)` block. The intention is execute the vector code only when the input `len` >= `tmp_limit`, right? If I am right, then I think we should use the original `len` before this `subw(len, len, unroll_words)` update on entry. Based on that, I am suggesting following sequence:
const int64_t single_table_size = 256;
const int64_t unroll = 16;
const int64_t unroll_words = unroll*wordSize;
mv(tmp5, right_32_bits);
const ExternalAddress table_addr = StubRoutines::crc_table_addr();
la(table0, table_addr);
add(table1, table0, 1*single_table_size*sizeof(juint), tmp1);
add(table2, table0, 2*single_table_size*sizeof(juint), tmp1);
add(table3, table2, 1*single_table_size*sizeof(juint), tmp1);
if (UseRVV) {
const int64_t tmp_limit = MaxVectorSize >= 32 ? unroll_words*2 : unroll_words*4;
sub(tmp1, len, tmp_limit);
bge(tmp1, zr, L_vector_entry);
}
subw(len, len, unroll_words); <=========== moved here
andn(crc, tmp5, crc); <=========== moved here
bge(len, zr, L_unroll_loop_entry);
I don't see how `L_unroll_loop_entry` finally as a fallback are affecting us. The code doesn't become more complicated to me and the two versions are still separated.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/20910#discussion_r1756024897
More information about the hotspot-dev
mailing list