September 2017 - aarch64-port-dev

RFR: JDK-8187601: Unrolling more when SLP auto-vectorization failed
by Zhongwei Yao 30 Sep '17

30 Sep '17

[Forward from aarch64-port-dev to hotspot-compiler-dev] Hi, all, Bug: https://bugs.openjdk.java.net/browse/JDK-8187601 Webrev: http://cr.openjdk.java.net/~zyao/8187601/webrev.00 In the current implementation, the loop unrolling times are determined by vector size and element size when SuperWordLoopUnrollAnalysis is true (both X86 and aarch64 are true for now). This unrolling policy generates less optimized code when SLP auto-vectorization fails (as following example shows). In this patch, I modify the current unrolling policy to do more unrolling when SLP auto-vectorization fails. So the loop will be unrolled until reaching the unroll times limitation. Here is one example: public static void accessArrayConstants(int[] array) { for (int j = 0; j < 1024; j++) { array[0]++; array[1]++; } } Before this patch, the loop will be unrolled by 4 times. 4 is determined by: AArch64's vector size 128 bits / array element size 32 bits = 4. On X86, vector size is 256 bits. So the unroll times are 8. Below is the generated code by C2 on AArch64: ==== generated code start ==== 0x0000ffff6caf3180: ldr w10, [x1,#16] ; 0x0000ffff6caf3184: add w13, w10, #0x1 0x0000ffff6caf3188: str w13, [x1,#16] ; 0x0000ffff6caf318c: ldr w12, [x1,#20] ; 0x0000ffff6caf3190: add w13, w10, #0x4 0x0000ffff6caf3194: add w10, w12, #0x4 0x0000ffff6caf3198: str w13, [x1,#16] ; 0x0000ffff6caf319c: add w11, w11, #0x4 ; 0x0000ffff6caf31a0: str w10, [x1,#20] ; 0x0000ffff6caf31a4: cmp w11, #0x3fd 0x0000ffff6caf31a8: b.lt 0x0000ffff6caf3180 ; ==== generated code end ==== After applied this patch, it is unrolled 16 times: ==== generated code start ==== 0x0000ffffb0aa6100: ldr w10, [x1,#16] ; 0x0000ffffb0aa6104: add w13, w10, #0x1 0x0000ffffb0aa6108: str w13, [x1,#16] ; 0x0000ffffb0aa610c: ldr w12, [x1,#20] ; 0x0000ffffb0aa6110: add w13, w10, #0x10 0x0000ffffb0aa6114: add w10, w12, #0x10 0x0000ffffb0aa6118: str w13, [x1,#16] ; 0x0000ffffb0aa611c: add w11, w11, #0x10 ; 0x0000ffffb0aa6120: str w10, [x1,#20] ; 0x0000ffffb0aa6124: cmp w11, #0x3f1 0x0000ffffb0aa6128: b.lt 0x0000ffffb0aa6100 ; ==== generated code end ==== This patch passes jtreg tests both on AArch64 and X86. -- Best regards, Zhongwei

2 9

Re: [aarch64-port-dev ] [10] RFR: 8186915 - AARCH64: Intrinsify squareToLen and mulAdd
by Dmitrij Pochepko 25 Sep '17

25 Sep '17

