[8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic vector CRC implementation

Andrew Hughes gnu.andrew at redhat.com
Tue Feb 18 10:29:00 UTC 2020


On 27/09/2019 04:31, Gustavo Romero wrote:
> Hi,
> 
> Could the following backport for jdk8u be reviewed please?
> 
> The original change was mainly written to provide a better
> implementation for
> CRC32 and CRC32C, but it also improved the CRC32 performance in general.
> This
> backport is the first change of a patchset comprised of 4 changes aimed to
> backport all the latest CRC32 missing parts from JDK 11u.
> 
> It's a PPC64-only change.
> 
> Bug     : https://bugs.openjdk.java.net/browse/JDK-8198894
> Original: http://hg.openjdk.java.net/jdk/jdk/rev/7cd503c499a0
> Backport:
> http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for-review/8198894/
> 

Can we please stick to one change per webrev, please? It makes it
confusing as to what will actually be pushed when a webrev refers to
multiple bugs which are not part of the RFR.

> It was necessary to backport it to:
> 
> - Adapt the file names to OpenJDK 8u

Fine, and doesn't warrant review on its own.

> - Remove CRC32C part, leaving only CRC32 part, since OpenJDK 8u has no
> CRC32C
> - Add Assembler::add_const_optimized() from "8077838: Recent
> developments for ppc" [0]

Cherry-picking this seems fine as we don't want to force POWER 8 as a
requirement on 8u.

> - Fix vpermxor() opcode, replacing VPMSUMW_OPCODE by VPERMXOR_OPCODE,
>   accordingly to fix in "8190781: ppc64 + s390: Fix CriticalJNINatives" [1]

It seems this fix should be backported as a pre-requisite. Was there a
reason not to? It seems a fairly simple change from a naive perspective.

> - Adapt signatures for the following functions and their callers,
> accordingly to
>   "8175369: [ppc] Provide intrinsic implementation for CRC32C" [2], also
> to ease
>   subsequent backports in this patchset:
>    a. MacroAssembler::update_byteLoop_crc32(), removing 'invertCRC'
> parameter
>    b. MacroAssembler::kernel_crc32_1word(), adding 'invertCRC' parameter
> 

I share Martin's concerns about this. If we must do this, I would prefer
it was done as a separate change. It seems unrelated to the other
changes in 8198894.

A few minor issues:

* The diff of the macroAssembler_ppc.cpp changes looks different from
the 11u version, though there doesn't seem to be any actual difference.
I don't know if it's possible to line this up better by checking no
empty lines were missed.

* macroAssembler_ppc.cpp, macroAssembler_ppc.hpp, stubGenerator_ppc.hpp,
stubRoutines_ppc_64.hpp & stubRoutines_ppc_64.cpp include copyright
header changes in the 11u patch which don't appear to be in the 8u
version. Were these already present or simply missed?

> 
> Thank you.
> 
> Best regards,
> Gustavo
> 
> [0] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/88847a1b3718
> [1] http://hg.openjdk.java.net/jdk/jdk/rev/5a69ba3a4fd1#l1.7
> [2] https://bugs.openjdk.java.net/browse/JDK-8175369

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222



More information about the hotspot-compiler-dev mailing list