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