Hi Andrew, you can find my attempt to implement mulAdd intrinsic using wider multiplication here http://cr.openjdk.java.net/~dpochepk/8186915/webrev.02/ but as expected I got slower results on same benchmark compared to original webrev.01 with 32-bit multiplication. I've measured results on ThunderX: webrev.01 version: Benchmark (size) Mode Cnt Score Error Units BigIntegerBench.mulAddReflect 1 avgt 5 194.809 ? 1.341 ns/op BigIntegerBench.mulAddReflect 2 avgt 5 198.242 ? 1.348 ns/op BigIntegerBench.mulAddReflect 3 avgt 5 201.213 ? 0.670 ns/op BigIntegerBench.mulAddReflect 5 avgt 5 213.426 ? 7.441 ns/op BigIntegerBench.mulAddReflect 10 avgt 5 236.396 ? 1.663 ns/op BigIntegerBench.mulAddReflect 50 avgt 5 432.255 ? 24.718 ns/op BigIntegerBench.mulAddReflect 100 avgt 5 653.961 ? 10.140 ns/op webrev.02 version with wider multiplication: Benchmark (size) Mode Cnt Score Error Units BigIntegerBench.mulAddReflect 1 avgt 5 196.109 ? 0.663 ns/op BigIntegerBench.mulAddReflect 2 avgt 5 213.438 ? 124.206 ns/op BigIntegerBench.mulAddReflect 3 avgt 5 211.683 ? 3.206 ns/op BigIntegerBench.mulAddReflect 5 avgt 5 217.324 ? 5.827 ns/op BigIntegerBench.mulAddReflect 10 avgt 5 233.272 ? 21.560 ns/op BigIntegerBench.mulAddReflect 50 avgt 5 455.337 ? 237.168 ns/op BigIntegerBench.mulAddReflect 100 avgt 5 826.844 ? 4.972 ns/op As you can see, it's up to 26% worse throughput with wider multiplication. The reasons for this is: 1. mulAdd uses 32-bit multiplier (unlike multiplyToLen intrinsic) and it can’t be changed within the function signature. Thus we can’t fully utilize the potential of 64-bit multiplication. 2. umulh instruction is more expensive than mul instruction. I haven't implemented wider multiplication for squareToLen intrinsic, since it'll require much more code due to more corner cases. Also, squaring algorithm in BigInteger doesn't handle more than 127 integers in one squareToLen call(large integer arrays are divided to smaller parts for squaring, so, 1..127 integers are squared at once), which makes all additional off-loop penalties expensive in comparison to loop execution time. At this point I ran out of ideas how we could improve the performance 3x for these intrinsics. I understand one can do better with 64bit for the intrinsics you implemented, but squareToLen and mulAdd looks different. Do you have other suggestions, or can we proceed with initial version (webrev.01)? Thanks, Dmitrij On 01.09.2017 10:51, Andrew Haley wrote: > On 31/08/17 23:46, Dmitrij Pochepko wrote: >> I tried a number of initial versions first. I also tried to use wider >> multiplication via umulh (and larger load instructions like ldp/ldr), >> but after measuring all versions I've found that version I've initially >> sent appeared to be the fastest (I was measuring it on ThunderX which I >> have in hand). It might be because of lots of additional ror(..., 32) >> operations in other versions to convert values from initial layout to >> register and back. Another reason might be more complex overall logic >> and larger code, which triggers more icache lines to be loaded. Or even >> some umulh specifics on some CPUs. So, after measuring, I've abandoned >> these versions in a middle of development and polished the fastest one. >> I have some raw development unpolished versions of such approaches >> left(not sure I have debugged versions saved, but at least has an >> overall idea). >> I attached squares_v2.3.1.diff: early version which is using mul/umulh >> for just one case. It was surprisingly slower for this case than version >> I've sent to review, so, I've abandoned this approach. >> I've also tried version with large load instructions(ldp/ldr): >> squares_v1.diff and it was also slower(it has another, slower, mul_add >> loop implementation, but I was comparing to the same version, which is >> using ldrw-only). >> >> I'm not sure if I should use 64-bit multiplications and/or 64/128 bit >> loads. I can try to return back to one of such versions and try to >> polish it, but I'll probably get slower results again on h/w I have and >> it's not clear if it'll be faster on any other h/w(which one? It takes a >> lot of time to iteratively improve and measure every version on >> respective h/w). > I'm using Applied Micro hardware for my testing at the moment. > > I did the speed testing for Montgomery multiply on ThunderX. I > appreciate that it's difficult to get the 64-bit version right and > fast, but you should see about 3 - 3.5* speedup over the pure Java > version if you get it right. That's what I saw when I did the > Montgomery multiply. You do have to pipeline the loads and the > multiplies to avoid stalls. > > Be aware that squareToLen is not used at all when running the > RSA benchmark with C2. >

