RFR(L): 8185979: PPC64: Implement SHA2 intrinsic
gromero at linux.vnet.ibm.com
Fri Aug 25 20:35:00 UTC 2017
On 25-08-2017 13:18, Doerr, Martin wrote:
> I think you didn't get my point about AIX.
> Your current version doesn't break AIX, but it lacks SHA2 acceleration for AIX on Power 8 and newer, which is still relevant.
> So I'd like to ask you kindly to take a look if Big Endian support for the stub could be added without high effort. AIX doesn't need VRSAVE handling (like Little Endian linux, unlike Big Endian linux), so a few lines in the stub could possibly be enough. I can assist with testing.
I don't think that VRSAVE is handled on Linux, even on BE. Although BE ABI 
"Functions must ensure that the appropriate bits in the vrsave register are set for any vector registers they use"
and LE ABI does not say that, even on Linux BE VRSAVE is not in effect
used to determine which vector registers (VMX/Altivec) should be saved/restored.
No application uses it on Linux, so I would say that VRSAVE is ignored on Linux
completely both on BE and LE. save/restore library interfaces don't pay
attention to it in glibc: VRSAVE is just saved/restored completely in mechanisms
of swap/get/setcontext(), set/longjump(), and dl-trampoline() and that's all. I
checked that with toolchain folks and they agree. We've already discussed that a
long time ago but at that time I was just using the vector-scalar registers 
and at that time I agreed that if VMX/Altivec was in use instead of the VSX so
VRSAVE should be handled accordingly. But I have a different opinion now...
I'm wondering if something would really break on Linux BE if we forget about
VRSAVE at all in the JVM. If not, we could forget about VRSAVE forever on Linux.
Looks like VRSAVE was sort of born to the oblivion... ?
More information about the hotspot-compiler-dev