RFR: 8295698: AArch64: test/jdk/sun/security/ec/ed/EdDSATest.java failed with -XX:+UseSHA3Intrinsics
Dong Bo
dongbo at openjdk.org
Tue Nov 15 06:41:09 UTC 2022
On Mon, 14 Nov 2022 17:53:46 GMT, Andrew Haley <aph at openjdk.org> wrote:
> > > This looks right, but I don't think I can test it, which I usually would do with a patch this complicated. When we have a processor without FEAT_SHA3) we should define BCAX, EOR3, RAX1, and XAR as macros. Could you do that, please?
> >
> >
> > Thanks for the comments.
> > Do you mean that we need a patch (not to be merged) to support testing on processor without FEAT_SHA3? In which, the SHA3 instructions are substituted by multiple instructions, something like: `eor3 v1, v2, v3, v4 => eor v1, v2, v3; eor v1, v1, v4`?
>
> Yes, exactly. So the intrinsic will work everywhere. Why not merge it? It seems obvious to me.
>
I see, great idea. But I'm afraid this cannot easily be done due to the high register pressure of the `keccak()` algorithm loop.
Three registers are passed to `xar Vd, Vn, Vm, #imm`, which operation equals to `tmp = Vn ROR Vm; Vd = ROR(tmp[127:64], imm):ROR(tmp[63:0], imm)`.
Registers `Vm/Vn` will be read by operations below, we need another `tmp` register, or we will get clobbered `Vm/Vn` when translating `xar` to NEON instructions.
And we cannot find a free `tmp` register, almost every register has useful data for future use.
The other three SHA3 instructions have similar register issue.
> > BTW, FEAT_SHA3 is supported on M1. If you happen to have one, the test can be done on it. :) To test this on M1/MacOS, modification below is needed to enable SHA3Intriniscs by default. Since other features, i.e. UseSHA, can not be automatically detected neither, I think it is irrelevant with this patch.
>
> Do you know why SHA3 isn't enabled on M1?
FEAT_SHA3 is not detected on MacOS, this code snippet below would be enough for FEAT_SHA3.
I think there are some other hardware features, e.g. FEAT_SHA1, FEAT_SHA256, FEAT_SHA512, are not detected on MacOS too.
We may need another PR to fix it.
diff --git a/src/hotspot/os_cpu/bsd_aarch64/vm_version_bsd_aarch64.cpp b/src/hotspot/os_cpu/bsd_aarch64/vm_version_bsd_aarch64.cpp
index 45cd77b3ba5..0ac6b4a56d1 100644
--- a/src/hotspot/os_cpu/bsd_aarch64/vm_version_bsd_aarch64.cpp
+++ b/src/hotspot/os_cpu/bsd_aarch64/vm_version_bsd_aarch64.cpp
@@ -68,6 +68,8 @@ void VM_Version::get_os_cpu_info() {
if (cpu_has("hw.optional.armv8_crc32")) _features |= CPU_CRC32;
if (cpu_has("hw.optional.armv8_1_atomics")) _features |= CPU_LSE;
+ if (cpu_has("hw.optional.armv8_2_sha3")) _features |= CPU_SHA3;
+
int cache_line_size;
int hw_conf_cache_line[] = { CTL_HW, HW_CACHELINE };
sysctllen = sizeof(cache_line_size);
-------------
PR: https://git.openjdk.org/jdk/pull/10939
More information about the hotspot-compiler-dev
mailing list