4 14

JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 10 on AArch64
by ci_notify＠linaro.org 21 Sep '17

21 Sep '17

This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk10/openjdk-jtreg-nightly-tests/summary/2017/26… ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 1,400; fail: 11,561 Build 1: aarch64/2017/sep/20 pass: 1,369; fail: 35; error: 1 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 7,432; fail: 714; error: 20 Build 1: aarch64/2017/sep/20 pass: 7,469; fail: 689; error: 22 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 3,784 Build 1: aarch64/2017/sep/20 pass: 3,783; fail: 1 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 1,403; fail: 11,562; error: 1 Build 1: aarch64/2017/sep/20 pass: 1,373; fail: 37 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 7,469; fail: 675; error: 22 Build 1: aarch64/2017/sep/20 pass: 7,452; fail: 705; error: 23 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 3,782; error: 2 Build 1: aarch64/2017/sep/20 pass: 3,783; fail: 1 Previous results can be found here: http://openjdk.linaro.org/jdk10/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.05x Relative performance: Server critical-jOPS (nc): 0.90x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk10/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 70.58, Server: 115.7 Client 70.58 / Client 2014-04-01 (43.00): 1.64x Server 115.7 / Server 2014-04-01 (71.00): 1.63x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk10/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-09-07 pass rate: 11556/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/249/results/ 2017-09-21 pass rate: 11556/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/263/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/

1 0

hg: aarch64-port/jdk8u-shenandoah/hotspot: [backport] PhiNode::has_only_data_users() needs to apply to shenandoah barrier only
by rwestrel＠redhat.com 20 Sep '17

20 Sep '17

Changeset: 48b74a7788cd Author: roland Date: 2017-09-19 13:41 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/48b74a… [backport] PhiNode::has_only_data_users() needs to apply to shenandoah barrier only ! src/share/vm/opto/cfgnode.cpp

1 0

bug fix for aarch64-port/jdk8u-shenandoah when Shenandoah is disabled
by Roland Westrelin 20 Sep '17

20 Sep '17

http://cr.openjdk.java.net/~roland/shenandoah/phi_has_only_data_users/webre… This is a fix for an issue that affects aarch64-port/jdk8u-shenandoah even when shenandoah is disabled. That bug causes a debug VM to crash with: Internal Error at phaseX.cpp:985, pid=26493, tid=0x00007fd8c4199700 assert(false) failed: infinite loop in PhaseIterGVN::optimize and a product build to consume a lot of memory. Roland.

2 2

RFR: Bulk import from Shenandoah
by Roman Kennke 18 Sep '17

18 Sep '17

I would like to bulk-import some changes from Shenandoah/JDK8u: http://cr.openjdk.java.net/~rkennke/aarch64-bulk-import-shenandoah-2017-08-… <http://cr.openjdk.java.net/%7Erkennke/aarch64-bulk-import-shenandoah-2017-0…> It is made of 26 changes, squashed into one bulk change. It's mostly backports of stuff that has baked in jdk9 and jdk10 dev repos, and some jdk8 specific fixes and added tests. It's all gone through our own testing, and doesn't touch anything non-shenandoah. The reason why we're doing bulk import instead of single-changeset import as we did last time is that it makes it easier to merge the import back into Shenandoah. I got a whole lot of problems this time with sorting out conflicts from last merge's transplanted changesets. Ok to push? Roman

5 7

RFR: JDK-8187601: Unrolling more when SLP auto-vectorization failed
by Zhongwei Yao 18 Sep '17

18 Sep '17

