RFR: 8319716: RISC-V: Add SHA-2

[Robbin Ehn]

On Wed, 8 Nov 2023 19:17:32 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> Main author is @luhenry, I only fixed some minor things and tested it.
>> 
>> Such as:
>> test/hotspot/jtreg/compiler/intrinsics/sha/
>> test/jdk/java/security/MessageDigest/
>> test/jdk/jdk/security/
>> tier1
>> 
>> And still running some test.
>
> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 169:
> 
>> 167:   }
>> 168: 
>> 169:   if (UseZvknhb && UseZvkb) {
> 
> this looks weird, two jdk options needed to enable sha intrinsincs. 
> Can we simplify it somehow  for now , like UseRVVCryptoExt ?
> Splitting this into UseZvknhb && UseZvkb can be done in future, if it really would be needed one day

Yes, this is a total mess.
For bystanders this is a 'simple' march to gcc-13:
`rv64im0_a2p1_f2p2_d2p2_c2p0_v1p0_zicsr2p0_zifencei2p0_zmmul1p0_zacas1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0`
A simple RVA23U64 CPU may have like 40 extensions, a high performance server class CPU may have well over a hundred.

Just the scalar crypto ones:
`Zbkb, Zbkc, Zbkx, Zknd, Zkne, Zknh, Zksed, Zksh, Zkr, Zkt, Zkn, Zks, Zk`

It is no reasonable to add all these as flags.
So flags for the collections seems like much better idea.
But we probably need to be able to turn off a sub-extension such UseZvknhb.
"-XX:+UseVectorCryptoExt:zvknhb=false"
Suggestions welcome.

Just top of my head, at the moment I need to supply this crazy arch string to qemu, compiler, obj dump and there doesn't seem to be a solution near, so maybe we should be able to supply that arch string to the VM also.
`-XX:UseArch=rv64im0_a2p1_f2p2_d2p2_c2p0_v1p0_zicsr2p0_zifencei2p0_zmmul1p0_zacas1p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16562#discussion_r1387619392