[10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic

[Gustavo Romero]

Hi Martin!

On 01-09-2017 12:39, Doerr, Martin wrote:
> Hi Gustavos,
> 
> I have managed to upload a version which seems to work on both endianness implementations.
> At least some quick tests have passed on AIX and Big Endian linux in addition to Little Endian linux.

Great! :-)


> I'll be out next week, but the change looks ok for me. Please let me know if the changed version still looks ok for you, too. Feel free to overwork or improve it.
> It'd also be good to know, if relying on vrsave=-1 is safe.

Sure, Martin. I'm chasing what's exactly setting vrsave=-1 and the full history log (looks like it's not in the kernel, but I'm checking yet).


> Is the copyright information ok? Did you get source code which requires to be mentioned in the comments?
> The code looks similar to a reference implementation, so the authors of it may want to be mentioned?
> Or did you just use the paper for implementing it? In this case, I'd mention the paper.

Gustavo S: the information on the paper must be updated accordingly as Martin noted in the new webrev. There is none currently.


> After we got a second review and ran more tests, we can ask somebody from Oracle to push it.
> 
> Thanks for contributing and your support,
> Martin

Thanks a lot for reviewing and for all the help.

Regards,
Gustavo R

> 
> -----Original Message-----
> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin
> Sent: Donnerstag, 31. August 2017 18:21
> To: Gustavo Romero <gromero at linux.vnet.ibm.com>
> Cc: 'hotspot-compiler-dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net
> Subject: RE: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic
> 
> Hi Gustavo R,
> 
> I guess you're right. vrsave is already set to -1, so all Vector Registers get saved.
> It'd be good to know where it is set (OS, Flag in ELF header, ???) and if this is guaranteed.
> I don't want to risk getting sporadic errors on some OS versions.
> 
> I'd like to enable SHA intrinsics on linux BE as well. I already managed to get the 256 bit version working (was quite some work!).
> 
> Thanks and best regards,
> Martin
> 
> 
> -----Original Message-----
> From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] 
> Sent: Freitag, 25. August 2017 22:35
> To: Doerr, Martin <martin.doerr at sap.com>
> Cc: Gustavo Serra Scalet <gustavo.scalet at eldorado.org.br>; 'hotspot-compiler-dev at openjdk.java.net' <hotspot-compiler-dev at openjdk.java.net>; ppc-aix-port-dev at openjdk.java.net
> Subject: Re: [10] RFR(L): 8185979: PPC64: Implement SHA2 intrinsic
> 
> Hi Martin,
> 
> 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 [1]
> says:
> 
> "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 [2]
> 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... ?
> 
> 
> Kind regards,
> Gustavo
> 
> [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__refspecs.linuxfoundation.org_ELF_ppc64_PPC-2Delf64abi-2D1.9.html&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=kYUIMs9GlX4qSpgorcaHtHrNQxh38_XLwoS4XhaXum8&m=ih0Z-esrs-Hl9wipN392okVsz6z70Rsr9rgJinnzArY&s=arAjOio5NNoRIZLdczhgF5BDoAF3HUvq-xCtSufn_kA&e= 
> [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DMay_002508.html&d=DwIFAg&c=jf_iaSHvJObTbx-siA1ZOg&r=kYUIMs9GlX4qSpgorcaHtHrNQxh38_XLwoS4XhaXum8&m=ih0Z-esrs-Hl9wipN392okVsz6z70Rsr9rgJinnzArY&s=p0xb08lxayJHBXZREL-7c5ipKc-waZMMZpTiQWfU-S4&e= 
>