Hi, all, Bug: https://bugs.openjdk.java.net/browse/JDK-8187601 Webrev: http://cr.openjdk.java.net/~zyao/8187601/webrev.00 In the current implementation, the loop unrolling times are determined by vector size and element size when SuperWordLoopUnrollAnalysis is true (both X86 and aarch64 are true for now). This unrolling policy generates less optimized code when SLP auto-vectorization fails (as following example shows). In this patch, I modify the current unrolling policy to do more unrolling when SLP auto-vectorization fails. So the loop will be unrolled until reaching the unroll times limitation. Here is one example: public static void accessArrayConstants(int[] array) { for (int j = 0; j < 1024; j++) { array[0]++; array[1]++; } } Before this patch, the loop will be unrolled by 4 times. 4 is determined by: AArch64's vector size 128 bits / array element size 32 bits = 4. On X86, vector size is 256 bits. So the unroll times are 8. Below is the generated code by C2 on AArch64: ... ... # omit unrelated code. ... 0x0000ffff6caf3180: ldr w10, [x1,#16] ;*iaload {reexecute=0 rethrow=0 return_oop=0} ; - ArrayAccess::accessArrayConstants@12 (line 6) 0x0000ffff6caf3184: add w13, w10, #0x1 0x0000ffff6caf3188: str w13, [x1,#16] ;*iastore {reexecute=0 rethrow=0 return_oop=0} ; - ArrayAccess::accessArrayConstants@15 (line 6) 0x0000ffff6caf318c: ldr w12, [x1,#20] ;*iaload {reexecute=0 rethrow=0 return_oop=0} ; - ArrayAccess::accessArrayConstants@19 (line 7) 0x0000ffff6caf3190: add w13, w10, #0x4 0x0000ffff6caf3194: add w10, w12, #0x4 0x0000ffff6caf3198: str w13, [x1,#16] ;*iastore {reexecute=0 rethrow=0 return_oop=0} ; - ArrayAccess::accessArrayConstants@15 (line 6) 0x0000ffff6caf319c: add w11, w11, #0x4 ;*iinc {reexecute=0 rethrow=0 return_oop=0} ; - ArrayAccess::accessArrayConstants@23 (line 5) 0x0000ffff6caf31a0: str w10, [x1,#20] ;*iastore {reexecute=0 rethrow=0 return_oop=0} ; - ArrayAccess::accessArrayConstants@22 (line 7) 0x0000ffff6caf31a4: cmp w11, #0x3fd 0x0000ffff6caf31a8: b.lt 0x0000ffff6caf3180 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} ; - ArrayAccess::accessArrayConstants@6 (line 5) ... ... # omit unrelated code. ... After applied this patch, it is unrolled 16 times: ... ... # omit unrelated code. ... 0x0000ffffb0aa6100: ldr w10, [x1,#16] ;*iaload {reexecute=0 rethrow=0 return_oop=0} ; - ArrayAccess::accessArrayConstants@12 (line 6) 0x0000ffffb0aa6104: add w13, w10, #0x1 0x0000ffffb0aa6108: str w13, [x1,#16] ;*iastore {reexecute=0 rethrow=0 return_oop=0} ; - ArrayAccess::accessArrayConstants@15 (line 6) 0x0000ffffb0aa610c: ldr w12, [x1,#20] ;*iaload {reexecute=0 rethrow=0 return_oop=0} ; - ArrayAccess::accessArrayConstants@19 (line 7) 0x0000ffffb0aa6110: add w13, w10, #0x10 0x0000ffffb0aa6114: add w10, w12, #0x10 0x0000ffffb0aa6118: str w13, [x1,#16] ;*iastore {reexecute=0 rethrow=0 return_oop=0} ; - ArrayAccess::accessArrayConstants@15 (line 6) 0x0000ffffb0aa611c: add w11, w11, #0x10 ;*iinc {reexecute=0 rethrow=0 return_oop=0} ; - ArrayAccess::accessArrayConstants@23 (line 5) 0x0000ffffb0aa6120: str w10, [x1,#20] ;*iastore {reexecute=0 rethrow=0 return_oop=0} ; - ArrayAccess::accessArrayConstants@22 (line 7) 0x0000ffffb0aa6124: cmp w11, #0x3f1 0x0000ffffb0aa6128: b.lt 0x0000ffffb0aa6100 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} ; - ArrayAccess::accessArrayConstants@6 (line 5) ... ... # omit unrelated code. ... This patch passes jtreg tests both on AArch64 and X86. -- Best regards, Zhongwei

1 0

JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 10 on AArch64
by ci_notify＠linaro.org 08 Sep '17

08 Sep '17

This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk10/openjdk-jtreg-nightly-tests/summary/2017/24… ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 1,400; fail: 11,561 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 7,432; fail: 714; error: 20 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 3,784 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 1,403; fail: 11,562; error: 1 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 7,469; fail: 675; error: 22 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2017/sep/06 pass: 3,782; error: 2 Previous results can be found here: http://openjdk.linaro.org/jdk10/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 1.05x Relative performance: Server critical-jOPS (nc): 0.90x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk10/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the client and server compilers on 2014-04-01. Relative performance: Zero: 1.0, Client: 71.29, Server: 118.61 Client 71.29 / Client 2014-04-01 (43.00): 1.66x Server 118.61 / Server 2014-04-01 (71.00): 1.67x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk10/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2017-09-07 pass rate: 11556/11559, results: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/2017/249/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk10/jcstress-nightly-runs/

2 1

Re: [aarch64-port-dev ] RFR(S): 8154537: AArch64: some integer rotate instructions are never emitted
by Andrew Haley 05 Sep '17

05 Sep '17

I'm looking at the webrev in http://cr.openjdk.java.net/~roland/8154537/webrev.00/ and I see the the changes were made to aarch64.ad but not to ad_aarch64.m4. This is problematic because some .m4 files are used to generate the .ad file, and if anyone regenerates the .ad file the bug will regress. I think this is the change we need to make. It won't affect generated code at all, but it is something of a ticking bomb. diff -r 214a94e9366c src/cpu/aarch64/vm/aarch64_ad.m4 --- a/src/cpu/aarch64/vm/aarch64_ad.m4 Mon Jul 17 12:11:32 2017 +0000 +++ b/src/cpu/aarch64/vm/aarch64_ad.m4 Fri Jul 28 18:57:25 2017 +0100 @@ -268,21 +268,21 @@ ins_pipe(ialu_reg_reg_vshift); %}')dnl define(ROL_INSN, ` -instruct $3$1_rReg_Var_C$2(iRegLNoSp dst, iRegL src, iRegI shift, immI$2 c$2, rFlagsReg cr) +instruct $3$1_rReg_Var_C$2(iReg$1NoSp dst, iReg$1 src, iRegI shift, immI$2 c$2, rFlagsReg cr) %{ match(Set dst (Or$1 (LShift$1 src shift) (URShift$1 src (SubI c$2 shift)))); expand %{ - $3L_rReg(dst, src, shift, cr); + $3$1_rReg(dst, src, shift, cr); %} %}')dnl define(ROR_INSN, ` -instruct $3$1_rReg_Var_C$2(iRegLNoSp dst, iRegL src, iRegI shift, immI$2 c$2, rFlagsReg cr) +instruct $3$1_rReg_Var_C$2(iReg$1NoSp dst, iReg$1 src, iRegI shift, immI$2 c$2, rFlagsReg cr) %{ match(Set dst (Or$1 (URShift$1 src shift) (LShift$1 src (SubI c$2 shift)))); expand %{ - $3L_rReg(dst, src, shift, cr); + $3$1_rReg(dst, src, shift, cr); %} %}')dnl ROL_EXPAND(L, rol, rorv) -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

2 4

hg: aarch64-port/jdk8u/hotspot: 8187224: aarch64: some inconsistency between aarch64_ad.m4 and aarch64.ad
by felix.yang＠linaro.org 05 Sep '17

05 Sep '17

Changeset: 471de666658d Author: fyang Date: 2017-09-05 19:09 +0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/471de666658d 8187224: aarch64: some inconsistency between aarch64_ad.m4 and aarch64.ad Summary: fix ROL_INSN and ROR_INSN definition in aarch64_ad.m4 Reviewed-by: aph ! src/cpu/aarch64/vm/aarch64_ad.m4

1 0