From jiefu at openjdk.java.net  Tue Mar  1 00:12:06 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 1 Mar 2022 00:12:06 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v6]
In-Reply-To: <2OyaRp6UdLYtDJSJQash1i6Nfo4jriWELQA30ITrwIY=.ab68593c-de96-493f-a215-0be40cb69a36@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <atA1KlK27dwDA_AEuBgA0goEn6lQc1uZ-xhCT08NZgU=.f02e1fa5-f289-44d5-9715-7efcfe73418d@github.com>
 <2OyaRp6UdLYtDJSJQash1i6Nfo4jriWELQA30ITrwIY=.ab68593c-de96-493f-a215-0be40cb69a36@github.com>
Message-ID: <kblCV0Ov7NbXc2rfRSoqdUshSTtVUa_dR7507BY6W2o=.6d810617-7a7f-4065-815a-ee3138261ae2@github.com>

On Mon, 28 Feb 2022 23:42:13 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> The tool measures the throughput of the operations, which is the number of cycles per iteration. Because the processor can execute multiple instructions at the same time, to measure the latency, you should create a dependency chain between the output of the instruction and its input in the next iteration. The technique used by uops.info is to `movsx` (which is an instruction that is not elided) from the output operand back to the input operand, so that the processor must wait for the result of the previous iteration before executing the next one, instead of executing multiple iterations concurrently when there is a lack of dependencies.
> 
> A simple `lea rax, [rbp + rcx + 0x8]; movsx rbp, eax` gives the throughput of 4 cycles, minus the latency of the `movsx` which is 1 gives you the documented latency of 3 (this is the latency between the output and the base operand, similar experiment will give the same answer for the latency between the output and the index operand).
> 
> Thanks.

Thanks for your clarification.
I will try it later today.

I would suggest reverting unnecessary changes of the other register operand definitions in the AD file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From sviswanathan at openjdk.java.net  Tue Mar  1 01:57:09 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 1 Mar 2022 01:57:09 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v6]
In-Reply-To: <Z4B8qhzPcjVwfeOVtdqg2jY0O1F7KaPjKHs0vc42dcg=.83c1e538-4a20-4762-89a2-97060e8933ab@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <Z4B8qhzPcjVwfeOVtdqg2jY0O1F7KaPjKHs0vc42dcg=.83c1e538-4a20-4762-89a2-97060e8933ab@github.com>
Message-ID: <vebauRd6DIyA2qje9cw2YAVXuzHeUlyqVe7vdPvZVo0=.1d791a9f-3de3-4b37-b236-d7e1ea81855a@github.com>

On Fri, 25 Feb 2022 01:11:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> 
>> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
>> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
>> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
>> 
>> 
>> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
>> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
>> 
>> Please review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8281375: Fix a typo.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4363:

> 4361:     movl(rtmp, 0x0F0F0F0F);
> 4362:     evpbroadcastd(xtmp1, rtmp, vec_enc);
> 4363:     evmovdqul(xtmp2, k0, ExternalAddress(StubRoutines::x86::vector_popcount_lut()), true, vec_enc, rtmp);

In general merge can be set to false for all the instructions in this algorithm as the mask is always all true.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4375:

> 4373:     evpunpckldq(xtmp2, k0, xtmp3, xtmp1, true, vec_enc);
> 4374:     evpsadbw(xtmp2, k0, xtmp2, xtmp1, true, vec_enc);
> 4375:     vpackuswb(dst, xtmp2, dst, vec_enc);

This doesn't look correct for say 512 bit vector length. At this point, the xtmp2 has 64-bit popcount results for lower 8 integers and dst has 64-bit popcount results for upper 8 integers. The vpackuswb does interleaving between xtmp2 and dst at 128 bit lanes so the result is not in correct order.

src/hotspot/cpu/x86/x86.ad line 1871:

> 1869:       if ((vlen == 16) && !VM_Version::supports_avx512vlbw()) {
> 1870:         return false;
> 1871:       }

This restriction was not there before this patch. This extra check should be only when supports_avx512_vpopcntdq() is false.

src/hotspot/cpu/x86/x86.ad line 1876:

> 1874:       if ((vlen <= 4) || ((vlen == 8) && !VM_Version::supports_avx512vlbw())) {
> 1875:         return false;
> 1876:       }

This restriction was not there before this patch. This extra check should be only when supports_avx512_vpopcntdq() is false.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From duke at openjdk.java.net  Tue Mar  1 02:28:00 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 1 Mar 2022 02:28:00 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v7]
In-Reply-To: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
Message-ID: <tNKnyG13TLhpmdmqj5rCrZ3nwiizmvuxghP-_byMdPg=.713531f5-531e-41b0-8abb-411cec6444d0@github.com>

> Hi,
> 
> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  remove irrelevent changes

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7560/files
  - new: https://git.openjdk.java.net/jdk/pull/7560/files/a866de71..31f23261

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=05-06

  Stats: 6 lines in 2 files changed: 1 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7560/head:pull/7560

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Tue Mar  1 02:29:38 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 1 Mar 2022 02:29:38 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v5]
In-Reply-To: <bQqm-OVDKj7riwhp8W1bMNKKeZ5fmurESHENA5QQT6I=.f2ca086b-53ae-4a3a-b0be-30a804eac444@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
 <oy1Ecg-Q0lCrL0_VYvXJ8bWmrTK7q76_ukRKgRDMAdw=.88a14343-12e3-4506-b968-8911407a75fc@github.com>
 <Td0k0p6nfSuNy586YViYw7qACpR-P3ZtVC4frPcPprg=.8508a6a6-5cdd-4d89-a25b-483b63f816f8@github.com>
 <bQqm-OVDKj7riwhp8W1bMNKKeZ5fmurESHENA5QQT6I=.f2ca086b-53ae-4a3a-b0be-30a804eac444@github.com>
Message-ID: <wSmPuep_SRNZXlrsQD6LEULw1SUkcjb159S6S994cm0=.de7a57ce-5570-4fd0-9f24-1d615363c74e@github.com>

On Mon, 28 Feb 2022 15:02:25 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Mostly for completeness only, do you think I should revert this? Thank you very much.
>
>> Mostly for completeness only, do you think I should revert this? Thank you very much.
> 
> Yes.
> I would suggest not touching unnecessary part of code.

Thanks, I have removed irrelevant changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From dlong at openjdk.java.net  Tue Mar  1 03:55:31 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 1 Mar 2022 03:55:31 GMT
Subject: RFR: 8282467: add extra diagnostics for JDK-8268184
Message-ID: <pe-I_0PKCP_idZQPdgxxQCZiZnig7EN-1-WTYk4hQ9A=.b35f3e96-3983-41dd-90dd-55b21b8fdf15@github.com>

Add more info to the assert to help diagnose what went wrong the next time it fails.

-------------

Commit messages:
 - add extra info to assert

Changes: https://git.openjdk.java.net/jdk/pull/7642/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7642&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282467
  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7642.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7642/head:pull/7642

PR: https://git.openjdk.java.net/jdk/pull/7642

From jbhateja at openjdk.java.net  Tue Mar  1 04:43:00 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 1 Mar 2022 04:43:00 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v6]
In-Reply-To: <vebauRd6DIyA2qje9cw2YAVXuzHeUlyqVe7vdPvZVo0=.1d791a9f-3de3-4b37-b236-d7e1ea81855a@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <Z4B8qhzPcjVwfeOVtdqg2jY0O1F7KaPjKHs0vc42dcg=.83c1e538-4a20-4762-89a2-97060e8933ab@github.com>
 <vebauRd6DIyA2qje9cw2YAVXuzHeUlyqVe7vdPvZVo0=.1d791a9f-3de3-4b37-b236-d7e1ea81855a@github.com>
Message-ID: <vXKnwFri-UtLPcwFg86Om-dLk40CK9YWkM2ht_g9-VA=.8e4c856d-57eb-4bf5-bf1c-71905d958d9e@github.com>

On Tue, 1 Mar 2022 01:52:59 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8281375: Fix a typo.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4375:
> 
>> 4373:     evpunpckldq(xtmp2, k0, xtmp3, xtmp1, true, vec_enc);
>> 4374:     evpsadbw(xtmp2, k0, xtmp2, xtmp1, true, vec_enc);
>> 4375:     vpackuswb(dst, xtmp2, dst, vec_enc);
> 
> This doesn't look correct for say 512 bit vector length. At this point, the xtmp2 has 64-bit popcount results for lower 8 integers and dst has 64-bit popcount results for upper 8 integers. The vpackuswb does interleaving between xtmp2 and dst at 128 bit lanes so the result is not in correct order.

original vector of integer = [ a3  a2  a1  a0]
unpackldq =  [0, a1, 0, a0]
unpackhdq = [ 0, a3 , 0 , a2]
perform sum of absolute difference and store the result into LSB 16 bits of each quad word.
packuswb  packs at lane granularity i.e, 128 bits packed.
      128 bit               128 bit
[0, sa3, 0, sa2]  [ 0, sa1, 0, sa0 ]  =>   [ sa3, sa2 , sa1, sa0]

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From darcy at openjdk.java.net  Tue Mar  1 06:20:07 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 1 Mar 2022 06:20:07 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v9]
In-Reply-To: <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>
Message-ID: <C8UrQ5i-1DBVeT7O3uFmyLkGTCmHLcRVkyupDPocqeg=.d7ecc45f-e9f2-4ab9-9d4f-8c084f0d1a6a@github.com>

On Fri, 25 Feb 2022 06:22:42 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
>> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279508: Adding descriptive comments.

test/jdk/java/lang/Math/RoundTests.java line 32:

> 30:     public static void main(String... args) {
> 31:         int failures = 0;
> 32:         for (int i = 0; i < 100000; i++) {

Is there an idiom to trigger the auto-vectorization, perhaps using command line arguments, that doesn't bloat the running time of this test?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From stuefe at openjdk.java.net  Tue Mar  1 08:28:05 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 1 Mar 2022 08:28:05 GMT
Subject: RFR: 8282467: add extra diagnostics for JDK-8268184
In-Reply-To: <pe-I_0PKCP_idZQPdgxxQCZiZnig7EN-1-WTYk4hQ9A=.b35f3e96-3983-41dd-90dd-55b21b8fdf15@github.com>
References: <pe-I_0PKCP_idZQPdgxxQCZiZnig7EN-1-WTYk4hQ9A=.b35f3e96-3983-41dd-90dd-55b21b8fdf15@github.com>
Message-ID: <53j8D0ipIn7lyqJVEoLniuEH7k8E-IANIxh4-92Y1ug=.b1155585-13e0-4b56-9be2-9e0c89390174@github.com>

On Tue, 1 Mar 2022 03:48:00 GMT, Dean Long <dlong at openjdk.org> wrote:

> Add more info to the assert to help diagnose what went wrong the next time it fails.

Looks good (and trivial).

Cheers, Thomas

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7642

From dlong at openjdk.java.net  Tue Mar  1 08:28:06 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 1 Mar 2022 08:28:06 GMT
Subject: RFR: 8282467: add extra diagnostics for JDK-8268184
In-Reply-To: <pe-I_0PKCP_idZQPdgxxQCZiZnig7EN-1-WTYk4hQ9A=.b35f3e96-3983-41dd-90dd-55b21b8fdf15@github.com>
References: <pe-I_0PKCP_idZQPdgxxQCZiZnig7EN-1-WTYk4hQ9A=.b35f3e96-3983-41dd-90dd-55b21b8fdf15@github.com>
Message-ID: <l8SKOi8U2YXTXRkjJMSmEF7RfDSxs9RydPjUOwFVulQ=.1fccf28d-55b8-4e20-a57e-6b00a867367c@github.com>

On Tue, 1 Mar 2022 03:48:00 GMT, Dean Long <dlong at openjdk.org> wrote:

> Add more info to the assert to help diagnose what went wrong the next time it fails.

Thanks Thomas!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7642

From dlong at openjdk.java.net  Tue Mar  1 08:28:06 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 1 Mar 2022 08:28:06 GMT
Subject: Integrated: 8282467: add extra diagnostics for JDK-8268184
In-Reply-To: <pe-I_0PKCP_idZQPdgxxQCZiZnig7EN-1-WTYk4hQ9A=.b35f3e96-3983-41dd-90dd-55b21b8fdf15@github.com>
References: <pe-I_0PKCP_idZQPdgxxQCZiZnig7EN-1-WTYk4hQ9A=.b35f3e96-3983-41dd-90dd-55b21b8fdf15@github.com>
Message-ID: <KRYW1fniNhhNyL580maFbfITMBHY-ya4W9RQPWhrmDc=.3ac29a9a-de13-4ebb-bebb-28ab6a012f94@github.com>

On Tue, 1 Mar 2022 03:48:00 GMT, Dean Long <dlong at openjdk.org> wrote:

> Add more info to the assert to help diagnose what went wrong the next time it fails.

This pull request has now been integrated.

Changeset: d3022f87
Author:    Dean Long <dlong at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d3022f87b598398d7130e984088ede6ffc9f48e1
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8282467: add extra diagnostics for JDK-8268184

Reviewed-by: stuefe

-------------

PR: https://git.openjdk.java.net/jdk/pull/7642

From thartmann at openjdk.java.net  Tue Mar  1 11:24:12 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 1 Mar 2022 11:24:12 GMT
Subject: RFR: 8280003: C1: Reconsider uses of logical_and immediates in
 LIRGenerator::do_getObjectSize [v5]
In-Reply-To: <SFtuct7rVbp36lQfSqGZhmUa7dI6eTc1mg8iWaWLw8k=.0fda8530-f076-4f8d-9e66-e1cf044d9636@github.com>
References: <4wfmxqeneC0qL6x2cFaMVp-AWoQVbognQdKjV_nx4_U=.40d443e8-d900-472c-857d-841efabebc3d@github.com>
 <LUkpkuk71swNdBlfo4Cutf2hrWGJyiDWNpHxvFGn9oY=.6d16fdb0-3a43-4327-b225-8e3343d6589a@github.com>
 <SFtuct7rVbp36lQfSqGZhmUa7dI6eTc1mg8iWaWLw8k=.0fda8530-f076-4f8d-9e66-e1cf044d9636@github.com>
Message-ID: <9l1WUJNoCCvcqzyi1qUjpBrHwPx_oGnkMSUwcv6mU3k=.23606457-c298-42bc-a57b-359ae8c60209@github.com>

On Tue, 8 Feb 2022 07:20:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert ARM32 checks
>
> This needs attention of compiler/C1 reviewer :)

@shipilev Looks like this is good to go in?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7080

From roland at openjdk.java.net  Tue Mar  1 12:05:05 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 1 Mar 2022 12:05:05 GMT
Subject: RFR: 8277055: Assert "missing inlining msg" with
 -XX:+PrintIntrinsics
In-Reply-To: <4O-VnRkcKYv4jHhr1XXsDudUMnhEebv-_ocX0stgqqE=.2f9d8be0-2105-4de0-bbca-ba06936e121e@github.com>
References: <4O-VnRkcKYv4jHhr1XXsDudUMnhEebv-_ocX0stgqqE=.2f9d8be0-2105-4de0-bbca-ba06936e121e@github.com>
Message-ID: <98x5pksGgRh2Qf1v35Yy4XCcoFC2EfOuAMf5zQ0HSDA=.a19a393e-e123-4f54-a186-9958a86bd986@github.com>

On Tue, 8 Feb 2022 16:57:20 GMT, Tobias Holenstein <duke at openjdk.java.net> wrote:

> in `CallGenerator::do_late_inline_helper()` we hit an assert `"missing inlining msg"` when calling  `C->print_inlining_update_delayed(this)`. The reason is that not all implementations of do_late_inline_check() print an inline message. The fix is to add an inline message for the two `return false` in `LateInlineVirtualCallGenerator::do_late_inline_check(...)` where we do not print an inline message.
> 
> Tier1-3 passed

Looks good to me.

-------------

Marked as reviewed by roland (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7385

From chagedorn at openjdk.java.net  Tue Mar  1 13:10:33 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 1 Mar 2022 13:10:33 GMT
Subject: RFR: 8282480: IGV: Use description instead of enum name for phases
Message-ID: <FdsSpYoxV2_538mVX6Pr71Mo_bhVmcsd8Ih4JPFOYhk=.57a60e02-3985-45e2-96a7-cee375f897f2@github.com>

[JDK-8281505](https://bugs.openjdk.java.net/browse/JDK-8281505) changed the `PrintIdeal` output to use the enum name of a phase when used with `PrintIdealPhase` instead of the description. However, it also changed the phase name shown in the IGV to the enum name. This should be reverted back for a better readability.

IGV after JDK-8281505:
![Screenshot from 2022-03-01 13-59-15](https://user-images.githubusercontent.com/17833009/156173248-7f6450cb-9816-437a-b5fa-816a2e214ad9.png)

IGV before JDK-8281505/with this patch:
![Screenshot from 2022-03-01 13-58-36](https://user-images.githubusercontent.com/17833009/156173243-0a0f975a-a44d-46a6-a48a-5183ff7600e1.png)

Thanks,
Christian

-------------

Commit messages:
 - 8282480: IGV: Use description instead of enum name for phases

Changes: https://git.openjdk.java.net/jdk/pull/7645/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7645&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282480
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7645.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7645/head:pull/7645

PR: https://git.openjdk.java.net/jdk/pull/7645

From redestad at openjdk.java.net  Tue Mar  1 13:32:58 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 1 Mar 2022 13:32:58 GMT
Subject: RFR: 8282480: IGV: Use description instead of enum name for phases
In-Reply-To: <FdsSpYoxV2_538mVX6Pr71Mo_bhVmcsd8Ih4JPFOYhk=.57a60e02-3985-45e2-96a7-cee375f897f2@github.com>
References: <FdsSpYoxV2_538mVX6Pr71Mo_bhVmcsd8Ih4JPFOYhk=.57a60e02-3985-45e2-96a7-cee375f897f2@github.com>
Message-ID: <i7mc7lnuYJKNdDOxqV4BO9Kh3h2l3lB8hyRIzFxAN3A=.1e16defd-74ff-4159-9a48-4d73c3ef110f@github.com>

On Tue, 1 Mar 2022 13:03:50 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> [JDK-8281505](https://bugs.openjdk.java.net/browse/JDK-8281505) changed the `PrintIdeal` output to use the enum name of a phase when used with `PrintIdealPhase` instead of the description. However, it also changed the phase name shown in the IGV to the enum name. This should be reverted back for a better readability.
> 
> IGV after JDK-8281505:
> ![Screenshot from 2022-03-01 13-59-15](https://user-images.githubusercontent.com/17833009/156173248-7f6450cb-9816-437a-b5fa-816a2e214ad9.png)
> 
> IGV before JDK-8281505/with this patch:
> ![Screenshot from 2022-03-01 13-58-36](https://user-images.githubusercontent.com/17833009/156173243-0a0f975a-a44d-46a6-a48a-5183ff7600e1.png)
> 
> Thanks,
> Christian

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7645

From thartmann at openjdk.java.net  Tue Mar  1 13:55:05 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 1 Mar 2022 13:55:05 GMT
Subject: RFR: 8282480: IGV: Use description instead of enum name for phases
In-Reply-To: <FdsSpYoxV2_538mVX6Pr71Mo_bhVmcsd8Ih4JPFOYhk=.57a60e02-3985-45e2-96a7-cee375f897f2@github.com>
References: <FdsSpYoxV2_538mVX6Pr71Mo_bhVmcsd8Ih4JPFOYhk=.57a60e02-3985-45e2-96a7-cee375f897f2@github.com>
Message-ID: <dwtL-QhRqzQnovYmdoqoQX8mnpdla1KiOKOwnEd2b80=.ba404a1d-66d2-4fee-aae4-fb92798566e8@github.com>

On Tue, 1 Mar 2022 13:03:50 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> [JDK-8281505](https://bugs.openjdk.java.net/browse/JDK-8281505) changed the `PrintIdeal` output to use the enum name of a phase when used with `PrintIdealPhase` instead of the description. However, it also changed the phase name shown in the IGV to the enum name. This should be reverted back for a better readability.
> 
> IGV after JDK-8281505:
> ![Screenshot from 2022-03-01 13-59-15](https://user-images.githubusercontent.com/17833009/156173248-7f6450cb-9816-437a-b5fa-816a2e214ad9.png)
> 
> IGV before JDK-8281505/with this patch:
> ![Screenshot from 2022-03-01 13-58-36](https://user-images.githubusercontent.com/17833009/156173243-0a0f975a-a44d-46a6-a48a-5183ff7600e1.png)
> 
> Thanks,
> Christian

Looks good and trivial.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7645

From thartmann at openjdk.java.net  Tue Mar  1 14:01:05 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 1 Mar 2022 14:01:05 GMT
Subject: RFR: 8281811: assert(_base == Tuple) failed: Not a Tuple after
 JDK-8280799 [v3]
In-Reply-To: <5cPXKQx_MBcV8TVASmC1CziX6khVGMIPePn0qa0nplU=.2c0621ea-b24b-4ef4-877f-b42d2977d330@github.com>
References: <a_7Y1Uefju944FJL6-WtUYidTw8ls0bVLlUGl0O5i2w=.70ff32d6-94a9-4f18-99cc-4e1b3fecd9b0@github.com>
 <5cPXKQx_MBcV8TVASmC1CziX6khVGMIPePn0qa0nplU=.2c0621ea-b24b-4ef4-877f-b42d2977d330@github.com>
Message-ID: <sJ9yYQKdwMxJ_32AFEJQ2qqmMSaUc8vNgn3m8LoxiWQ=.eb471005-8b99-4b5b-aac7-73372f2c2d8b@github.com>

On Mon, 28 Feb 2022 12:42:28 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The crash occurs because a Shenandoah barrier is expanded between the
>> Start node and its control projection. One of the test cases I added
>> also shows the same failure with a barrier expansion between a MemBar
>> and its control projection. The barrier is expanded at the control
>> that PhaseIdealLoop assigns to it.
>> 
>> This code:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L5756
>> I added back with JDK-8280799 is what's causing the incorrect
>> placement of the barrier.
>> 
>> The fix I propose is to skip that logic if the loop opts pass is for
>> barrier expansion as there's no range check elimination then.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   merge error

Okay, thanks for the explanation. Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7494

From thartmann at openjdk.java.net  Tue Mar  1 14:03:08 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 1 Mar 2022 14:03:08 GMT
Subject: RFR: 8282045: When loop strip mining fails,
 safepoints are removed from loop anyway [v2]
In-Reply-To: <lMuc_77DeCiZA8H-_SFgbMesoXYY8z9chtw4__Y40u0=.f3a4df78-1dca-4d0f-bd94-d16723945fe3@github.com>
References: <HjjLKneDt_iA-P-eny58G-TMOhc2VLJ-BxqeqtTfda0=.938174e0-c898-4757-b242-8d2cdf6c6c8c@github.com>
 <lMuc_77DeCiZA8H-_SFgbMesoXYY8z9chtw4__Y40u0=.f3a4df78-1dca-4d0f-bd94-d16723945fe3@github.com>
Message-ID: <meF1GHWSIm_gT1w-cwaMMuqlQz7h3ccT001ZcgMSZgA=.934cdbc2-0d88-4e99-85c3-603497c23047@github.com>

On Mon, 28 Feb 2022 13:20:41 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I noticed that if loop strip mining fails because a safepoint is not
>> found right above the exit test (following partial peel for instance),
>> all safepoints are removed from the loop anyway. That's fixed by the
>> change in IdealLoopTree::counted_loop() where rather than test if loop
>> strip mining is enabled, the check now verifies that loop strip mining
>> was successful.
>> 
>> With that change,
>> compiler/c2/irTests/TestAutoVectorization2DArray.java fails. The loop
>> is not converted into a strip mined loop because there's no safepoint
>> above the exit test after partial peeling. The loop strip mining logic
>> is too strict when it comes to the safepoint location. Any safepoint
>> that dominates the exit and is in the loop as long as there's no side
>> effect between the safepoint and the exit can be used. The patch
>> implements that change as well. TestAutoVectorization2DArray.java
>> passes as a result.
>> 
>> The existing requirement to have no safepoint on the backedge is too
>> strict as well. If the loop has another safepoint that can be used for
>> strip mining, then the safepoint on the backedge can safely be
>> dropped. That's also implemented by the patch.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into JDK-8282045
>  - whitespaces
>  - fix & test

Thanks, looks good to me.

Also, I executed some testing and it all passed.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7513

From roland at openjdk.java.net  Tue Mar  1 14:13:06 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 1 Mar 2022 14:13:06 GMT
Subject: RFR: 8281811: assert(_base == Tuple) failed: Not a Tuple after
 JDK-8280799 [v3]
In-Reply-To: <QKkbEhXwBUMsTFn7_6TDTaxrIcQBvRorT_cAldHNcZM=.25bd636d-ee98-414f-a603-61a17ae52b01@github.com>
References: <a_7Y1Uefju944FJL6-WtUYidTw8ls0bVLlUGl0O5i2w=.70ff32d6-94a9-4f18-99cc-4e1b3fecd9b0@github.com>
 <QKkbEhXwBUMsTFn7_6TDTaxrIcQBvRorT_cAldHNcZM=.25bd636d-ee98-414f-a603-61a17ae52b01@github.com>
Message-ID: <uf1uesgdiL6f9a5XGYIl1Fo6BW_Jy9UHmX-GsiIP_Kk=.1de93600-f4a5-48a3-979c-824e658131e8@github.com>

On Wed, 16 Feb 2022 19:02:27 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   merge error
>
> Good.

@vnkozlov @TobiHartmann thanks for the reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7494

From roland at openjdk.java.net  Tue Mar  1 14:13:08 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 1 Mar 2022 14:13:08 GMT
Subject: Integrated: 8281811: assert(_base == Tuple) failed: Not a Tuple after
 JDK-8280799
In-Reply-To: <a_7Y1Uefju944FJL6-WtUYidTw8ls0bVLlUGl0O5i2w=.70ff32d6-94a9-4f18-99cc-4e1b3fecd9b0@github.com>
References: <a_7Y1Uefju944FJL6-WtUYidTw8ls0bVLlUGl0O5i2w=.70ff32d6-94a9-4f18-99cc-4e1b3fecd9b0@github.com>
Message-ID: <Wqk3DkcQQ5fCSVom4ojGsat9Lj1S9oDfO-uLVBZPMqQ=.d06d1aab-d1ab-4cfa-8b0d-6a6b50b235c6@github.com>

On Wed, 16 Feb 2022 13:28:48 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The crash occurs because a Shenandoah barrier is expanded between the
> Start node and its control projection. One of the test cases I added
> also shows the same failure with a barrier expansion between a MemBar
> and its control projection. The barrier is expanded at the control
> that PhaseIdealLoop assigns to it.
> 
> This code:
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L5756
> I added back with JDK-8280799 is what's causing the incorrect
> placement of the barrier.
> 
> The fix I propose is to skip that logic if the loop opts pass is for
> barrier expansion as there's no range check elimination then.

This pull request has now been integrated.

Changeset: fcce24c5
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fcce24c5b3cd1dab755fd9b6779af71f4dd78773
Stats:     88 lines in 3 files changed: 74 ins; 0 del; 14 mod

8281811: assert(_base == Tuple) failed: Not a Tuple after JDK-8280799

Reviewed-by: kvn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7494

From duke at openjdk.java.net  Tue Mar  1 14:13:50 2022
From: duke at openjdk.java.net (Tobias Holenstein)
Date: Tue, 1 Mar 2022 14:13:50 GMT
Subject: RFR: 8277055: Assert "missing inlining msg" with
 -XX:+PrintIntrinsics [v2]
In-Reply-To: <4O-VnRkcKYv4jHhr1XXsDudUMnhEebv-_ocX0stgqqE=.2f9d8be0-2105-4de0-bbca-ba06936e121e@github.com>
References: <4O-VnRkcKYv4jHhr1XXsDudUMnhEebv-_ocX0stgqqE=.2f9d8be0-2105-4de0-bbca-ba06936e121e@github.com>
Message-ID: <e6eYiCN6OUirvoI8-CsjilFx5PyTVUTNti11Lq033mI=.fb2fb3d6-cea2-4067-a182-fbc92c0d5442@github.com>

> in `CallGenerator::do_late_inline_helper()` we hit an assert `"missing inlining msg"` when calling  `C->print_inlining_update_delayed(this)`. The reason is that not all implementations of do_late_inline_check() print an inline message. The fix is to add an inline message for the two `return false` in `LateInlineVirtualCallGenerator::do_late_inline_check(...)` where we do not print an inline message.
> 
> Tier1-3 passed

Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision:

  more detailed message

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7385/files
  - new: https://git.openjdk.java.net/jdk/pull/7385/files/162e97aa..deae1189

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7385&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7385&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7385.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7385/head:pull/7385

PR: https://git.openjdk.java.net/jdk/pull/7385

From thartmann at openjdk.java.net  Tue Mar  1 14:13:51 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 1 Mar 2022 14:13:51 GMT
Subject: RFR: 8277055: Assert "missing inlining msg" with
 -XX:+PrintIntrinsics [v2]
In-Reply-To: <e6eYiCN6OUirvoI8-CsjilFx5PyTVUTNti11Lq033mI=.fb2fb3d6-cea2-4067-a182-fbc92c0d5442@github.com>
References: <4O-VnRkcKYv4jHhr1XXsDudUMnhEebv-_ocX0stgqqE=.2f9d8be0-2105-4de0-bbca-ba06936e121e@github.com>
 <e6eYiCN6OUirvoI8-CsjilFx5PyTVUTNti11Lq033mI=.fb2fb3d6-cea2-4067-a182-fbc92c0d5442@github.com>
Message-ID: <74tdeSabkBWUN8o7TbaTAvPMlWsze-e9T9AavG0X3rQ=.13d080af-adb6-4bbd-b076-677807ce36a2@github.com>

On Tue, 1 Mar 2022 14:09:38 GMT, Tobias Holenstein <duke at openjdk.java.net> wrote:

>> in `CallGenerator::do_late_inline_helper()` we hit an assert `"missing inlining msg"` when calling  `C->print_inlining_update_delayed(this)`. The reason is that not all implementations of do_late_inline_check() print an inline message. The fix is to add an inline message for the two `return false` in `LateInlineVirtualCallGenerator::do_late_inline_check(...)` where we do not print an inline message.
>> 
>> Tier1-3 passed
>
> Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more detailed message

Looks good to me too. Thanks for updating the inlining message to include the reason.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7385

From chagedorn at openjdk.java.net  Tue Mar  1 14:27:02 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 1 Mar 2022 14:27:02 GMT
Subject: RFR: 8282480: IGV: Use description instead of enum name for phases
In-Reply-To: <FdsSpYoxV2_538mVX6Pr71Mo_bhVmcsd8Ih4JPFOYhk=.57a60e02-3985-45e2-96a7-cee375f897f2@github.com>
References: <FdsSpYoxV2_538mVX6Pr71Mo_bhVmcsd8Ih4JPFOYhk=.57a60e02-3985-45e2-96a7-cee375f897f2@github.com>
Message-ID: <sRlnaLXf0s1XqIfN35EntQqKcnjL-PGXUd6wOTMK3Gw=.d1f8a14a-584b-4398-9747-0c7457de4e0a@github.com>

On Tue, 1 Mar 2022 13:03:50 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> [JDK-8281505](https://bugs.openjdk.java.net/browse/JDK-8281505) changed the `PrintIdeal` output to use the enum name of a phase when used with `PrintIdealPhase` instead of the description. However, it also changed the phase name shown in the IGV to the enum name. This should be reverted back for a better readability.
> 
> IGV after JDK-8281505:
> ![Screenshot from 2022-03-01 13-59-15](https://user-images.githubusercontent.com/17833009/156173248-7f6450cb-9816-437a-b5fa-816a2e214ad9.png)
> 
> IGV before JDK-8281505/with this patch:
> ![Screenshot from 2022-03-01 13-58-36](https://user-images.githubusercontent.com/17833009/156173243-0a0f975a-a44d-46a6-a48a-5183ff7600e1.png)
> 
> Thanks,
> Christian

Thanks Claes and Tobias for your reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7645

From chagedorn at openjdk.java.net  Tue Mar  1 14:37:08 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 1 Mar 2022 14:37:08 GMT
Subject: RFR: 8282045: When loop strip mining fails,
 safepoints are removed from loop anyway [v2]
In-Reply-To: <lMuc_77DeCiZA8H-_SFgbMesoXYY8z9chtw4__Y40u0=.f3a4df78-1dca-4d0f-bd94-d16723945fe3@github.com>
References: <HjjLKneDt_iA-P-eny58G-TMOhc2VLJ-BxqeqtTfda0=.938174e0-c898-4757-b242-8d2cdf6c6c8c@github.com>
 <lMuc_77DeCiZA8H-_SFgbMesoXYY8z9chtw4__Y40u0=.f3a4df78-1dca-4d0f-bd94-d16723945fe3@github.com>
Message-ID: <U4gxhKlZoulyj25alxI16P86MpeM_OavesQqiYbJrH0=.55251235-7648-4310-b2dc-b3797d85736d@github.com>

On Mon, 28 Feb 2022 13:20:41 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I noticed that if loop strip mining fails because a safepoint is not
>> found right above the exit test (following partial peel for instance),
>> all safepoints are removed from the loop anyway. That's fixed by the
>> change in IdealLoopTree::counted_loop() where rather than test if loop
>> strip mining is enabled, the check now verifies that loop strip mining
>> was successful.
>> 
>> With that change,
>> compiler/c2/irTests/TestAutoVectorization2DArray.java fails. The loop
>> is not converted into a strip mined loop because there's no safepoint
>> above the exit test after partial peeling. The loop strip mining logic
>> is too strict when it comes to the safepoint location. Any safepoint
>> that dominates the exit and is in the loop as long as there's no side
>> effect between the safepoint and the exit can be used. The patch
>> implements that change as well. TestAutoVectorization2DArray.java
>> passes as a result.
>> 
>> The existing requirement to have no safepoint on the backedge is too
>> strict as well. If the loop has another safepoint that can be used for
>> strip mining, then the safepoint on the backedge can safely be
>> dropped. That's also implemented by the patch.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into JDK-8282045
>  - whitespaces
>  - fix & test

Looks good to me!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7513

From roland at openjdk.java.net  Tue Mar  1 14:47:07 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 1 Mar 2022 14:47:07 GMT
Subject: RFR: 8282045: When loop strip mining fails,
 safepoints are removed from loop anyway [v2]
In-Reply-To: <meF1GHWSIm_gT1w-cwaMMuqlQz7h3ccT001ZcgMSZgA=.934cdbc2-0d88-4e99-85c3-603497c23047@github.com>
References: <HjjLKneDt_iA-P-eny58G-TMOhc2VLJ-BxqeqtTfda0=.938174e0-c898-4757-b242-8d2cdf6c6c8c@github.com>
 <lMuc_77DeCiZA8H-_SFgbMesoXYY8z9chtw4__Y40u0=.f3a4df78-1dca-4d0f-bd94-d16723945fe3@github.com>
 <meF1GHWSIm_gT1w-cwaMMuqlQz7h3ccT001ZcgMSZgA=.934cdbc2-0d88-4e99-85c3-603497c23047@github.com>
Message-ID: <hEUJfsrXsNHqoLN_6n0M8F4HD1397BeLDBrfKPsdSas=.1eb7b166-2e2e-41ba-a24c-18d5090f0210@github.com>

On Tue, 1 Mar 2022 13:59:31 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - review
>>  - Merge branch 'master' into JDK-8282045
>>  - whitespaces
>>  - fix & test
>
> Also, I executed some testing and it all passed.

@TobiHartmann @chhagedorn thanks for the reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7513

From roland at openjdk.java.net  Tue Mar  1 14:47:09 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 1 Mar 2022 14:47:09 GMT
Subject: Integrated: 8282045: When loop strip mining fails,
 safepoints are removed from loop anyway
In-Reply-To: <HjjLKneDt_iA-P-eny58G-TMOhc2VLJ-BxqeqtTfda0=.938174e0-c898-4757-b242-8d2cdf6c6c8c@github.com>
References: <HjjLKneDt_iA-P-eny58G-TMOhc2VLJ-BxqeqtTfda0=.938174e0-c898-4757-b242-8d2cdf6c6c8c@github.com>
Message-ID: <iepx_1tuECoz8fhniZfYuPrJVWRescCtgcWLU6znhLY=.42fbd0ed-bf71-4645-a8b8-576392ec69ca@github.com>

On Thu, 17 Feb 2022 10:00:32 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> I noticed that if loop strip mining fails because a safepoint is not
> found right above the exit test (following partial peel for instance),
> all safepoints are removed from the loop anyway. That's fixed by the
> change in IdealLoopTree::counted_loop() where rather than test if loop
> strip mining is enabled, the check now verifies that loop strip mining
> was successful.
> 
> With that change,
> compiler/c2/irTests/TestAutoVectorization2DArray.java fails. The loop
> is not converted into a strip mined loop because there's no safepoint
> above the exit test after partial peeling. The loop strip mining logic
> is too strict when it comes to the safepoint location. Any safepoint
> that dominates the exit and is in the loop as long as there's no side
> effect between the safepoint and the exit can be used. The patch
> implements that change as well. TestAutoVectorization2DArray.java
> passes as a result.
> 
> The existing requirement to have no safepoint on the backedge is too
> strict as well. If the loop has another safepoint that can be used for
> strip mining, then the safepoint on the backedge can safely be
> dropped. That's also implemented by the patch.

This pull request has now been integrated.

Changeset: 2c5d266f
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2c5d266f9f20005bc2a6c30dcaa95b059ea59d74
Stats:     203 lines in 3 files changed: 165 ins; 25 del; 13 mod

8282045: When loop strip mining fails, safepoints are removed from loop anyway

Reviewed-by: thartmann, chagedorn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7513

From thartmann at openjdk.java.net  Tue Mar  1 15:40:04 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 1 Mar 2022 15:40:04 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v6]
In-Reply-To: <vqG5pdUa0dej8EieLWHPXmdhMEQFaCcjMZjyL_c_PQM=.3ba2368a-664d-48ae-9ee8-57ff0533818b@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <vqG5pdUa0dej8EieLWHPXmdhMEQFaCcjMZjyL_c_PQM=.3ba2368a-664d-48ae-9ee8-57ff0533818b@github.com>
Message-ID: <01jKztyIoud-G62fKKAjCGrhBZuJeD5Nr8ZkHYOyTFA=.20ef8440-00f9-45cb-a107-805f88b477b4@github.com>

On Fri, 25 Feb 2022 12:57:46 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
>> 
>> It starts by dumping the inital EA worklist, and then has individual trace messages for when a node's escape state is updated, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
>> 
>> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
>> 
>> <details>
>> <summary>Sample output (click to unfold)</summary>
>> 
>> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
>> 
>> 
>> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
>> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
>> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
>> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
>> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
>> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
>> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
>> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> +++++ Calculating escapse states and scalar replaceability
>> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> 
>> </details>
>> 
>> Testing: 
>> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
>> - Tier1-4
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce indentation
>   
>   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

Marked as reviewed by thartmann (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7428

From iveresov at openjdk.java.net  Tue Mar  1 15:50:24 2022
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 1 Mar 2022 15:50:24 GMT
Subject: RFR: 8279886: C1: Turn off SelectivePhiFunctions in presence of
 irreducible loops [v2]
In-Reply-To: <9hUbaevqiNT2GmsBxLbGYHYFmSMeDZZDaBkUpuJFBHk=.b7da7542-844d-4d8c-8f61-ee0eca5a3500@github.com>
References: <9hUbaevqiNT2GmsBxLbGYHYFmSMeDZZDaBkUpuJFBHk=.b7da7542-844d-4d8c-8f61-ee0eca5a3500@github.com>
Message-ID: <Yoat8TsWJuuo2NKA-3ze-kdcBqb_9jJwDL568NYH31k=.ff83b2da-8eac-4a5f-a514-433238897826@github.com>

> This change add irreducible loops detection to `BlockListBuilder::mark_loops()` - a loop marking routine necessary for the SSA conversion. Here is brief description of the algorithm (copy-pasted from the comments I left in the code).
> 
> The loop detection algorithm works as follows:
> 
> - We maintain the `_loop_map`, where for each block we have a bitmap indicating which loops contain this block.
> - The CFG is recursively traversed (depth-first) and if we detect a loop, we assign the loop a unique number that is stored in the bitmap associated with the loop header block. Until we return back through that loop header the bitmap contains only a single bit corresponding to the loop number.
> - The bit is then propagated for all the blocks in the loop after we exit them (post-order). There could be multiple bits of course in case of nested loops.
> - When we exit the loop header we remove that single bit and assign the real loop state for it.
> - Now, the tricky part here is how we detect irriducible loops. In the algorithm above the loop state bits are propagated to the predecessors. If we encounter an irreducible loop (a loop with multiple heads) we would see a node with some loop bit set that would then propagate back and be never cleared because we would never go back through the original loop header. Therefore if there are any irreducible loops the bits in the states for these loops are going to propagate back to the root.
> 
> Testing is clean: hs-tier{1-7}

Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Add comments
 - Detect irreducible loops during parsing/phi insertion.

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7636/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7636&range=01
  Stats: 63 lines in 5 files changed: 27 ins; 7 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7636.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7636/head:pull/7636

PR: https://git.openjdk.java.net/jdk/pull/7636

From kvn at openjdk.java.net  Tue Mar  1 16:10:10 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 1 Mar 2022 16:10:10 GMT
Subject: RFR: 8281548: Add escape analysis tracing flag [v6]
In-Reply-To: <vqG5pdUa0dej8EieLWHPXmdhMEQFaCcjMZjyL_c_PQM=.3ba2368a-664d-48ae-9ee8-57ff0533818b@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
 <vqG5pdUa0dej8EieLWHPXmdhMEQFaCcjMZjyL_c_PQM=.3ba2368a-664d-48ae-9ee8-57ff0533818b@github.com>
Message-ID: <s5NMyoJx0zjCbXpcQB7UfPzzvm7o9nnLJt71518_YWs=.a53b17b2-3d56-4edc-a720-d3cb402b74fe@github.com>

On Fri, 25 Feb 2022 12:57:46 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
>> 
>> It starts by dumping the inital EA worklist, and then has individual trace messages for when a node's escape state is updated, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
>> 
>> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
>> 
>> <details>
>> <summary>Sample output (click to unfold)</summary>
>> 
>> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
>> 
>> 
>> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
>> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
>> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
>> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
>> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
>> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
>> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
>> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> +++++ Calculating escapse states and scalar replaceability
>> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
>> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
>> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
>> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
>> 
>> </details>
>> 
>> Testing: 
>> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
>> - Tier1-4
>> 
>> Thanks,
>> Jorn
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce indentation
>   
>   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

Good

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7428

From jvernee at openjdk.java.net  Tue Mar  1 16:31:05 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 1 Mar 2022 16:31:05 GMT
Subject: Integrated: 8281548: Add escape analysis tracing flag
In-Reply-To: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
References: <2dtKKhSjWC-V6rTVyrtDJBD0srUUWy5BDdAJjsoTaac=.68a0d585-4931-4114-ae72-1e9fbbfe32d8@github.com>
Message-ID: <TzOQ5naYpGMTalKPqvDVqP7ZwmMMm3Xj4bHWvSODKcw=.f1b17b59-ab64-4a2e-a70a-e42d6588f8ea@github.com>

On Thu, 10 Feb 2022 16:41:09 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> This PR adds `TraceEscapeAnalysis` as a compiler directive and compile command (but not as global flag). The flag is intended to be used to track down the source of an object's escape, or why it is disqualified from scalar replacement for another reason.
> 
> It starts by dumping the inital EA worklist, and then has individual trace messages for when a node's escape state is updated, or when it is marked as not scalar replaceable. I've already succesfully used this to track down a failure to scalar replace an allocation myself (see sample output), so it seemed useful to upstream.
> 
> There were also 2 instances where I couldn't quite figure out the reason for a state update from the surrounding code. I've left the reason string as "reason unknown" in those cases, for now. Maybe someone could point out a better reason string for those cases?
> 
> <details>
> <summary>Sample output (click to unfold)</summary>
> 
> The object I'm interested in is represented by node JavaObject(22). From the messages under `+++++ Calculating escapse states and scalar replaceability` it can be traced back like: JavaObject(22) ->LocalVar(46) -> LocalVar(55) -> LocalVar(60) -> escapes as argument to call.
> 
> 
> +++++ Initial worklist for static jint main.PtrPass.panama_call_as_address(jobject) (ea_inv=0)
> JavaObject(0) GlobalEscape(GlobalEscape) NSR [ [ 66 255 248 241 246 ]]   1  Con  ===  0  [[]]  #top
> JavaObject(2) GlobalEscape(GlobalEscape) NSR [ [ ]]   88  ConP  ===  0  [[ 162  44  42  154  57  43 ]]  #java/lang/invoke/BoundMethodHandle$Species_L:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_L:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(3) GlobalEscape(GlobalEscape) NSR [ [ ]]   65  ConP  ===  0  [[ 106  36  41  40  38  39 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLLL:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(4) GlobalEscape(GlobalEscape) NSR [ [ ]]   242  ConP  ===  0  [[ 216 ]]  #precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact *  Klass:precise jdk/internal/foreign/NativeMemorySegmentImpl: 0x00000281c0ebb790:Constant:exact * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(5) GlobalEscape(GlobalEscape) NSR [ [ ]]   89  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(6) GlobalEscape(GlobalEscape) NSR [ [ ]]   126  ConP  ===  0  [[ 54 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(7) GlobalEscape(GlobalEscape) NSR [ [ ]]   132  ConP  ===  0  [[ 57 ]]  #jdk/internal/invoke/NativeEntryPoint:exact *  Oop:jdk/internal/invoke/NativeEntryPoint:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(8) GlobalEscape(GlobalEscape) NSR [ [ ]]   98  ConP  ===  0  [[ 43  57  44 ]]  #jdk/internal/foreign/abi/Binding$Context$3:exact *  Oop:jdk/internal/foreign/abi/Binding$Context$3:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(10) GlobalEscape(GlobalEscape) NSR [ [ ]]   270  ConP  ===  0  [[ 263 ]]  #precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact *  Klass:precise jdk/internal/foreign/ResourceScopeImpl$GlobalScopeImpl: 0x00000281c09d2ae0:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(11) GlobalEscape(GlobalEscape) NSR [ [ ]]   247  ConP  ===  0  [[ 224 ]]  #precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact *  Klass:precise jdk/internal/foreign/ConfinedScope: 0x00000281c09d2ba8:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(12) GlobalEscape(GlobalEscape) NSR [ [ ]]   161  ConP  ===  0  [[ 106  237  229 ]]  #precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact *  Klass:precise jdk/internal/foreign/MemoryAddressImpl: 0x00000281c0ebb858:Constant:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(13) GlobalEscape(GlobalEscape) NSR [ [ ]]   170  ConN  ===  0  [[ 118  235 ]]  #narrowoop: jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(14) GlobalEscape(GlobalEscape) NSR [ [ ]]   123  ConP  ===  0  [[ 154  54 ]]  #precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact *  Klass:precise [jdk/internal/foreign/Scoped: 0x00000281c0ee6438 *: :Constant:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(15) GlobalEscape(GlobalEscape) NSR [ [ ]]   128  ConP  ===  0  [[ 54  154 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(16) GlobalEscape(GlobalEscape) NSR [ [ ]]   87  ConP  ===  0  [[ 54  162  42  57  44  43  42  154  154  154  42 ]]  #jdk/internal/foreign/NativeSymbolImpl:exact *  Oop:jdk/internal/foreign/NativeSymbolImpl:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(17) GlobalEscape(GlobalEscape) NSR [ [ ]]   93  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/MemberName:exact *  Oop:java/lang/invoke/MemberName:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(18) GlobalEscape(GlobalEscape) NSR [ [ ]]   92  ConP  ===  0  [[ 42 ]]  #java/lang/Class:exact *  Oop:java/lang/Class:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(19) GlobalEscape(GlobalEscape) NSR [ [ ]]   91  ConP  ===  0  [[ 42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(20) GlobalEscape(GlobalEscape) NSR [ [ ]]   90  ConP  ===  0  [[ 154  42 ]]  #java/lang/invoke/BoundMethodHandle$Species_LLL:exact *  Oop:java/lang/invoke/BoundMethodHandle$Species_LLL:exact * !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(1) NoEscape(NoEscape) [ [ ]]   62  ConP  ===  0  [[ 215  34  217  37  260 ]]  #NULL !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(21) NoEscape(NoEscape) [ [ 234 ]]   154  AllocateArray  ===  174  83  84  15  1 ( 122  123  124  125  1  1  1  1  1  86  87  1  88  1  1  1  1  1  1  89  87  86  1  1  1  1  90  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 258  257  209  252  95  234 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c400::invoke @ bci:16 0x0000000800c21c00::invoke @ bci:46 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47)
> JavaObject(22) NoEscape(NoEscape) [ [ 198 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) +8 ( )[ [ ]]   269  AddP  === _  66  66  274  [[ 259 ]]   Interface:java/lang/foreign/MemorySegment:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) +8 ( )[ [ ]]   273  AddP  === _  101  101  274  [[ 268 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) +8 ( )[ [ ]]   272  AddP  === _  86  86  274  [[ 265 ]]   Interface:java/lang/foreign/MemoryAddress:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(26) NoEscape(NoEscape) +8 ( )[ [ ]]   271  AddP  === _  71  71  274  [[ 264 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+8 * [narrowklass] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:31 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(27) NoEscape(NoEscape) [ [ 117 ]]   54  AllocateArray  ===  120  121  55  15  1 ( 122  123  124  125  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  33  1  1  1  126  1  1  1  1  1  1  1  1  1  87  127  1  1  128  1  1  1  1  1  1  1  1  1  1  1 ) [[ 203  164  107  168  31  117 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) Array::newInstance @ bci:2 (line 78) 0x0000000800c05c00::invokeStatic @ bci:11 0x0000000800c06800::invoke @ bci:21 0x0000000800c15800::collector @ bci:13 0x0000000800c1c000::invoke @ bci:44 0x0000000800c1c800::invoke @ bci:17 0x0000000800c21c00::invoke @ bci:61 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(28) NoEscape(NoEscape) oop +24 ( )[ [ 182 ]]   220  AddP  === _  70  70  122  [[ 182 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(29) NoEscape(NoEscape) oop +24 ( )[ [ 143 ]]   184  AddP  === _  71  71  122  [[ 143 ]]   Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull+24 * [narrow] !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) oop ( 221P )[ [ 142 ]]   183  AddP  === _  1  221  222  [[ 142 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(31) NoEscape(NoEscape) +12 ( )[ [ ]]   146  AddP  === _  189  189  190  [[ 77 ]]   Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact+12 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(32) NoEscape(NoEscape) oop +20 ( )[ [ ]]   171  AddP  === _  1  117  212  [[ 119 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(33) NoEscape(NoEscape) oop +20 ( )[ [ ]]   254  AddP  === _  1  234  212  [[ 236 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(34) NoEscape(NoEscape) +32 ( )[ [ ]]   148  AddP  === _  70  70  193  [[ 80 ]]   Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact+32 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(35) NoEscape(NoEscape) oop +16 ( )[ [ ]]   169  AddP  === _  1  117  211  [[ 118 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) +16 ( )[ [ ]]   267  AddP  === _  1  198  211  [[ 251 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) +16 ( )[ [ ]]   175  AddP  === _  214  214  211  [[ 131 ]]   Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact+16 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(38) NoEscape(NoEscape) oop +16 ( )[ [ ]]   253  AddP  === _  1  234  211  [[ 235 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(39) NoEscape(NoEscape) [ [ ]]   72  LoadP  === _  60  142  [[ 38  219 ]]  @rawptr:NotNull, idx=Raw; #java/lang/Thread:NotNull *  Oop:java/lang/Thread:NotNull *
> LocalVar(40) NoEscape(NoEscape) [ 183F [ ]]   142  LoadP  === _  60  183  [[ 72 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:NotNull (does not depend only on test) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(41) NoEscape(NoEscape) [ 184F [ 73 ]]   143  LoadN  === _  60  184  [[ 73 ]]  @jdk/internal/foreign/ResourceScopeImpl+24 * [narrow], name=owner, idx=6; #narrowoop: java/lang/Thread * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(42) NoEscape(NoEscape) [ 220F [ 141 ]]   182  LoadN  === _  60  220  [[ 141 ]]  @jdk/internal/foreign/AbstractMemorySegmentImpl+24 * [narrow], name=scope, idx=5; #narrowoop: jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(43) GlobalEscape(GlobalEscape) [ [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(44) NoEscape(NoEscape) [ 1P [ 70 ]]   66  CastPP  ===  135  136  [[ 36  269  269  70 ]]  #java/lang/foreign/MemorySegment:NotNull *  Interface:java/lang/foreign/MemorySegment:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(45) NoEscape(NoEscape) [ 154P [ ]]   234  Proj  ===  154  [[ 200  254  253 ]] #5 !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) [ 106P [ 152 ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(47) NoEscape(NoEscape) [ 54P [ ]]   117  Proj  ===  54  [[ 53  171  169 ]] #5 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(48) NoEscape(NoEscape) [ 1P [ ]]   255  DecodeNKlass  === _  268  [[ 237 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(49) NoEscape(NoEscape) [ 1P [ ]]   248  DecodeNKlass  === _  265  [[ 229 ]]  #java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *  Interface:java/lang/foreign/MemoryAddress: 0x00000281c0ebd120 *
> LocalVar(50) NoEscape(NoEscape) [ 1P [ ]]   241  DecodeNKlass  === _  259  [[ 216 ]]  #java/lang/foreign/MemorySegment: 0x00000281c0ebad38 *  Interface:java/lang/foreign/MemorySegment: 0x00000281c0ebad38 * !jvms: ConfinedScope::isAlive @ bci:6 (line 60) ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(51) NoEscape(NoEscape) [ 143 [ ]]   73  DecodeN  === _  143  [[ 219  260  38 ]]  #java/lang/Thread *  Oop:java/lang/Thread * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(52) NoEscape(NoEscape) [ 1P [ ]]   246  DecodeNKlass  === _  264  [[ 263  224 ]]  #jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 *  Klass:jdk/internal/foreign/ResourceScopeImpl: 0x00000281c0ec1c38 * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:-1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(53) NoEscape(NoEscape) [ 182 [ 71 ]]   141  DecodeN  === _  182  [[ 71  217 ]]  #jdk/internal/foreign/ResourceScopeImpl *  Oop:jdk/internal/foreign/ResourceScopeImpl * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:1 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(54) NoEscape(NoEscape) [ 66 [ ]]   70  CheckCastPP  ===  139  66  [[ 148  148  40  39  38  220  220 ]]  #jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact *  Oop:jdk/internal/foreign/NativeMemorySegmentImpl:NotNull:exact * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(56) NoEscape(NoEscape) [ 141 [ 189 ]]   71  CastPP  ===  140  141  [[ 39  189  271  271  184  184  38 ]]  #jdk/internal/foreign/ResourceScopeImpl:NotNull *  Oop:jdk/internal/foreign/ResourceScopeImpl:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) NoEscape(NoEscape) [ [ ]]   52  Phi  ===  46  112  113  114  [[ 29 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull *
> LocalVar(58) NoEscape(NoEscape) [ [ ]]   114  Phi  ===  165  166  167  [[ 52  162  162 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !orig=2293 !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(59) NoEscape(NoEscape) [ [ ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) [ 152 [ 127 ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(61) NoEscape(NoEscape) [ 71 [ ]]   189  CheckCastPP  ===  187  71  [[ 146  146 ]]  #jdk/internal/foreign/ConfinedScope:NotNull:exact *  Oop:jdk/internal/foreign/ConfinedScope:NotNull:exact *
> LocalVar(62) NoEscape(NoEscape) [ 86 [ 101 172 ]]   127  CheckCastPP  ===  174  86  [[ 54  101  154  172 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(63) NoEscape(NoEscape) [ [ ]]   214  CheckCastPP  ===  129  101  [[ 175  175 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(64) NoEscape(NoEscape) [ 127 [ ]]   101  CheckCastPP  === _  127  [[ 214  44  273  273 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:-1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(65) NoEscape(NoEscape) [ 127 [ ]]   172  EncodeP  === _  127  [[ 119  236 ]]  #narrowoop: jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> +++++ Calculating escapse states and scalar replaceability
> LocalVar(58) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(58) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) NoEscape(NoEscape) -> GlobalEscape(NoEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(60) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) escapes as arg to: 162  CallStaticJava  ===  165  205  206  15  1 ( 88  114  124  87  86  1  1  1  1  1  1  1  1  1  1  1  1  1  1  1  114 ) [[ 204  108  163 ]] # Static  java.lang.invoke.MethodHandle::invokeBasic(LILL)I int ( java/lang/invoke/MethodHandle:NotNull *, java/lang/Object *, int, java/lang/Object *, java/lang/Object * ) 0x0000000800c21c00::invoke @ bci:77 0x0000000800c20c00::invokeExact_MT @ bci:19 PtrPass::panama_call_as_address @ bci:9 (line 47) !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:14 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(55) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(60) GlobalEscape(GlobalEscape) [ 152 [ 127 272b ]]   86  CheckCastPP  === _  152  [[ 162  272  272  42  42  42  154  154  43  43  44  57  127 ]]  #java/lang/foreign/MemoryAddress:NotNull *  Interface:java/lang/foreign/MemoryAddress:NotNull * !orig=[431],2290 !jvms: NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(46) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(55) GlobalEscape(GlobalEscape) [ 198 [ 86 ]]   152  CheckCastPP  ===  196  198  [[ 151  86 ]]  #jdk/internal/foreign/MemoryAddressImpl:NotNull:exact *  Oop:jdk/internal/foreign/MemoryAddressImpl:NotNull:exact * !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:4 (line 203) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> JavaObject(22) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> JavaObject(22) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(46) GlobalEscape(GlobalEscape) [ 106P [ 152 267b ]]   198  Proj  ===  106  [[ 230  152  267 ]] #5
> LocalVar(59) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(59) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(43) GlobalEscape(GlobalEscape) [ 29 [ ]]   12  Rethrow  ===  25  26  27  15  28 exception 29  [[ 0 ]] 
> LocalVar(57) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> LocalVar(57) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: LocalVar(59) GlobalEscape(GlobalEscape) [ 1P 52 [ 12 ]]   29  Phi  ===  25  51  52  [[ 12 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) NoEscape(NoEscape) -> ArgEscape(NoEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(30) ArgEscape(NoEscape) -> ArgEscape(ArgEscape) propagated from: JavaObject(9) ArgEscape(ArgEscape) NSR [ 183F [ ]]   221  ThreadLocal  ===  0  [[ 183 ]]  !jvms: ResourceScopeImpl::checkValidStateSlow @ bci:28 (line 205) AbstractMemorySegmentImpl::checkValidState @ bci:4 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(36) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(25) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(24) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(37) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(22) GlobalEscape(GlobalEscape) [ 267F 272F 273F 175F [ 198 152 86 127 101 172 214 254 171 ]]   106  Allocate  ===  160  59  60  15  1 ( 122  161  124  1  1  65  1  80  1 ) [[ 157  110  47  266  83  198 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, top ) MemoryAddress::ofLong @ bci:12 (line 165) NativeMemorySegmentImpl::address @ bci:8 (line 65) PtrPass::panama_call_as_address @ bci:4 (line 47) !jvms: AbstractMemorySegmentImpl::checkValidState @ bci:1 (line 366) NativeMemorySegmentImpl::address @ bci:1 (line 64) PtrPass::panama_call_as_address @ bci:4 (line 47)
> Field(23) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(23) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(28) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(34) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 ]]   1  Con  ===  0  [[]]  #top
> Field(26) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(26) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(29) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) NoEscape(NoEscape) -> GlobalEscape(NoEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> Field(31) GlobalEscape(NoEscape) -> GlobalEscape(GlobalEscape) propagated from: JavaObject(0) GlobalEscape(GlobalEscape) NSR [ 269F 220F 148F 271F 184F 146F [ 66 255 248 241 246 29 114 52 183 142 72 70 12 220 182 141 71 189 ]]   1  Con  ===  0  [[]]  #top
> 
> </details>
> 
> Testing: 
> - Manually running hotspot compiler tests with `-XX:CompileCommand=TraceEscapeAnalysis,*::*`
> - Tier1-4
> 
> Thanks,
> Jorn

This pull request has now been integrated.

Changeset: 8fec7b87
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8fec7b87c1bc762f9c8ef41cd715d5aaab4c0324
Stats:     141 lines in 4 files changed: 96 ins; 0 del; 45 mod

8281548: Add escape analysis tracing flag

Reviewed-by: kvn, thartmann, xliu

-------------

PR: https://git.openjdk.java.net/jdk/pull/7428

From sviswanathan at openjdk.java.net  Tue Mar  1 16:38:06 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 1 Mar 2022 16:38:06 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v6]
In-Reply-To: <vXKnwFri-UtLPcwFg86Om-dLk40CK9YWkM2ht_g9-VA=.8e4c856d-57eb-4bf5-bf1c-71905d958d9e@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <Z4B8qhzPcjVwfeOVtdqg2jY0O1F7KaPjKHs0vc42dcg=.83c1e538-4a20-4762-89a2-97060e8933ab@github.com>
 <vebauRd6DIyA2qje9cw2YAVXuzHeUlyqVe7vdPvZVo0=.1d791a9f-3de3-4b37-b236-d7e1ea81855a@github.com>
 <vXKnwFri-UtLPcwFg86Om-dLk40CK9YWkM2ht_g9-VA=.8e4c856d-57eb-4bf5-bf1c-71905d958d9e@github.com>
Message-ID: <xZjAlpBvr8wTPrPimwBPWzPDelA5s5w3jhkFL54m9P8=.7fd20387-c91e-42bf-8875-0c83679667be@github.com>

On Tue, 1 Mar 2022 04:39:29 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4375:
>> 
>>> 4373:     evpunpckldq(xtmp2, k0, xtmp3, xtmp1, true, vec_enc);
>>> 4374:     evpsadbw(xtmp2, k0, xtmp2, xtmp1, true, vec_enc);
>>> 4375:     vpackuswb(dst, xtmp2, dst, vec_enc);
>> 
>> This doesn't look correct for say 512 bit vector length. At this point, the xtmp2 has 64-bit popcount results for lower 8 integers and dst has 64-bit popcount results for upper 8 integers. The vpackuswb does interleaving between xtmp2 and dst at 128 bit lanes so the result is not in correct order.
>
> original vector of integer = [ a3  a2  a1  a0]
> unpackldq =  [0, a1, 0, a0]
> unpackhdq = [ 0, a3 , 0 , a2]
> perform sum of absolute difference and store the result into LSB 16 bits of each quad word.
> packuswb  packs at lane granularity i.e, 128 bits packed.
>       128 bit               128 bit
> [0, sa3, 0, sa2]  [ 0, sa1, 0, sa0 ]  =>   [ sa3, sa2 , sa1, sa0]

The problem is at 512 bit level.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From jbhateja at openjdk.java.net  Tue Mar  1 17:07:58 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 1 Mar 2022 17:07:58 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v10]
In-Reply-To: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
Message-ID: <kRLV83PaX5URFUGTuC0DkWA5pXa7LGg5nHb2dXL1lrQ=.3d577851-1d1c-4813-baa7-a06d3c9d5346@github.com>

> Summary of changes:
> - Intrinsify Math.round(float) and Math.round(double) APIs.
> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
> - Test creation using new IR testing framework.
> 
> Following are the performance number of a JMH micro included with the patch 
> 
> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
> 
> 
> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
> -- | -- | -- | -- | -- | -- | -- | --
> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8279508: Review comments resolved.`

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7094/files
  - new: https://git.openjdk.java.net/jdk/pull/7094/files/54d4ea36..3b90ae53

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=08-09

  Stats: 12 lines in 2 files changed: 1 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094

PR: https://git.openjdk.java.net/jdk/pull/7094

From jbhateja at openjdk.java.net  Tue Mar  1 17:08:51 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 1 Mar 2022 17:08:51 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v7]
In-Reply-To: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
Message-ID: <kATPxslgFX2I4XTxlzpbOHK_4toQrppMxrtKFaIbgJI=.c098b898-89cd-4c29-9422-177450f1c399@github.com>

> Summary of changes:
> 
> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
> 
> 
> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8281375: Review comments resolved.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7373/files
  - new: https://git.openjdk.java.net/jdk/pull/7373/files/92071f7b..1cdd068e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7373&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7373&range=05-06

  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7373.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7373/head:pull/7373

PR: https://git.openjdk.java.net/jdk/pull/7373

From kvn at openjdk.java.net  Tue Mar  1 18:32:02 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 1 Mar 2022 18:32:02 GMT
Subject: RFR: 8281122: [IR Framework] Cleanup IR matching code in
 preparation for JDK-8280378
In-Reply-To: <EipCoiSZ7caqan6lwb4T-ALGmTAd1PO8F2TnpbdBCfA=.d97f1afb-406a-405e-8f6f-5d06e9f133ea@github.com>
References: <EipCoiSZ7caqan6lwb4T-ALGmTAd1PO8F2TnpbdBCfA=.d97f1afb-406a-405e-8f6f-5d06e9f133ea@github.com>
Message-ID: <Ned-NQSLbatYj7VIGQPBMerCEVd5wE6QhHiDMMXZ44I=.0ccee123-99b7-4601-8904-973702500599@github.com>

On Fri, 18 Feb 2022 13:36:31 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch does some restructurings and refactorings of the `IRMatcher.java` class in preparation for adding IR matching support on different compile phases with [JDK-8280378](https://bugs.openjdk.java.net/browse/JDK-8280378). There are no semantic changes of how IR matching is eventually done on regexes and how the results are checked with the `failOn` and `counts` constraints provided by the user. The only user-visible change is an improved output format of matching failures.
> 
> The old format also did not report a `counts` constraint failure correctly. It wrongly used the format of `failOn` failures which was misleading. This is also fixed by this patch.
> 
> **Example:**
> 
> @Test
> @IR(counts = {IRNode.STORE_F, "!= 1"}) // fails
> @IR(counts = {IRNode.STORE_F, "2", IRNode.LOAD_F, "> 1"}) // both constraints fail
> public void test1() {
>     fFld = 4.2f;
> }
> 
> @Test
> @IR(failOn = IRNode.ALLOC, counts = {IRNode.STORE_F, ">= 2"}) // failOn and counts fail
> public void test2() {
>     fFld = 4.2f;
>     o = new Object();
> }
> 
> _Failure outputs:_
> <details>
>   <summary>Old format</summary>
> 
> 
> Failed IR Rules (3)
> ------------------
> - Method "public void ir_framework.tests.Testi.test1()":
>   * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "!= 1"}, applyIfNot={})"
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>         Expected 1 but found 1 node:
>           25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>   * @IR rule 2: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "2", "(\\d+(\\s){2}(LoadF.*)+(\\s){2}===.*)", "> 1"}, applyIfNot={})"
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>         Expected 2 but found 1 node:
>           25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>         Regex 2: (\d+(\s){2}(LoadF.*)+(\s){2}===.*)
>         Expected 1 but found 0 nodes.
> 
> - Method "public void ir_framework.tests.Testi.test2()":
>   * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={"(.*precise .*\\R((.*(?i:mov|xorl|nop|spill).*|\\s*|.*LGHI.*)\\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)"}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", ">= 2"}, applyIfNot={})"
>     - failOn: Graph contains forbidden nodes:
>         Regex 1: (.*precise .*\R((.*(?i:mov|xorl|nop|spill).*|\s*|.*LGHI.*)\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)
>         Matched forbidden node:
>           1a5     movq    RSI, precise java/lang/Object: 0x00007fb188007318:Constant:exact *	# ptr
>     1af     call,static  wrapper for: _new_instance_Java
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>         Expected 2 but found 1 node:
>           25  StoreF  ===  5  7  24  21  [[ 19  236  36  179  220 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test2 @ bci:3 (line 55)
> 
> </details>
> <details>
>   <summary>New format</summary>
> 
> 
> Failed IR Rules (3) of Methods (2)
> ----------------------------------
> 1) Method "public void ir_framework.tests.Testi.test1()" - [Failed IR rules: 2]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "!= 1"}, applyIfNot={})"
>      - counts: Graph contains wrong number of nodes:
>        * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 1 != 1 [given]
>          - Matched node:
>            * 25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>    * @IR rule 2: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "2", "(\\d+(\\s){2}(LoadF.*)+(\\s){2}===.*)", "> 1"}, applyIfNot={})"
>      - counts: Graph contains wrong number of nodes:
>        * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 1 = 2 [given]
>          - Matched node:
>            * 25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>        * Regex 2: (\d+(\s){2}(LoadF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 0 > 1 [given]
>          - No nodes matched!
> 
> 2) Method "public void ir_framework.tests.Testi.test2()" - [Failed IR rules: 1]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={"(.*precise .*\\R((.*(?i:mov|xorl|nop|spill).*|\\s*|.*LGHI.*)\\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)"}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", ">= 2"}, applyIfNot={})"
>      - failOn: Graph contains forbidden nodes:
>        * Regex 1: (.*precise .*\R((.*(?i:mov|xorl|nop|spill).*|\s*|.*LGHI.*)\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)
>          - Matched forbidden node:
>            * 1a5     movq    RSI, precise java/lang/Object: 0x00007fd3c4007318:Constant:exact *	# ptr
>              1af     call,static  wrapper for: _new_instance_Java
>      - counts: Graph contains wrong number of nodes:
>        * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 1 >= 2 [given]
>          - Matched node:
>            * 25  StoreF  ===  5  7  24  21  [[ 19  236  36  179  220 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test2 @ bci:3 (line 55)
> 
> </details>
> 
> **New class structure:**
> 
> The old `IRMatcher` class mixed different tasks such as parsing, IR annotation verification, IR matching and failure reporting together. This made it difficult to extend the existing code to add IR matching support on different compile phases. Therefore, the class was split to separate the different tasks:
> - parser classes (`IREncodingParser`, `HotSpotPidFileParser`, `IRMethodParser` etc.)
> - entity classes for the different parts of an `@IR` annotation (`IRMethod`, `IRRule`, `Counts`, `FailOn` etc.)
> - match result classes for each entity class to provide a formatted failure message (`IRMethodMatchResult`, `IRRuleMatchResult` etc.)
> 
> The main structure of the new classes will be kept in JDK-8280378 but will be further improved to match the new needs.
> 
> **Testing:**
> - Normal tier testing including tier5 and 6 where the IR framework tests are executed.
> - Testing of this patch in Valhalla with tier1-3 + some Valhalla-specific stress testing
> 
> 
> Thanks,
> Christian

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7533

From kvn at openjdk.java.net  Tue Mar  1 19:22:58 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 1 Mar 2022 19:22:58 GMT
Subject: RFR: 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java
 will fail when --with-jvm-features=-compiler1 [v3]
In-Reply-To: <phRjfJY6VUbEvFyfq5tO69cySrr1yCXwyvIgwvGT684=.676eaac4-3715-428e-8e2e-a191204d739a@github.com>
References: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
 <phRjfJY6VUbEvFyfq5tO69cySrr1yCXwyvIgwvGT684=.676eaac4-3715-428e-8e2e-a191204d739a@github.com>
Message-ID: <VvVpKxm1_qQjbO79irkPxlGGEiRmVTS2UCs_kGOYyps=.97e6f267-0116-4923-bbb2-7513100bbf13@github.com>

On Mon, 28 Feb 2022 06:45:17 GMT, Haomin <duke at openjdk.java.net> wrote:

>> ?l when --with-jvm-features=-compiler1
>
> Haomin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282142: [TestCase] compiler/inlining/ResolvedClassTest.java will fail when --with-jvm-features=-compiler1

Did you investigated why C2 compilation failed to produce expected message? And produces instead: `failed initial checks`

-------------

PR: https://git.openjdk.java.net/jdk/pull/7541

From manc at openjdk.java.net  Tue Mar  1 20:24:29 2022
From: manc at openjdk.java.net (Man Cao)
Date: Tue, 1 Mar 2022 20:24:29 GMT
Subject: RFR: 8282507: Add LICENSE file for hsdis
Message-ID: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>

Hi all,

Could anyone help review the addition of LICENSE file to hsdis directory?

-Man

-------------

Commit messages:
 - Add LICENSE file for hsdis

Changes: https://git.openjdk.java.net/jdk/pull/7649/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7649&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282507
  Stats: 35 lines in 1 file changed: 35 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7649.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7649/head:pull/7649

PR: https://git.openjdk.java.net/jdk/pull/7649

From kvn at openjdk.java.net  Tue Mar  1 21:10:07 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 1 Mar 2022 21:10:07 GMT
Subject: RFR: 8279886: C1: Turn off SelectivePhiFunctions in presence of
 irreducible loops [v2]
In-Reply-To: <Yoat8TsWJuuo2NKA-3ze-kdcBqb_9jJwDL568NYH31k=.ff83b2da-8eac-4a5f-a514-433238897826@github.com>
References: <9hUbaevqiNT2GmsBxLbGYHYFmSMeDZZDaBkUpuJFBHk=.b7da7542-844d-4d8c-8f61-ee0eca5a3500@github.com>
 <Yoat8TsWJuuo2NKA-3ze-kdcBqb_9jJwDL568NYH31k=.ff83b2da-8eac-4a5f-a514-433238897826@github.com>
Message-ID: <BwbQB-AkL57g7N6wW0v0js9rYVontEt4JKqx2t2AJ-A=.09de7457-078a-4512-aa91-f6c673329c6f@github.com>

On Tue, 1 Mar 2022 15:50:24 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> This change add irreducible loops detection to `BlockListBuilder::mark_loops()` - a loop marking routine necessary for the SSA conversion. Here is brief description of the algorithm (copy-pasted from the comments I left in the code).
>> 
>> The loop detection algorithm works as follows:
>> 
>> - We maintain the `_loop_map`, where for each block we have a bitmap indicating which loops contain this block.
>> - The CFG is recursively traversed (depth-first) and if we detect a loop, we assign the loop a unique number that is stored in the bitmap associated with the loop header block. Until we return back through that loop header the bitmap contains only a single bit corresponding to the loop number.
>> - The bit is then propagated for all the blocks in the loop after we exit them (post-order). There could be multiple bits of course in case of nested loops.
>> - When we exit the loop header we remove that single bit and assign the real loop state for it.
>> - Now, the tricky part here is how we detect irriducible loops. In the algorithm above the loop state bits are propagated to the predecessors. If we encounter an irreducible loop (a loop with multiple heads) we would see a node with some loop bit set that would then propagate back and be never cleared because we would never go back through the original loop header. Therefore if there are any irreducible loops the bits in the states for these loops are going to propagate back to the root.
>> 
>> Testing is clean: hs-tier{1-7}
>
> Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Add comments
>  - Detect irreducible loops during parsing/phi insertion.

Looks good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7636

From jrose at openjdk.java.net  Tue Mar  1 23:05:03 2022
From: jrose at openjdk.java.net (John R Rose)
Date: Tue, 1 Mar 2022 23:05:03 GMT
Subject: RFR: 8278296: Generalize long range check transformation [v5]
In-Reply-To: <tQI4zYKoYVc1Izd9libv95_22lImNIyB6hHMsR93Igk=.80fd7bed-2f90-476f-a9ec-2698cc9c2abb@github.com>
References: <Khntpfq1O8Ea-1lFIi3di44_E9YmuVsayLDVgc7xV0A=.b4996073-64c1-4cda-b778-d242c06ccc43@github.com>
 <tQI4zYKoYVc1Izd9libv95_22lImNIyB6hHMsR93Igk=.80fd7bed-2f90-476f-a9ec-2698cc9c2abb@github.com>
Message-ID: <K0RbbWgXFCxQJY06YNtOZdYNLe8JojxZMu9zHiCsxT0=.3d28bed9-58a2-4408-9b6f-a0f75f4003bd@github.com>

On Wed, 26 Jan 2022 16:04:06 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> 8259609 (C2: optimize long range checks in long counted loops) only
>> covered the case of a counted loop with a positive stride and a range
>> check with a positive scale. This change generalizes the long range
>> check transformation to all 4 combinations of stride and scale signs.
>> 
>> The stride > 0, scale > 0 case (covered 8259609) was tweaked so it now
>> uses Qmax computed as the inclusive limit of j*K+Q. That helps in
>> generalizing the formulas to other cases.
>> 
>> The addition of PhaseIdealLoop::is_scaled_iv_plus_extra_offset() was
>> required for the case of negative scale in an int loop. The range
>> check then has the shape:
>> 
>> (CmpUL (AddL (ConvI2L (SubI ConI (LshiftI (Phi
>> 
>> with ConI, the zero constant.
>> 
>> This change also addresses this comment from John:
>> 
>> https://github.com/openjdk/jdk/pull/6576#discussion_r765343664
>> 
>> as part of 8276116 (C2: optimize long range checks in int counted loops)
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Attached is another bunch of documentation changes, explaining what's going on in great detail.  I think I'm done, actually.  I did this in concert with an executable test harness, to catch logic errors.

[roland-review-0301-patch.txt](https://github.com/openjdk/jdk/files/8165295/roland-review-0301-patch.txt)

In the transform code, I changed the names of some of the variables and some of the order of operations, to correspond better to the documentation (or so I hope; please check).

I made an algorithmic change, replacing an overflowing `Q_max+1` by simply `max_jlong` rather than `R`, since `max_jlong` is a simple rematerializable constant but `R` might need spilling.  I validated this change in my test harness; any value between R and `max_jlong` inclusive will work as `H_clamp`.

Near the conditional moves I made comments suggesting alternative flow-free idioms.  But I can't think of any good reason not to use the conditional moves, even on platforms (like old PPC) which implement them as control flow.  Feel free to toss those comments, though I enjoyed coming up with them.

For the record, I did a series of experiments to validate the subtle logic of this transformation.  Here is the code:
<http://cr.openjdk.java.net/~jrose/jvm/ClampedRangeCheckSimulation.zip>

Attached is another bunch of documentation changes, explaining what's going on in great detail.  I think I'm done, actually.  I did this in concert with an executable test harness, to catch logic errors.

[roland-review-0301-patch.txt](https://github.com/openjdk/jdk/files/8165295/roland-review-0301-patch.txt)

In the transform code, I changed the names of some of the variables and some of the order of operations, to correspond better to the documentation (or so I hope; please check).

I made an algorithmic change, replacing an overflowing `Q_max+1` by simply `max_jlong` rather than `R`, since `max_jlong` is a simple rematerializable constant but `R` might need spilling.  I validated this change in my test harness; any value between R and `max_jlong` inclusive will work as `H_clamp`.

Near the conditional moves I made comments suggesting alternative flow-free idioms.  But I can't think of any good reason not to use the conditional moves, even on platforms (like old PPC) which implement them as control flow.  Feel free to toss those comments, though I enjoyed coming up with them.

For the record, I did a series of experiments to validate the subtle logic of this transformation.  Here is the code:
<http://cr.openjdk.java.net/~jrose/jvm/ClampedRangeCheckSimulation.zip>

-------------

PR: https://git.openjdk.java.net/jdk/pull/6989

From duke at openjdk.java.net  Wed Mar  2 01:55:59 2022
From: duke at openjdk.java.net (Haomin)
Date: Wed, 2 Mar 2022 01:55:59 GMT
Subject: RFR: 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java
 will fail when --with-jvm-features=-compiler1 [v3]
In-Reply-To: <VvVpKxm1_qQjbO79irkPxlGGEiRmVTS2UCs_kGOYyps=.97e6f267-0116-4923-bbb2-7513100bbf13@github.com>
References: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
 <phRjfJY6VUbEvFyfq5tO69cySrr1yCXwyvIgwvGT684=.676eaac4-3715-428e-8e2e-a191204d739a@github.com>
 <VvVpKxm1_qQjbO79irkPxlGGEiRmVTS2UCs_kGOYyps=.97e6f267-0116-4923-bbb2-7513100bbf13@github.com>
Message-ID: <ihygzKR6uuAs0wes_cK6A7KC53St5iMWLsbfNLbUZ6s=.1efe5ff8-5d57-4271-82be-43caa5ccacb4@github.com>

On Tue, 1 Mar 2022 19:20:16 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Did you investigated why C2 compilation failed to produce expected message? And produces instead: `failed initial checks`

Hi  @vnkozlov ,

`testStaticInit()` want to  get expected error `analyzer.shouldContain("TestStaticInit$A::m (1 bytes)   no static binding");`
But only C1 can print this.

grep -nr "no static binding" src/hotspot/
src/hotspot/share/c1/c1_GraphBuilder.cpp:2101:      print_inlining(target, "no static binding", /*success*/ false);
src/hotspot/share/gc/parallel/mutableNUMASpace.cpp:834:  // Make the page allocation happen here if there is no static binding.

So, I think It should be tested when c1-only. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7541

From jbhateja at openjdk.java.net  Wed Mar  2 02:44:41 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 2 Mar 2022 02:44:41 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v11]
In-Reply-To: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
Message-ID: <pISqYd60ZBAUKka4b7I1ADwLxQaDQigDYRyWvD6-buY=.6d7a7ab1-7a10-4e62-9f60-9f82dcefadd2@github.com>

> Summary of changes:
> - Intrinsify Math.round(float) and Math.round(double) APIs.
> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
> - Test creation using new IR testing framework.
> 
> Following are the performance number of a JMH micro included with the patch 
> 
> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
> 
> 
> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
> -- | -- | -- | -- | -- | -- | -- | --
> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8279508: Removing +LogCompilation flag.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7094/files
  - new: https://git.openjdk.java.net/jdk/pull/7094/files/3b90ae53..57b1b13a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094

PR: https://git.openjdk.java.net/jdk/pull/7094

From xgong at openjdk.java.net  Wed Mar  2 03:46:27 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 2 Mar 2022 03:46:27 GMT
Subject: RFR: 8282432: Optimize masked "test" Vector API with predicate feature
Message-ID: <RlORBnCyrfaaTry0T08GvIcNFPFptQcFuMLRp7_xa6M=.4872305b-525d-4bee-9ec6-354950b87605@github.com>

The vector `"test"` api is implemented with vector `"compare"`. And the masked `"test" `is implemented with `"test(op).and(m)"` which means `"compare().and(m)"` finally. Since the masked vector `"compare"` has been optimized with predicated instruction for archituctures that support the feature, the masked `"test"` can also be optimized by implementing it with the predicated compare. This could save the additional ` "and"` for architectures that support the predicate feature.

This patch optimized the masked `"test"` by implementing it with masked `"compare"`. With this patch, the following codes for the` "IS_NEGATIVE"` op for a DoubleVector with SVE:

  mov z19.d, #0
  cmpgt   p1.d, p7/z, z19.d, z17.d
  and p0.b, p7/z, p1.b, p0.b

are optimized to:

  mov z19.d, #0
  cmpgt   p0.d, p0/z, z19.d, z17.d

Also update the jtreg tests for masked` "test" ` to make sure they are hot enough to be compiled by c2.

-------------

Commit messages:
 - 8282432: Optimize masked "test" Vector API with predicate feature

Changes: https://git.openjdk.java.net/jdk/pull/7654/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7654&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282432
  Stats: 1233 lines in 70 files changed: 590 ins; 7 del; 636 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7654.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7654/head:pull/7654

PR: https://git.openjdk.java.net/jdk/pull/7654

From jbhateja at openjdk.java.net  Wed Mar  2 05:05:11 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 2 Mar 2022 05:05:11 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v6]
In-Reply-To: <xZjAlpBvr8wTPrPimwBPWzPDelA5s5w3jhkFL54m9P8=.7fd20387-c91e-42bf-8875-0c83679667be@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <Z4B8qhzPcjVwfeOVtdqg2jY0O1F7KaPjKHs0vc42dcg=.83c1e538-4a20-4762-89a2-97060e8933ab@github.com>
 <vebauRd6DIyA2qje9cw2YAVXuzHeUlyqVe7vdPvZVo0=.1d791a9f-3de3-4b37-b236-d7e1ea81855a@github.com>
 <vXKnwFri-UtLPcwFg86Om-dLk40CK9YWkM2ht_g9-VA=.8e4c856d-57eb-4bf5-bf1c-71905d958d9e@github.com>
 <xZjAlpBvr8wTPrPimwBPWzPDelA5s5w3jhkFL54m9P8=.7fd20387-c91e-42bf-8875-0c83679667be@github.com>
Message-ID: <ofoTU7thT9CEgwCeKaQpT72zPMOwXz8tes2OQoOTrfY=.b3e0977d-0ad1-4fa3-a4c6-75e34be1e44b@github.com>

On Tue, 1 Mar 2022 16:34:52 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> original vector of integer = [ a3  a2  a1  a0]
>> unpackldq =  [0, a1, 0, a0]
>> unpackhdq = [ 0, a3 , 0 , a2]
>> perform sum of absolute difference and store the result into LSB 16 bits of each quad word.
>> packuswb  packs at lane granularity i.e, 128 bits packed.
>>       128 bit               128 bit
>> [0, sa3, 0, sa2]  [ 0, sa1, 0, sa0 ]  =>   [ sa3, sa2 , sa1, sa0]
>
> The problem is at 512 bit level.

original 512 bit vector holding 16 integers = [ a15 a14 a13 a12, a11 a10 a9 a8 ,a7 a6 a5 a4 ,a3 a2 a1 a0 ]
 unpackdq lower:
                512 bit (vec1) 
   128           128        128      128
 0 a13 0 a12  0 a9 0 a8  0 a5 0 a4  0 a1 0 a0
 unpackdq higher:
                512 bit (vec1) 
   128           128        128      128
 0 a15 0 a14  0 a11 0 a10  0 a7 0 a6  0 a3 0 a2
 Next sum of absolute difference operation followed by pack will squeez each 128 bit lane of two participant vectors
 and interleave them in resulatant vector.
         VEC1_L3     VEC1_L2     VEC1_L1   VEC1_L0              VEC2_L3     VEC2_L2      VEC2_L1    VEC2_L0           
 [ 0 sa13 0 sa12  0 sa9 0 sa8  0 sa5 0 sa4  0 sa1 0 sa0 ] [ 0 sa15 0 sa14  0 sa11 0 sa10  0 sa7 0 sa6  0 sa3 0 sa2 ]
 [ sa15 sa14 sa13 sa12   sa11 sa10 sa9 sa8  sa7 sa6 sa5 sa4  sa3 sa2 sa1 sa0]

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From chagedorn at openjdk.java.net  Wed Mar  2 09:01:05 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 2 Mar 2022 09:01:05 GMT
Subject: Integrated: 8282480: IGV: Use description instead of enum name for
 phases
In-Reply-To: <FdsSpYoxV2_538mVX6Pr71Mo_bhVmcsd8Ih4JPFOYhk=.57a60e02-3985-45e2-96a7-cee375f897f2@github.com>
References: <FdsSpYoxV2_538mVX6Pr71Mo_bhVmcsd8Ih4JPFOYhk=.57a60e02-3985-45e2-96a7-cee375f897f2@github.com>
Message-ID: <bxj2fp7e0RkGcOTRY1nqZjdEM_nUKZcoDF_r_shaAJ0=.39e0cd1a-e47d-42d5-bde9-08e6e171cd48@github.com>

On Tue, 1 Mar 2022 13:03:50 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> [JDK-8281505](https://bugs.openjdk.java.net/browse/JDK-8281505) changed the `PrintIdeal` output to use the enum name of a phase when used with `PrintIdealPhase` instead of the description. However, it also changed the phase name shown in the IGV to the enum name. This should be reverted back for a better readability.
> 
> IGV after JDK-8281505:
> ![Screenshot from 2022-03-01 13-59-15](https://user-images.githubusercontent.com/17833009/156173248-7f6450cb-9816-437a-b5fa-816a2e214ad9.png)
> 
> IGV before JDK-8281505/with this patch:
> ![Screenshot from 2022-03-01 13-58-36](https://user-images.githubusercontent.com/17833009/156173243-0a0f975a-a44d-46a6-a48a-5183ff7600e1.png)
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: ed3496e6
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ed3496e6c030b6b0a3745bf8ef281075afa1cd27
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8282480: IGV: Use description instead of enum name for phases

Reviewed-by: redestad, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7645

From ihse at openjdk.java.net  Wed Mar  2 10:33:02 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 2 Mar 2022 10:33:02 GMT
Subject: RFR: 8282507: Add LICENSE file for hsdis
In-Reply-To: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
References: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
Message-ID: <bVHRX_SyJv5JLAvPtGmcIPw9dPFoR7ZA97kijKOCZ2s=.bd92c7a8-1ecd-489d-bc7d-9a317decaa40@github.com>

On Tue, 1 Mar 2022 20:18:11 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone help review the addition of LICENSE file to hsdis directory?
> 
> -Man

I'm not sure what the legal implications are of adding a separate general file like this, instead of marking each individual file. I'd need to get some confirmation that this is acceptable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7649

From roland at openjdk.java.net  Wed Mar  2 13:36:31 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 2 Mar 2022 13:36:31 GMT
Subject: RFR: 8278296: Generalize long range check transformation [v6]
In-Reply-To: <Khntpfq1O8Ea-1lFIi3di44_E9YmuVsayLDVgc7xV0A=.b4996073-64c1-4cda-b778-d242c06ccc43@github.com>
References: <Khntpfq1O8Ea-1lFIi3di44_E9YmuVsayLDVgc7xV0A=.b4996073-64c1-4cda-b778-d242c06ccc43@github.com>
Message-ID: <_NG2SisUeyWEbQzye-ZRXRiadCQL-tIjhG0v7Jz6QhY=.4c2df5ac-d323-43ed-ab3e-7e92af1f6371@github.com>

> 8259609 (C2: optimize long range checks in long counted loops) only
> covered the case of a counted loop with a positive stride and a range
> check with a positive scale. This change generalizes the long range
> check transformation to all 4 combinations of stride and scale signs.
> 
> The stride > 0, scale > 0 case (covered 8259609) was tweaked so it now
> uses Qmax computed as the inclusive limit of j*K+Q. That helps in
> generalizing the formulas to other cases.
> 
> The addition of PhaseIdealLoop::is_scaled_iv_plus_extra_offset() was
> required for the case of negative scale in an int loop. The range
> check then has the shape:
> 
> (CmpUL (AddL (ConvI2L (SubI ConI (LshiftI (Phi
> 
> with ConI, the zero constant.
> 
> This change also addresses this comment from John:
> 
> https://github.com/openjdk/jdk/pull/6576#discussion_r765343664
> 
> as part of 8276116 (C2: optimize long range checks in int counted loops)

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - typo + build fix
 - John's review
 - Merge branch 'master' into JDK-8278296
 - review
 - fixes
 - John's patch
 - Merge branch 'master' into JDK-8278296
 - more review
 - review
 - whitespaces
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/2c5d266f...6a2ae123

-------------

Changes: https://git.openjdk.java.net/jdk/pull/6989/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6989&range=05
  Stats: 723 lines in 7 files changed: 489 ins; 79 del; 155 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6989.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6989/head:pull/6989

PR: https://git.openjdk.java.net/jdk/pull/6989

From roland at openjdk.java.net  Wed Mar  2 13:40:00 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 2 Mar 2022 13:40:00 GMT
Subject: RFR: 8278296: Generalize long range check transformation [v5]
In-Reply-To: <K0RbbWgXFCxQJY06YNtOZdYNLe8JojxZMu9zHiCsxT0=.3d28bed9-58a2-4408-9b6f-a0f75f4003bd@github.com>
References: <Khntpfq1O8Ea-1lFIi3di44_E9YmuVsayLDVgc7xV0A=.b4996073-64c1-4cda-b778-d242c06ccc43@github.com>
 <tQI4zYKoYVc1Izd9libv95_22lImNIyB6hHMsR93Igk=.80fd7bed-2f90-476f-a9ec-2698cc9c2abb@github.com>
 <K0RbbWgXFCxQJY06YNtOZdYNLe8JojxZMu9zHiCsxT0=.3d28bed9-58a2-4408-9b6f-a0f75f4003bd@github.com>
Message-ID: <OBHKSnnQM62no-lFBJtWD50-jTJgqKyK_JE0SDHgb4A=.ee5dac75-e66e-4f62-b0b3-3d644fc4c910@github.com>

On Tue, 1 Mar 2022 23:02:10 GMT, John R Rose <jrose at openjdk.org> wrote:

> Attached is another bunch of documentation changes, explaining what's going on in great detail. I think I'm done, actually. I did this in concert with an executable test harness, to catch logic errors.

Thanks for the careful review. I pushed your patch + another commit with a typo and build fixes.
Would you mind marking yourself as a reviewer (using the github UI) if you're done?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6989

From adinn at openjdk.java.net  Wed Mar  2 13:49:00 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Wed, 2 Mar 2022 13:49:00 GMT
Subject: RFR: 8282182: Document algorithm used to encode aarch64 logical
 immediate operands. [v3]
In-Reply-To: <_mcHOjaHB3O6M6B9vFnu6d-SWwTNu14mX2-iVAHYKz4=.2e9b79d3-fe2f-45b0-9942-48eccb1cfa11@github.com>
References: <dd7y8tkaDFRy7OQGykzQ_to0zAgexVv7_KvaVIlqF2U=.22a2870d-928a-47c1-93fe-0ede3f22293e@github.com>
 <_mcHOjaHB3O6M6B9vFnu6d-SWwTNu14mX2-iVAHYKz4=.2e9b79d3-fe2f-45b0-9942-48eccb1cfa11@github.com>
Message-ID: <UowwU_s83gYyAX4WYtlkTQ8XkDDKy_qg8EHTwTfLqCo=.dd6553c3-4189-43eb-a540-8ff64c965a38@github.com>

On Mon, 21 Feb 2022 13:15:34 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> This *documentation only* change explains how logical immediate mask values are derived from valid logical instruction operands. The encoding function is used to populate a sparse array that maps valid masks to a unique set of input operand values and a reverse lookup array that maps inputs to the associated mask.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include unsaved changes

@shipilev Any further comments on the revised version?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7536

From manc at openjdk.java.net  Wed Mar  2 19:09:03 2022
From: manc at openjdk.java.net (Man Cao)
Date: Wed, 2 Mar 2022 19:09:03 GMT
Subject: RFR: 8282507: Add LICENSE file for hsdis
In-Reply-To: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
References: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
Message-ID: <6p9JZ8dwlJ5-HZkkP4yxHfv17G8v25jmSLTiw9GgUu8=.384fb06e-3fb6-477a-a82a-5e31b0022241@github.com>

On Tue, 1 Mar 2022 20:18:11 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone help review the addition of LICENSE file to hsdis directory?
> 
> -Man

Thank you for reaching out for confirmation. This doc might help: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository . A separate LICENSE file is also more consistent with other code in OpenJDK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7649

From psandoz at openjdk.java.net  Wed Mar  2 19:17:04 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 2 Mar 2022 19:17:04 GMT
Subject: RFR: 8282432: Optimize masked "test" Vector API with predicate
 feature
In-Reply-To: <RlORBnCyrfaaTry0T08GvIcNFPFptQcFuMLRp7_xa6M=.4872305b-525d-4bee-9ec6-354950b87605@github.com>
References: <RlORBnCyrfaaTry0T08GvIcNFPFptQcFuMLRp7_xa6M=.4872305b-525d-4bee-9ec6-354950b87605@github.com>
Message-ID: <3Eb4XMw6WAiao9pQW6BfchjrwQ4qju9nL8hG0HL9psk=.aa63fea9-c727-4a34-9b87-e78fea9d027a@github.com>

On Wed, 2 Mar 2022 02:50:27 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The vector `"test"` api is implemented with vector `"compare"`. And the masked `"test" `is implemented with `"test(op).and(m)"` which means `"compare().and(m)"` finally. Since the masked vector `"compare"` has been optimized with predicated instruction for archituctures that support the feature, the masked `"test"` can also be optimized by implementing it with the predicated compare. This could save the additional ` "and"` for architectures that support the predicate feature.
> 
> This patch optimized the masked `"test"` by implementing it with masked `"compare"`. With this patch, the following codes for the` "IS_NEGATIVE"` op for a DoubleVector with SVE:
> 
>   mov z19.d, #0
>   cmpgt   p1.d, p7/z, z19.d, z17.d
>   and p0.b, p7/z, p1.b, p0.b
> 
> are optimized to:
> 
>   mov z19.d, #0
>   cmpgt   p0.d, p0/z, z19.d, z17.d
> 
> Also update the jtreg tests for masked` "test" ` to make sure they are hot enough to be compiled by c2.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java line 1737:

> 1735:     <M1 extends VectorMask<Double>,
> 1736:      M2 extends VectorMask<Long>>
> 1737:     M1 testTemplate(Class<M1> maskType, Test op, M2 mask) {

Can we simplify by making some code FP specific?
- the mask `cast` can be applied in this method rather than in the caller, simplifying the signature
- for clarify, vector `viewAsIntegralLanes` is only needed for FP (update would be required for the non-mask template).

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java line 1766:

> 1764:                 throw new AssertionError(op);
> 1765:             }
> 1766:             return maskType.cast(m.cast(this.vspecies()));

Suggestion:

            return maskType.cast(m.cast(vsp));

Same for non-mask template too.

test/jdk/jdk/incubator/vector/templates/Unit-Test.template line 29:

> 27:         VectorMask<$Wideboxtype$> vmask = VectorMask.fromArray(SPECIES, mask, 0);
> 28: 
> 29:         for (int ic = 0; ic < INVOC_COUNT; ic++) {

Can you remove `SmokeTest` from the method name.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7654

From jiefu at openjdk.java.net  Wed Mar  2 23:16:07 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 2 Mar 2022 23:16:07 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v7]
In-Reply-To: <tNKnyG13TLhpmdmqj5rCrZ3nwiizmvuxghP-_byMdPg=.713531f5-531e-41b0-8abb-411cec6444d0@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <tNKnyG13TLhpmdmqj5rCrZ3nwiizmvuxghP-_byMdPg=.713531f5-531e-41b0-8abb-411cec6444d0@github.com>
Message-ID: <LO-w_tH7qm5KvT2ScHkYXD1JaAPtoFzbTrqQo11y9Gw=.565cf46b-0673-4451-849d-2ba751f3a348@github.com>

On Tue, 1 Mar 2022 02:28:00 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove irrelevent changes

test/micro/org/openjdk/bench/vm/compiler/LeaInstruction.java line 32:

> 30: @BenchmarkMode(Mode.AverageTime)
> 31: @OutputTimeUnit(TimeUnit.NANOSECONDS)
> 32: @Fork(value = 2, jvmArgsAppend = {"-XX:LoopUnrollLimit=1"})

How about `value = 1`?
I think it would reduce the micro-bench testing time, right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From sviswanathan at openjdk.java.net  Wed Mar  2 23:27:08 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 2 Mar 2022 23:27:08 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v9]
In-Reply-To: <mPYDVHjrBrCoZU853aifNgYbVOokUK__UWdd4QPtVQ8=.45572f64-bf9d-42f6-b033-b39f3bf5b7be@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>
 <Uh_FQzMDzw-9p5ojLandAlJRSJAcfHzcPKMhSQIKYL8=.afb061c1-0cfc-43a6-80a9-4d3f7c03ba3d@github.com>
 <1K0c0y8K8bVNJEFMyTQSxwdgJlx9E2N8uhHC7O9sfyM=.c4ead8b5-abe0-42f4-ae10-aa24425eb75d@github.com>
 <8mhsd-DL1IccFiqrRigKdck8OJg79sjKgaYXrHc4zwY=.c92cb7f5-8e54-42ab-84f1-9cfa1ce76779@github.com>
 <mPYDVHjrBrCoZU853aifNgYbVOokUK__UWdd4QPtVQ8=.45572f64-bf9d-42f6-b033-b39f3bf5b7be@github.com>
Message-ID: <l4V9Q0H9381bFwfhpp9hfIKtZJDDeoVujG5EGjkLNcA=.b864e331-b1f6-4816-8add-a33b1a51cfb7@github.com>

On Sat, 26 Feb 2022 03:38:32 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> I believe the indefinite value should be 2^(w - 1) (a.k.a 0x80000000) and the documentation is typoed. If you look at `cvtss2si`, the indefinite value is also written as 2^w - 1 but yet in `MacroAssembler::convert_f2i` we compare it with 0x80000000. In addition, choosing -1 as an indefinite value is weird enough and to complicate it as 2^w - 1 is really unusual.
>
> `MacroAssembler::convert_f2i`
> 
> https://github.com/openjdk/jdk/blob/c5c6058fd57d4b594012035eaf18a57257f4ad85/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8919

@jatin-bhateja  @merykitty You are right, on overflow we observe 2^(w - 1) i.e. 0x8000 0000 so using vector_float_signflip() is correct.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From sviswanathan at openjdk.java.net  Wed Mar  2 23:32:05 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 2 Mar 2022 23:32:05 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v11]
In-Reply-To: <pISqYd60ZBAUKka4b7I1ADwLxQaDQigDYRyWvD6-buY=.6d7a7ab1-7a10-4e62-9f60-9f82dcefadd2@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <pISqYd60ZBAUKka4b7I1ADwLxQaDQigDYRyWvD6-buY=.6d7a7ab1-7a10-4e62-9f60-9f82dcefadd2@github.com>
Message-ID: <vKosTPkS7nix0s9MhOUEnzelyT8Sy5lcXjA7Ak_RLPU=.246d2fde-e8cb-451d-a52f-f8e236b5be43@github.com>

On Wed, 2 Mar 2022 02:44:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
>> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279508: Removing +LogCompilation flag.

Marked as reviewed by sviswanathan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From sviswanathan at openjdk.java.net  Wed Mar  2 23:32:06 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 2 Mar 2022 23:32:06 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v9]
In-Reply-To: <gM42lIzUQBnOjZLyuBAh4-VqZZs0864NoDP5mOCUVDk=.12c99ec0-98ef-4e67-8fe7-279f82bdf9c9@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>
 <gM42lIzUQBnOjZLyuBAh4-VqZZs0864NoDP5mOCUVDk=.12c99ec0-98ef-4e67-8fe7-279f82bdf9c9@github.com>
Message-ID: <ZIKvDUUt0PfYfJzIKiMAtFOMIbOKm0_sJhzRM4WHiXk=.8be38e7c-a7de-4279-afaa-d2e1d9969455@github.com>

On Sat, 26 Feb 2022 04:55:08 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8279508: Adding descriptive comments.
>
> As per SDM, if post conversion a floating point number is non-representable in destination format e.g. a floating point value 3.4028235E10 post integer conversion will overflow the value range of integer primitive type, hence a -0.0 value or 0x80000000 is returned here. Similarly for +/- NaN and  +/-Inf post conversion value returns is -0.0.  All these cases i.e. post conversion non-representable floating point values and NaN/Inf values are handled in a special manner where algorithm first performs an unordered comparison b/w original source value and returns a 0 in case of  NaN, this weeds out the NaN case and for rest of the special values we check the MSB bit of the source and either return an Integer.MAX_VALUE for +ve numbers or a Integer.MIN_VALUE to adhere to the semantics of Math.round API.
> 
> Existing tests were enhanced to cover various special cases (NaN/Inf/+ve/-ve value/values which may be inexact after adding 0.5/ values which post conversion overflow integer value range).

@jatin-bhateja The patch looks good to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From sviswanathan at openjdk.java.net  Wed Mar  2 23:32:07 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 2 Mar 2022 23:32:07 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v9]
In-Reply-To: <Uh_FQzMDzw-9p5ojLandAlJRSJAcfHzcPKMhSQIKYL8=.afb061c1-0cfc-43a6-80a9-4d3f7c03ba3d@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>
 <Uh_FQzMDzw-9p5ojLandAlJRSJAcfHzcPKMhSQIKYL8=.afb061c1-0cfc-43a6-80a9-4d3f7c03ba3d@github.com>
Message-ID: <l5uOHpvq9nPIteYle2hsYhiq2v6JGtlqysYVp70MSZE=.aeea01bf-1a05-4e03-a825-0f11384848fb@github.com>

On Sat, 26 Feb 2022 01:07:47 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8279508: Adding descriptive comments.
>
> src/hotspot/cpu/x86/x86.ad line 7295:
> 
>> 7293:     __ vector_round_double_evex($dst$$XMMRegister, $src$$XMMRegister, $xtmp1$$XMMRegister,
>> 7294:                                 $xtmp2$$XMMRegister, $ktmp1$$KRegister, $ktmp2$$KRegister,
>> 7295:                                 ExternalAddress(vector_double_signflip()), new_mxcsr, $scratch$$Register, vlen_enc);
> 
> The vector_double_signflip() here should be replaced by vector_all_bits_set().
> vcvtpd2qq description:
> If a converted result cannot be represented in the destination
> format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value
> (2w-1, where w represents the number of bits in the destination format) is returned.

The overflow value observed is 2^(w-1) so using vector_double_signflip() is correct, please ignore this comment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From jrose at openjdk.java.net  Wed Mar  2 23:34:05 2022
From: jrose at openjdk.java.net (John R Rose)
Date: Wed, 2 Mar 2022 23:34:05 GMT
Subject: RFR: 8278296: Generalize long range check transformation [v6]
In-Reply-To: <_NG2SisUeyWEbQzye-ZRXRiadCQL-tIjhG0v7Jz6QhY=.4c2df5ac-d323-43ed-ab3e-7e92af1f6371@github.com>
References: <Khntpfq1O8Ea-1lFIi3di44_E9YmuVsayLDVgc7xV0A=.b4996073-64c1-4cda-b778-d242c06ccc43@github.com>
 <_NG2SisUeyWEbQzye-ZRXRiadCQL-tIjhG0v7Jz6QhY=.4c2df5ac-d323-43ed-ab3e-7e92af1f6371@github.com>
Message-ID: <xJiyTbUN9OqR5Kv7gZbxXlqwbN6d2phaxKJ5Ne8zMMk=.cbbb5342-7304-414f-9f9a-890d84338b65@github.com>

On Wed, 2 Mar 2022 13:36:31 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> 8259609 (C2: optimize long range checks in long counted loops) only
>> covered the case of a counted loop with a positive stride and a range
>> check with a positive scale. This change generalizes the long range
>> check transformation to all 4 combinations of stride and scale signs.
>> 
>> The stride > 0, scale > 0 case (covered 8259609) was tweaked so it now
>> uses Qmax computed as the inclusive limit of j*K+Q. That helps in
>> generalizing the formulas to other cases.
>> 
>> The addition of PhaseIdealLoop::is_scaled_iv_plus_extra_offset() was
>> required for the case of negative scale in an int loop. The range
>> check then has the shape:
>> 
>> (CmpUL (AddL (ConvI2L (SubI ConI (LshiftI (Phi
>> 
>> with ConI, the zero constant.
>> 
>> This change also addresses this comment from John:
>> 
>> https://github.com/openjdk/jdk/pull/6576#discussion_r765343664
>> 
>> as part of 8276116 (C2: optimize long range checks in int counted loops)
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - typo + build fix
>  - John's review
>  - Merge branch 'master' into JDK-8278296
>  - review
>  - fixes
>  - John's patch
>  - Merge branch 'master' into JDK-8278296
>  - more review
>  - review
>  - whitespaces
>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/2c5d266f...6a2ae123

Marked as reviewed by jrose (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6989

From duke at openjdk.java.net  Thu Mar  3 00:16:33 2022
From: duke at openjdk.java.net (Ahmed Muhsin)
Date: Thu, 3 Mar 2022 00:16:33 GMT
Subject: RFR: 8272735: Add missing SubL node transformations
Message-ID: <eFzwVPibLwh_XoXsOlIJQ3qjARbwXJaIVQUOcVGrznA=.7cc15e6e-3c6a-4dba-9e90-6e216874e600@github.com>

This change adds/enables missing subnode transformations for operations of type `long`.
A few comments in the test file `SubINodeIdealizationTests.java` were modified to add clarity and to fix a typo.
Hotspot:tier1 tests were run, this change does not introduce any new failures.

-------------

Commit messages:
 - modify test method comments to add clarity and validity
 - reorder test methods to match the test's counterpart, SubINodeIdealizationTests.java
 - add missing SubLNode transformations
 - add tests for missing SubLNode transformations

Changes: https://git.openjdk.java.net/jdk/pull/7669/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7669&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272735
  Stats: 64 lines in 3 files changed: 29 ins; 0 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7669.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7669/head:pull/7669

PR: https://git.openjdk.java.net/jdk/pull/7669

From duke at openjdk.java.net  Thu Mar  3 00:30:54 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 3 Mar 2022 00:30:54 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v8]
In-Reply-To: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
Message-ID: <L_BRRjCU4wv4e1jEKhm-M9SN2qzxls-tRbgdaF-Xd60=.b6e31bd2-6bb8-48d0-96b8-06bf6bbd6121@github.com>

> Hi,
> 
> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  address reviews

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7560/files
  - new: https://git.openjdk.java.net/jdk/pull/7560/files/31f23261..7d9b1e25

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=06-07

  Stats: 43 lines in 2 files changed: 0 ins; 30 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7560/head:pull/7560

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Thu Mar  3 00:30:55 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 3 Mar 2022 00:30:55 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v7]
In-Reply-To: <Xhms0oY8qb3-q5ZoUtvk_sGqDR1OarFB48x8F1buG_I=.eb3debf6-1297-4450-8199-83b40bb97beb@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <tNKnyG13TLhpmdmqj5rCrZ3nwiizmvuxghP-_byMdPg=.713531f5-531e-41b0-8abb-411cec6444d0@github.com>
 <Xhms0oY8qb3-q5ZoUtvk_sGqDR1OarFB48x8F1buG_I=.eb3debf6-1297-4450-8199-83b40bb97beb@github.com>
Message-ID: <5_xce5NTgFQepYuEMRANE1c0CuWKJZl6Ix8VI4Quao4=.ebe55bcc-f190-4a67-a3cb-9b97edc08cfb@github.com>

On Wed, 2 Mar 2022 14:30:21 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove irrelevent changes
>
> src/hotspot/cpu/x86/x86_64.ad line 3523:
> 
>> 3521:   match(RegI);
>> 3522:   match(rRegI);
>> 3523:   match(rax_RegI);
> 
> Why explicitly match rax, rbx, ..., rdi here?

Tbh I'm not sure but the other operands seem to do the same thing

> src/hotspot/cpu/x86/x86_64.ad line 7511:
> 
>> 7509: %}
>> 7510: 
>> 7511: instruct leaI_rReg_rReg_immI(rRegI dst, rRegI src1, rRegI src2, immI disp)
> 
> Please rename src1/src2 with base/index.

Done

> src/hotspot/cpu/x86/x86_64.ad line 7724:
> 
>> 7722: %}
>> 7723: 
>> 7724: instruct leaL_rReg_rReg_immI2_no_disp(rRegL dst, no_rbp_r13_RegL base, rRegL index, immI2 scale)
> 
> Does it make too much sense to keep both `leaL_rReg_rReg_immI2_no_disp ` and `leaL_rReg_rReg_immI2 ` for real programs?
> 
> The more instruct rules in the AD file, the bigger of the libjvm.so would be.
> I would suggest removing `leaL_rReg_rReg_immI2 `.

I agree

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From jbhateja at openjdk.java.net  Thu Mar  3 05:46:09 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 3 Mar 2022 05:46:09 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v2]
In-Reply-To: <AUfAFRB2Ki1dBUDYXNBQlF4FW0-HFotjDoKW3c6YzmQ=.59c5ce0b-482e-409b-944c-44afa409ea23@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <LQMZEAy-QU55kNt5fwFQSI8JPGuYz-nRWhuWVkKMt5c=.e5245c2f-c111-4c3d-829c-db44bca43e47@github.com>
 <AUfAFRB2Ki1dBUDYXNBQlF4FW0-HFotjDoKW3c6YzmQ=.59c5ce0b-482e-409b-944c-44afa409ea23@github.com>
Message-ID: <3JoM4khNMz85gwfyxZeBNxJCZ_B7826cc-iO4pHtTJM=.5b21a96e-b2f5-4093-a763-eec2b6d77a2e@github.com>

On Wed, 19 Jan 2022 22:09:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8279508: Adding a test for scalar intrinsification.
>
> The testing for this PR doesn't look adequate to me. I don't see any testing for the values where the behavior of round has been redefined at points in the last decade. See JDK-8010430 and JDK-6430675, both of which have regression tests in the core libs area. Thanks.

Hi @jddarcy , can you kindly validate your feedback, it has been incorporated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From jbhateja at openjdk.java.net  Thu Mar  3 05:46:07 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 3 Mar 2022 05:46:07 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v7]
In-Reply-To: <kATPxslgFX2I4XTxlzpbOHK_4toQrppMxrtKFaIbgJI=.c098b898-89cd-4c29-9422-177450f1c399@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <kATPxslgFX2I4XTxlzpbOHK_4toQrppMxrtKFaIbgJI=.c098b898-89cd-4c29-9422-177450f1c399@github.com>
Message-ID: <LG_V6wVTd4UF_U2p8sa6ipe8v6UwiFi07GbG7dIi6jI=.a50902fc-0eea-4136-a77b-c717e6a3b329@github.com>

On Tue, 1 Mar 2022 17:08:51 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> 
>> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
>> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
>> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
>> 
>> 
>> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
>> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
>> 
>> Please review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8281375: Review comments resolved.

Hi @sviswa7 , your comments have been addressed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From njian at openjdk.java.net  Thu Mar  3 06:53:02 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Thu, 3 Mar 2022 06:53:02 GMT
Subject: RFR: 8280511: AArch64: Combine shift and negate to a single
 instruction
In-Reply-To: <Aq55iB5EtUCgHU2-75Y-h-LBOqQBNxtr5QWRcTNHb4A=.b51d839c-3783-48ec-b084-f4604ca5b617@github.com>
References: <Aq55iB5EtUCgHU2-75Y-h-LBOqQBNxtr5QWRcTNHb4A=.b51d839c-3783-48ec-b084-f4604ca5b617@github.com>
Message-ID: <wC08PiqaBFgRjwjRxxq_W7h7miRU-ZlgSGTyECj5AG0=.d987fa80-b6f9-4441-9137-be7af81edacb@github.com>

On Tue, 15 Feb 2022 06:48:10 GMT, Fei Gao <fgao at openjdk.org> wrote:

> Hi,
> 
> In AArch64,
> 
> asr     x10, x1, #31
> neg     x0, x10
> 
> can be optimized to:
> `neg    x0, x1, asr #31`
> 
> To implement the instruction combining, we add matching rules in the backend.
> 
> Thanks.

Looks good to me.

-------------

Marked as reviewed by njian (Committer).

PR: https://git.openjdk.java.net/jdk/pull/7471

From chagedorn at openjdk.java.net  Thu Mar  3 07:22:07 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 3 Mar 2022 07:22:07 GMT
Subject: RFR: 8281122: [IR Framework] Cleanup IR matching code in
 preparation for JDK-8280378
In-Reply-To: <EipCoiSZ7caqan6lwb4T-ALGmTAd1PO8F2TnpbdBCfA=.d97f1afb-406a-405e-8f6f-5d06e9f133ea@github.com>
References: <EipCoiSZ7caqan6lwb4T-ALGmTAd1PO8F2TnpbdBCfA=.d97f1afb-406a-405e-8f6f-5d06e9f133ea@github.com>
Message-ID: <rQq7m3O3YGEnvLAg7tkGq1HgQBtDHTbDLDj5tE5pLjU=.0aac42ae-7c2f-41d2-9900-090ad147665e@github.com>

On Fri, 18 Feb 2022 13:36:31 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch does some restructurings and refactorings of the `IRMatcher.java` class in preparation for adding IR matching support on different compile phases with [JDK-8280378](https://bugs.openjdk.java.net/browse/JDK-8280378). There are no semantic changes of how IR matching is eventually done on regexes and how the results are checked with the `failOn` and `counts` constraints provided by the user. The only user-visible change is an improved output format of matching failures.
> 
> The old format also did not report a `counts` constraint failure correctly. It wrongly used the format of `failOn` failures which was misleading. This is also fixed by this patch.
> 
> **Example:**
> 
> @Test
> @IR(counts = {IRNode.STORE_F, "!= 1"}) // fails
> @IR(counts = {IRNode.STORE_F, "2", IRNode.LOAD_F, "> 1"}) // both constraints fail
> public void test1() {
>     fFld = 4.2f;
> }
> 
> @Test
> @IR(failOn = IRNode.ALLOC, counts = {IRNode.STORE_F, ">= 2"}) // failOn and counts fail
> public void test2() {
>     fFld = 4.2f;
>     o = new Object();
> }
> 
> _Failure outputs:_
> <details>
>   <summary>Old format</summary>
> 
> 
> Failed IR Rules (3)
> ------------------
> - Method "public void ir_framework.tests.Testi.test1()":
>   * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "!= 1"}, applyIfNot={})"
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>         Expected 1 but found 1 node:
>           25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>   * @IR rule 2: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "2", "(\\d+(\\s){2}(LoadF.*)+(\\s){2}===.*)", "> 1"}, applyIfNot={})"
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>         Expected 2 but found 1 node:
>           25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>         Regex 2: (\d+(\s){2}(LoadF.*)+(\s){2}===.*)
>         Expected 1 but found 0 nodes.
> 
> - Method "public void ir_framework.tests.Testi.test2()":
>   * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={"(.*precise .*\\R((.*(?i:mov|xorl|nop|spill).*|\\s*|.*LGHI.*)\\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)"}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", ">= 2"}, applyIfNot={})"
>     - failOn: Graph contains forbidden nodes:
>         Regex 1: (.*precise .*\R((.*(?i:mov|xorl|nop|spill).*|\s*|.*LGHI.*)\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)
>         Matched forbidden node:
>           1a5     movq    RSI, precise java/lang/Object: 0x00007fb188007318:Constant:exact *	# ptr
>     1af     call,static  wrapper for: _new_instance_Java
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>         Expected 2 but found 1 node:
>           25  StoreF  ===  5  7  24  21  [[ 19  236  36  179  220 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test2 @ bci:3 (line 55)
> 
> </details>
> <details>
>   <summary>New format</summary>
> 
> 
> Failed IR Rules (3) of Methods (2)
> ----------------------------------
> 1) Method "public void ir_framework.tests.Testi.test1()" - [Failed IR rules: 2]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "!= 1"}, applyIfNot={})"
>      - counts: Graph contains wrong number of nodes:
>        * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 1 != 1 [given]
>          - Matched node:
>            * 25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>    * @IR rule 2: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "2", "(\\d+(\\s){2}(LoadF.*)+(\\s){2}===.*)", "> 1"}, applyIfNot={})"
>      - counts: Graph contains wrong number of nodes:
>        * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 1 = 2 [given]
>          - Matched node:
>            * 25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>        * Regex 2: (\d+(\s){2}(LoadF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 0 > 1 [given]
>          - No nodes matched!
> 
> 2) Method "public void ir_framework.tests.Testi.test2()" - [Failed IR rules: 1]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={"(.*precise .*\\R((.*(?i:mov|xorl|nop|spill).*|\\s*|.*LGHI.*)\\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)"}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", ">= 2"}, applyIfNot={})"
>      - failOn: Graph contains forbidden nodes:
>        * Regex 1: (.*precise .*\R((.*(?i:mov|xorl|nop|spill).*|\s*|.*LGHI.*)\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)
>          - Matched forbidden node:
>            * 1a5     movq    RSI, precise java/lang/Object: 0x00007fd3c4007318:Constant:exact *	# ptr
>              1af     call,static  wrapper for: _new_instance_Java
>      - counts: Graph contains wrong number of nodes:
>        * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 1 >= 2 [given]
>          - Matched node:
>            * 25  StoreF  ===  5  7  24  21  [[ 19  236  36  179  220 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test2 @ bci:3 (line 55)
> 
> </details>
> 
> **New class structure:**
> 
> The old `IRMatcher` class mixed different tasks such as parsing, IR annotation verification, IR matching and failure reporting together. This made it difficult to extend the existing code to add IR matching support on different compile phases. Therefore, the class was split to separate the different tasks:
> - parser classes (`IREncodingParser`, `HotSpotPidFileParser`, `IRMethodParser` etc.)
> - entity classes for the different parts of an `@IR` annotation (`IRMethod`, `IRRule`, `Counts`, `FailOn` etc.)
> - match result classes for each entity class to provide a formatted failure message (`IRMethodMatchResult`, `IRRuleMatchResult` etc.)
> 
> The main structure of the new classes will be kept in JDK-8280378 but will be further improved to match the new needs.
> 
> **Testing:**
> - Normal tier testing including tier5 and 6 where the IR framework tests are executed.
> - Testing of this patch in Valhalla with tier1-3 + some Valhalla-specific stress testing
> 
> 
> Thanks,
> Christian

Thanks Vladimir for your review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7533

From chagedorn at openjdk.java.net  Thu Mar  3 07:22:07 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 3 Mar 2022 07:22:07 GMT
Subject: Integrated: 8281122: [IR Framework] Cleanup IR matching code in
 preparation for JDK-8280378
In-Reply-To: <EipCoiSZ7caqan6lwb4T-ALGmTAd1PO8F2TnpbdBCfA=.d97f1afb-406a-405e-8f6f-5d06e9f133ea@github.com>
References: <EipCoiSZ7caqan6lwb4T-ALGmTAd1PO8F2TnpbdBCfA=.d97f1afb-406a-405e-8f6f-5d06e9f133ea@github.com>
Message-ID: <0D573Z1Pc-VQ0oeFF5K4PGdrFQA1WhAqPvXPxeM7kpU=.01e2f5ac-90b5-4e43-93d0-625b6490f847@github.com>

On Fri, 18 Feb 2022 13:36:31 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This patch does some restructurings and refactorings of the `IRMatcher.java` class in preparation for adding IR matching support on different compile phases with [JDK-8280378](https://bugs.openjdk.java.net/browse/JDK-8280378). There are no semantic changes of how IR matching is eventually done on regexes and how the results are checked with the `failOn` and `counts` constraints provided by the user. The only user-visible change is an improved output format of matching failures.
> 
> The old format also did not report a `counts` constraint failure correctly. It wrongly used the format of `failOn` failures which was misleading. This is also fixed by this patch.
> 
> **Example:**
> 
> @Test
> @IR(counts = {IRNode.STORE_F, "!= 1"}) // fails
> @IR(counts = {IRNode.STORE_F, "2", IRNode.LOAD_F, "> 1"}) // both constraints fail
> public void test1() {
>     fFld = 4.2f;
> }
> 
> @Test
> @IR(failOn = IRNode.ALLOC, counts = {IRNode.STORE_F, ">= 2"}) // failOn and counts fail
> public void test2() {
>     fFld = 4.2f;
>     o = new Object();
> }
> 
> _Failure outputs:_
> <details>
>   <summary>Old format</summary>
> 
> 
> Failed IR Rules (3)
> ------------------
> - Method "public void ir_framework.tests.Testi.test1()":
>   * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "!= 1"}, applyIfNot={})"
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>         Expected 1 but found 1 node:
>           25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>   * @IR rule 2: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "2", "(\\d+(\\s){2}(LoadF.*)+(\\s){2}===.*)", "> 1"}, applyIfNot={})"
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>         Expected 2 but found 1 node:
>           25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>         Regex 2: (\d+(\s){2}(LoadF.*)+(\s){2}===.*)
>         Expected 1 but found 0 nodes.
> 
> - Method "public void ir_framework.tests.Testi.test2()":
>   * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={"(.*precise .*\\R((.*(?i:mov|xorl|nop|spill).*|\\s*|.*LGHI.*)\\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)"}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", ">= 2"}, applyIfNot={})"
>     - failOn: Graph contains forbidden nodes:
>         Regex 1: (.*precise .*\R((.*(?i:mov|xorl|nop|spill).*|\s*|.*LGHI.*)\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)
>         Matched forbidden node:
>           1a5     movq    RSI, precise java/lang/Object: 0x00007fb188007318:Constant:exact *	# ptr
>     1af     call,static  wrapper for: _new_instance_Java
>     - counts: Graph contains wrong number of nodes:
>         Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>         Expected 2 but found 1 node:
>           25  StoreF  ===  5  7  24  21  [[ 19  236  36  179  220 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test2 @ bci:3 (line 55)
> 
> </details>
> <details>
>   <summary>New format</summary>
> 
> 
> Failed IR Rules (3) of Methods (2)
> ----------------------------------
> 1) Method "public void ir_framework.tests.Testi.test1()" - [Failed IR rules: 2]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "!= 1"}, applyIfNot={})"
>      - counts: Graph contains wrong number of nodes:
>        * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 1 != 1 [given]
>          - Matched node:
>            * 25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>    * @IR rule 2: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", "2", "(\\d+(\\s){2}(LoadF.*)+(\\s){2}===.*)", "> 1"}, applyIfNot={})"
>      - counts: Graph contains wrong number of nodes:
>        * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 1 = 2 [given]
>          - Matched node:
>            * 25  StoreF  ===  5  7  24  21  [[ 16 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test1 @ bci:3 (line 48)
>        * Regex 2: (\d+(\s){2}(LoadF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 0 > 1 [given]
>          - No nodes matched!
> 
> 2) Method "public void ir_framework.tests.Testi.test2()" - [Failed IR rules: 1]:
>    * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={"(.*precise .*\\R((.*(?i:mov|xorl|nop|spill).*|\\s*|.*LGHI.*)\\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)"}, applyIfOr={}, counts={"(\\d+(\\s){2}(StoreF.*)+(\\s){2}===.*)", ">= 2"}, applyIfNot={})"
>      - failOn: Graph contains forbidden nodes:
>        * Regex 1: (.*precise .*\R((.*(?i:mov|xorl|nop|spill).*|\s*|.*LGHI.*)\R)*.*(?i:call,static).*wrapper for: _new_instance_Java)
>          - Matched forbidden node:
>            * 1a5     movq    RSI, precise java/lang/Object: 0x00007fd3c4007318:Constant:exact *	# ptr
>              1af     call,static  wrapper for: _new_instance_Java
>      - counts: Graph contains wrong number of nodes:
>        * Regex 1: (\d+(\s){2}(StoreF.*)+(\s){2}===.*)
>          - Failed comparison: [found] 1 >= 2 [given]
>          - Matched node:
>            * 25  StoreF  ===  5  7  24  21  [[ 19  236  36  179  220 ]]  @ir_framework/tests/Testi+12 *, name=fFld, idx=4;  Memory: @ir_framework/tests/Testi:NotNull+12 *, name=fFld, idx=4; !jvms: Testi::test2 @ bci:3 (line 55)
> 
> </details>
> 
> **New class structure:**
> 
> The old `IRMatcher` class mixed different tasks such as parsing, IR annotation verification, IR matching and failure reporting together. This made it difficult to extend the existing code to add IR matching support on different compile phases. Therefore, the class was split to separate the different tasks:
> - parser classes (`IREncodingParser`, `HotSpotPidFileParser`, `IRMethodParser` etc.)
> - entity classes for the different parts of an `@IR` annotation (`IRMethod`, `IRRule`, `Counts`, `FailOn` etc.)
> - match result classes for each entity class to provide a formatted failure message (`IRMethodMatchResult`, `IRRuleMatchResult` etc.)
> 
> The main structure of the new classes will be kept in JDK-8280378 but will be further improved to match the new needs.
> 
> **Testing:**
> - Normal tier testing including tier5 and 6 where the IR framework tests are executed.
> - Testing of this patch in Valhalla with tier1-3 + some Valhalla-specific stress testing
> 
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 2da67779
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2da677793f562236d473afe12b5c941f25f41377
Stats:     3592 lines in 57 files changed: 2756 ins; 769 del; 67 mod

8281122: [IR Framework] Cleanup IR matching code in preparation for JDK-8280378

Reviewed-by: thartmann, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7533

From duke at openjdk.java.net  Thu Mar  3 07:56:08 2022
From: duke at openjdk.java.net (Tobias Holenstein)
Date: Thu, 3 Mar 2022 07:56:08 GMT
Subject: RFR: 8277055: Assert "missing inlining msg" with
 -XX:+PrintIntrinsics [v2]
In-Reply-To: <74tdeSabkBWUN8o7TbaTAvPMlWsze-e9T9AavG0X3rQ=.13d080af-adb6-4bbd-b076-677807ce36a2@github.com>
References: <4O-VnRkcKYv4jHhr1XXsDudUMnhEebv-_ocX0stgqqE=.2f9d8be0-2105-4de0-bbca-ba06936e121e@github.com>
 <e6eYiCN6OUirvoI8-CsjilFx5PyTVUTNti11Lq033mI=.fb2fb3d6-cea2-4067-a182-fbc92c0d5442@github.com>
 <74tdeSabkBWUN8o7TbaTAvPMlWsze-e9T9AavG0X3rQ=.13d080af-adb6-4bbd-b076-677807ce36a2@github.com>
Message-ID: <g8KOklkg53k7KK0tW1JJNLVqXCaDuzGh31vBlqNjNqk=.30710fce-edbd-4697-a15b-09a3fd3db3a6@github.com>

On Tue, 1 Mar 2022 14:07:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Tobias Holenstein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more detailed message
>
> Looks good to me too. Thanks for updating the inlining message to include the reason.

Thanks @TobiHartmann and @rwestrel for the review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7385

From duke at openjdk.java.net  Thu Mar  3 08:03:08 2022
From: duke at openjdk.java.net (Tobias Holenstein)
Date: Thu, 3 Mar 2022 08:03:08 GMT
Subject: Integrated: 8277055: Assert "missing inlining msg" with
 -XX:+PrintIntrinsics
In-Reply-To: <4O-VnRkcKYv4jHhr1XXsDudUMnhEebv-_ocX0stgqqE=.2f9d8be0-2105-4de0-bbca-ba06936e121e@github.com>
References: <4O-VnRkcKYv4jHhr1XXsDudUMnhEebv-_ocX0stgqqE=.2f9d8be0-2105-4de0-bbca-ba06936e121e@github.com>
Message-ID: <2RepQKTaOE5NC0_JL6k-0ywPyCdgop3Ysc1PtNRgl1M=.eeeebf00-d8e5-45fd-adfb-f19d12f60da1@github.com>

On Tue, 8 Feb 2022 16:57:20 GMT, Tobias Holenstein <duke at openjdk.java.net> wrote:

> in `CallGenerator::do_late_inline_helper()` we hit an assert `"missing inlining msg"` when calling  `C->print_inlining_update_delayed(this)`. The reason is that not all implementations of do_late_inline_check() print an inline message. The fix is to add an inline message for the two `return false` in `LateInlineVirtualCallGenerator::do_late_inline_check(...)` where we do not print an inline message.
> 
> Tier1-3 passed

This pull request has now been integrated.

Changeset: b1f935c1
Author:    Tobias Holenstein <tobias.holenstein at oracle.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b1f935c1d0d3729470b57832cf74c43d49ea1f71
Stats:     14 lines in 2 files changed: 11 ins; 0 del; 3 mod

8277055: Assert "missing inlining msg" with -XX:+PrintIntrinsics

Reviewed-by: roland, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7385

From xgong at openjdk.java.net  Thu Mar  3 08:12:46 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 3 Mar 2022 08:12:46 GMT
Subject: RFR: 8282432: Optimize masked "test" Vector API with predicate
 feature [v2]
In-Reply-To: <RlORBnCyrfaaTry0T08GvIcNFPFptQcFuMLRp7_xa6M=.4872305b-525d-4bee-9ec6-354950b87605@github.com>
References: <RlORBnCyrfaaTry0T08GvIcNFPFptQcFuMLRp7_xa6M=.4872305b-525d-4bee-9ec6-354950b87605@github.com>
Message-ID: <Kt2y_yNkybBAXAS4z-rmKXBmE19qfooLEnTM6mCWejI=.4267af7f-1916-4cfc-9f9e-5ccb6227c019@github.com>

> The vector `"test"` api is implemented with vector `"compare"`. And the masked `"test" `is implemented with `"test(op).and(m)"` which means `"compare().and(m)"` finally. Since the masked vector `"compare"` has been optimized with predicated instruction for archituctures that support the feature, the masked `"test"` can also be optimized by implementing it with the predicated compare. This could save the additional ` "and"` for architectures that support the predicate feature.
> 
> This patch optimized the masked `"test"` by implementing it with masked `"compare"`. With this patch, the following codes for the` "IS_NEGATIVE"` op for a DoubleVector with SVE:
> 
>   mov z19.d, #0
>   cmpgt   p1.d, p7/z, z19.d, z17.d
>   and p0.b, p7/z, p1.b, p0.b
> 
> are optimized to:
> 
>   mov z19.d, #0
>   cmpgt   p0.d, p0/z, z19.d, z17.d
> 
> Also update the jtreg tests for masked` "test" ` to make sure they are hot enough to be compiled by c2.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Simply the testTemplate

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7654/files
  - new: https://git.openjdk.java.net/jdk/pull/7654/files/41a9d56f..c90d2f49

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7654&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7654&range=00-01

  Stats: 197 lines in 49 files changed: 13 ins; 33 del; 151 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7654.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7654/head:pull/7654

PR: https://git.openjdk.java.net/jdk/pull/7654

From xgong at openjdk.java.net  Thu Mar  3 08:12:48 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 3 Mar 2022 08:12:48 GMT
Subject: RFR: 8282432: Optimize masked "test" Vector API with predicate
 feature
In-Reply-To: <RlORBnCyrfaaTry0T08GvIcNFPFptQcFuMLRp7_xa6M=.4872305b-525d-4bee-9ec6-354950b87605@github.com>
References: <RlORBnCyrfaaTry0T08GvIcNFPFptQcFuMLRp7_xa6M=.4872305b-525d-4bee-9ec6-354950b87605@github.com>
Message-ID: <vA7Y5LD62TXE5pYQJcpRnVX5wAvXMhzKrcFFa7yaWu4=.078a8100-01d0-45a6-ac95-cbc5dc8c2443@github.com>

On Wed, 2 Mar 2022 02:50:27 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The vector `"test"` api is implemented with vector `"compare"`. And the masked `"test" `is implemented with `"test(op).and(m)"` which means `"compare().and(m)"` finally. Since the masked vector `"compare"` has been optimized with predicated instruction for archituctures that support the feature, the masked `"test"` can also be optimized by implementing it with the predicated compare. This could save the additional ` "and"` for architectures that support the predicate feature.
> 
> This patch optimized the masked `"test"` by implementing it with masked `"compare"`. With this patch, the following codes for the` "IS_NEGATIVE"` op for a DoubleVector with SVE:
> 
>   mov z19.d, #0
>   cmpgt   p1.d, p7/z, z19.d, z17.d
>   and p0.b, p7/z, p1.b, p0.b
> 
> are optimized to:
> 
>   mov z19.d, #0
>   cmpgt   p0.d, p0/z, z19.d, z17.d
> 
> Also update the jtreg tests for masked` "test" ` to make sure they are hot enough to be compiled by c2.

Hi @PaulSandoz , thanks for your review! All the comments have been address. Could you please take a look at it again? Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7654

From roland at openjdk.java.net  Thu Mar  3 09:06:43 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 3 Mar 2022 09:06:43 GMT
Subject: RFR: 8278296: Generalize long range check transformation [v7]
In-Reply-To: <Khntpfq1O8Ea-1lFIi3di44_E9YmuVsayLDVgc7xV0A=.b4996073-64c1-4cda-b778-d242c06ccc43@github.com>
References: <Khntpfq1O8Ea-1lFIi3di44_E9YmuVsayLDVgc7xV0A=.b4996073-64c1-4cda-b778-d242c06ccc43@github.com>
Message-ID: <5rM8EWPO7RSeKXP1aOtDVtYJv1w5GYGv7mj5AR3A6OA=.f9cb94a8-2894-4e59-a0af-4b5ea72f01e8@github.com>

> 8259609 (C2: optimize long range checks in long counted loops) only
> covered the case of a counted loop with a positive stride and a range
> check with a positive scale. This change generalizes the long range
> check transformation to all 4 combinations of stride and scale signs.
> 
> The stride > 0, scale > 0 case (covered 8259609) was tweaked so it now
> uses Qmax computed as the inclusive limit of j*K+Q. That helps in
> generalizing the formulas to other cases.
> 
> The addition of PhaseIdealLoop::is_scaled_iv_plus_extra_offset() was
> required for the case of negative scale in an int loop. The range
> check then has the shape:
> 
> (CmpUL (AddL (ConvI2L (SubI ConI (LshiftI (Phi
> 
> with ConI, the zero constant.
> 
> This change also addresses this comment from John:
> 
> https://github.com/openjdk/jdk/pull/6576#discussion_r765343664
> 
> as part of 8276116 (C2: optimize long range checks in int counted loops)

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  build fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6989/files
  - new: https://git.openjdk.java.net/jdk/pull/6989/files/6a2ae123..a25701a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6989&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6989&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6989.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6989/head:pull/6989

PR: https://git.openjdk.java.net/jdk/pull/6989

From duke at openjdk.java.net  Thu Mar  3 11:34:21 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Thu, 3 Mar 2022 11:34:21 GMT
Subject: RFR: 8282573: ByteBufferTest.java: replace endless recursion with
 RuntimeException in void ck(double x, double y)
Message-ID: <IbrYwGg0FHZuJc435zaAxXm6CDdBwckmLvet474j1sc=.08398081-1f2c-4285-809e-8c087c89e99c@github.com>

There are two functions that check for equality.
void ck(long x, long y): already throws a RuntimeException if we observe inequality
void ck(double x, double y): called itself, leading to endless recursion and a StackOverflowError.

Instead of the recursion, I now also throw a RuntimeException.

This can currently be triggered with
`path-to-jtreg/jtreg -va -s -jdk:jdk-path -javaoptions:"-XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressGCM -XX:+OptoScheduling -XX:StressSeed=293843391" test/hotspot/jtreg/compiler/intrinsics/unsafe/HeapByteBufferTest.java `
(see bug [JDK-8282555](https://bugs.openjdk.java.net/browse/JDK-8282555))

This way I could verify that instead of StackOverflowError we now get RuntimeException, as desired.
Ran some basic tests to ensure I didn't break things.

-------------

Commit messages:
 - missed a line
 - 8282573: ByteBufferTest.java: replace endless recursion with RuntimeException in void ck(double x, double y)

Changes: https://git.openjdk.java.net/jdk/pull/7674/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7674&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282573
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7674.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7674/head:pull/7674

PR: https://git.openjdk.java.net/jdk/pull/7674

From thartmann at openjdk.java.net  Thu Mar  3 14:29:59 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 3 Mar 2022 14:29:59 GMT
Subject: RFR: 8282573: ByteBufferTest.java: replace endless recursion with
 RuntimeException in void ck(double x, double y)
In-Reply-To: <IbrYwGg0FHZuJc435zaAxXm6CDdBwckmLvet474j1sc=.08398081-1f2c-4285-809e-8c087c89e99c@github.com>
References: <IbrYwGg0FHZuJc435zaAxXm6CDdBwckmLvet474j1sc=.08398081-1f2c-4285-809e-8c087c89e99c@github.com>
Message-ID: <aQd0yGzg1q_eaME-Pco89RdSznIaVa-pe5T7F5k40hQ=.b9bc94e5-226a-4c99-bed6-d4d394538a49@github.com>

On Thu, 3 Mar 2022 11:24:04 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> There are two functions that check for equality.
> void ck(long x, long y): already throws a RuntimeException if we observe inequality
> void ck(double x, double y): called itself, leading to endless recursion and a StackOverflowError.
> 
> Instead of the recursion, I now also throw a RuntimeException.
> 
> This can currently be triggered with
> `path-to-jtreg/jtreg -va -s -jdk:jdk-path -javaoptions:"-XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressGCM -XX:+OptoScheduling -XX:StressSeed=293843391" test/hotspot/jtreg/compiler/intrinsics/unsafe/HeapByteBufferTest.java `
> (see bug [JDK-8282555](https://bugs.openjdk.java.net/browse/JDK-8282555))
> 
> This way I could verify that instead of StackOverflowError we now get RuntimeException, as desired.
> Ran some basic tests to ensure I didn't break things.

test/hotspot/jtreg/compiler/intrinsics/unsafe/ByteBufferTest.java line 219:

> 217: 
> 218:     void ck(double x, double y) {
> 219:         if (x == x && y == y && x != y) {

What are the `x == x` and `y == y` checks good for?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7674

From duke at openjdk.java.net  Thu Mar  3 16:26:41 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Thu, 3 Mar 2022 16:26:41 GMT
Subject: RFR: 8282573: ByteBufferTest.java: replace endless recursion with
 RuntimeException in void ck(double x, double y) [v2]
In-Reply-To: <IbrYwGg0FHZuJc435zaAxXm6CDdBwckmLvet474j1sc=.08398081-1f2c-4285-809e-8c087c89e99c@github.com>
References: <IbrYwGg0FHZuJc435zaAxXm6CDdBwckmLvet474j1sc=.08398081-1f2c-4285-809e-8c087c89e99c@github.com>
Message-ID: <jKDHPJNztE9gunzBixqIE0lCT_5LdGDzGmGaVxePL8Q=.df0641e9-9fe6-4697-911a-fa65305bb70d@github.com>

> There are two functions that check for equality.
> void ck(long x, long y): already throws a RuntimeException if we observe inequality
> void ck(double x, double y): called itself, leading to endless recursion and a StackOverflowError.
> 
> Instead of the recursion, I now also throw a RuntimeException.
> 
> This can currently be triggered with
> `path-to-jtreg/jtreg -va -s -jdk:jdk-path -javaoptions:"-XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressGCM -XX:+OptoScheduling -XX:StressSeed=293843391" test/hotspot/jtreg/compiler/intrinsics/unsafe/HeapByteBufferTest.java `
> (see bug [JDK-8282555](https://bugs.openjdk.java.net/browse/JDK-8282555))
> 
> This way I could verify that instead of StackOverflowError we now get RuntimeException, as desired.
> Ran some basic tests to ensure I didn't break things.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  removed unnecessary conditions

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7674/files
  - new: https://git.openjdk.java.net/jdk/pull/7674/files/4eca7cf8..17ad7a21

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7674&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7674&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7674.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7674/head:pull/7674

PR: https://git.openjdk.java.net/jdk/pull/7674

From duke at openjdk.java.net  Thu Mar  3 16:38:59 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Thu, 3 Mar 2022 16:38:59 GMT
Subject: RFR: 8282573: ByteBufferTest.java: replace endless recursion with
 RuntimeException in void ck(double x, double y) [v2]
In-Reply-To: <aQd0yGzg1q_eaME-Pco89RdSznIaVa-pe5T7F5k40hQ=.b9bc94e5-226a-4c99-bed6-d4d394538a49@github.com>
References: <IbrYwGg0FHZuJc435zaAxXm6CDdBwckmLvet474j1sc=.08398081-1f2c-4285-809e-8c087c89e99c@github.com>
 <aQd0yGzg1q_eaME-Pco89RdSznIaVa-pe5T7F5k40hQ=.b9bc94e5-226a-4c99-bed6-d4d394538a49@github.com>
Message-ID: <hfLgXhz2hrXNR8SpTj_WyROgkZTzbfAOlU5xfURE4QQ=.e7141964-e6d4-4c11-a2b2-cc838f60036f@github.com>

On Thu, 3 Mar 2022 14:26:41 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed unnecessary conditions
>
> test/hotspot/jtreg/compiler/intrinsics/unsafe/ByteBufferTest.java line 219:
> 
>> 217: 
>> 218:     void ck(double x, double y) {
>> 219:         if (x == x && y == y && x != y) {
> 
> What are the `x == x` and `y == y` checks good for?

I removed it. @PaulSandoz agreed that this method was very suspect. I should try removing it. There is an off chance it could create some NaN issues on odd platforms.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7674

From psandoz at openjdk.java.net  Thu Mar  3 17:43:06 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 3 Mar 2022 17:43:06 GMT
Subject: RFR: 8282432: Optimize masked "test" Vector API with predicate
 feature [v2]
In-Reply-To: <Kt2y_yNkybBAXAS4z-rmKXBmE19qfooLEnTM6mCWejI=.4267af7f-1916-4cfc-9f9e-5ccb6227c019@github.com>
References: <RlORBnCyrfaaTry0T08GvIcNFPFptQcFuMLRp7_xa6M=.4872305b-525d-4bee-9ec6-354950b87605@github.com>
 <Kt2y_yNkybBAXAS4z-rmKXBmE19qfooLEnTM6mCWejI=.4267af7f-1916-4cfc-9f9e-5ccb6227c019@github.com>
Message-ID: <PZYFGsRTFUuVcp_KAxIiqkmFJG8_RVyNB5CIJB5KZZI=.ba35562e-b7d8-43e6-9d67-aed521373fe8@github.com>

On Thu, 3 Mar 2022 08:12:46 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The vector `"test"` api is implemented with vector `"compare"`. And the masked `"test" `is implemented with `"test(op).and(m)"` which means `"compare().and(m)"` finally. Since the masked vector `"compare"` has been optimized with predicated instruction for archituctures that support the feature, the masked `"test"` can also be optimized by implementing it with the predicated compare. This could save the additional ` "and"` for architectures that support the predicate feature.
>> 
>> This patch optimized the masked `"test"` by implementing it with masked `"compare"`. With this patch, the following codes for the` "IS_NEGATIVE"` op for a DoubleVector with SVE:
>> 
>>   mov z19.d, #0
>>   cmpgt   p1.d, p7/z, z19.d, z17.d
>>   and p0.b, p7/z, p1.b, p0.b
>> 
>> are optimized to:
>> 
>>   mov z19.d, #0
>>   cmpgt   p0.d, p0/z, z19.d, z17.d
>> 
>> Also update the jtreg tests for masked` "test" ` to make sure they are hot enough to be compiled by c2.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simply the testTemplate

I guess the following:
`mask.cast(IntVector.species(shape())`
is more efficient than:
`m.cast(vspecies().asIntegral()))`
?

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7654

From psandoz at openjdk.java.net  Thu Mar  3 17:58:04 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 3 Mar 2022 17:58:04 GMT
Subject: RFR: 8282573: ByteBufferTest.java: replace endless recursion with
 RuntimeException in void ck(double x, double y) [v2]
In-Reply-To: <jKDHPJNztE9gunzBixqIE0lCT_5LdGDzGmGaVxePL8Q=.df0641e9-9fe6-4697-911a-fa65305bb70d@github.com>
References: <IbrYwGg0FHZuJc435zaAxXm6CDdBwckmLvet474j1sc=.08398081-1f2c-4285-809e-8c087c89e99c@github.com>
 <jKDHPJNztE9gunzBixqIE0lCT_5LdGDzGmGaVxePL8Q=.df0641e9-9fe6-4697-911a-fa65305bb70d@github.com>
Message-ID: <MTp_OZ2rBZ9vFWa-P7GixJ7mh8m_B0SYKGHCJpdniZY=.9413f608-6cee-412a-9437-3e29cf74372a@github.com>

On Thu, 3 Mar 2022 16:26:41 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> There are two functions that check for equality.
>> void ck(long x, long y): already throws a RuntimeException if we observe inequality
>> void ck(double x, double y): called itself, leading to endless recursion and a StackOverflowError.
>> 
>> Instead of the recursion, I now also throw a RuntimeException.
>> 
>> This can currently be triggered with
>> `path-to-jtreg/jtreg -va -s -jdk:jdk-path -javaoptions:"-XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressGCM -XX:+OptoScheduling -XX:StressSeed=293843391" test/hotspot/jtreg/compiler/intrinsics/unsafe/HeapByteBufferTest.java `
>> (see bug [JDK-8282555](https://bugs.openjdk.java.net/browse/JDK-8282555))
>> 
>> This way I could verify that instead of StackOverflowError we now get RuntimeException, as desired.
>> Ran some basic tests to ensure I didn't break things.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unnecessary conditions

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7674

From sviswanathan at openjdk.java.net  Fri Mar  4 00:17:09 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 4 Mar 2022 00:17:09 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v7]
In-Reply-To: <kATPxslgFX2I4XTxlzpbOHK_4toQrppMxrtKFaIbgJI=.c098b898-89cd-4c29-9422-177450f1c399@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <kATPxslgFX2I4XTxlzpbOHK_4toQrppMxrtKFaIbgJI=.c098b898-89cd-4c29-9422-177450f1c399@github.com>
Message-ID: <T55SM6UdViOaoS4-pIo1g7TD6OMaWo_8wYePdKRTLfI=.624dc319-fe68-4d61-8a5b-522ed07de777@github.com>

On Tue, 1 Mar 2022 17:08:51 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> 
>> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
>> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
>> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
>> 
>> 
>> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
>> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
>> 
>> Please review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8281375: Review comments resolved.

src/hotspot/cpu/x86/assembler_x86.cpp line 8329:

> 8327: void Assembler::vpunpckhdq(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
> 8328:   assert(UseAVX > 0, "requires some form of AVX");
> 8329:   InstructionAttr attributes(vector_len, /* vex_w */ false, /* legacy_mode */ _legacy_mode_bw, /* no_mask_reg */ true, /* uses_vl */ true);

legacy_mode should be false here.

src/hotspot/cpu/x86/assembler_x86.cpp line 8336:

> 8334: void Assembler::vpunpckldq(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
> 8335:   assert(UseAVX > 0, "requires some form of AVX");
> 8336:   InstructionAttr attributes(vector_len, /* vex_w */ false, /* legacy_mode */ _legacy_mode_bw, /* no_mask_reg */ true, /* uses_vl */ true);

legacy_mode should be false here.

src/hotspot/cpu/x86/assembler_x86.cpp line 8341:

> 8339: }
> 8340: 
> 8341: // xmm/mem sourced byte/word/dword/qword replicate

The comment seems to be misplaced.

src/hotspot/cpu/x86/assembler_x86.cpp line 8342:

> 8340: 
> 8341: // xmm/mem sourced byte/word/dword/qword replicate
> 8342: void Assembler::evpsadbw(XMMRegister dst, KRegister mask, XMMRegister nds, XMMRegister src, bool merge, int vector_len) {

There is no masked version of evpsadbw documented which takes any k registers in the manual so we should be able to use the vpsadbw() defined before and remove evpsadbw()?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4360:

> 4358:     vpopcntd(dst, src, vec_enc);
> 4359:   } else if (vec_enc == Assembler::AVX_512bit) {
> 4360:     assert(VM_Version::supports_avx512vlbw(), "");

I think check for supports_avx512bw() is enough here. Do we need vl?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4374:

> 4372:     evpsadbw(dst, k0, dst, xtmp1, true, vec_enc);
> 4373:     evpunpckldq(xtmp2, k0, xtmp3, xtmp1, true, vec_enc);
> 4374:     evpsadbw(xtmp2, k0, xtmp2, xtmp1, true, vec_enc);

The merge masking can be set to false for the entire algorithm, because k is always all set and no merging at all needed.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4393:

> 4391:     vpunpckldq(xtmp2, xtmp3, xtmp1, vec_enc);
> 4392:     vpsadbw(xtmp2, xtmp2, xtmp1, vec_enc);
> 4393:     vpackuswb(dst, xtmp2, dst, vec_enc);

This code is common with the 512 bit version, vec_enc decides the proper encoding, could be merged together. This also then removes the need for adding the evpunpck* instructions. K0 mask is implicit.

src/hotspot/cpu/x86/x86.ad line 1870:

> 1868:     case Op_PopCountVI:
> 1869:       if (!VM_Version::supports_avx512_vpopcntdq() &&
> 1870:           (vlen == 16) && !VM_Version::supports_avx512vlbw()) {

For vlen==16, check for only avx512bw() is needed.

src/hotspot/cpu/x86/x86.ad line 1876:

> 1874:     case Op_PopCountVL:
> 1875:       if (!VM_Version::supports_avx512_vpopcntdq() &&
> 1876:           ((vlen <= 4) || ((vlen == 8) && !VM_Version::supports_avx512vlbw()))) {

In case of long vlen==8, check for only avx512bw() is needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From sviswanathan at openjdk.java.net  Fri Mar  4 00:17:09 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 4 Mar 2022 00:17:09 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v6]
In-Reply-To: <ofoTU7thT9CEgwCeKaQpT72zPMOwXz8tes2OQoOTrfY=.b3e0977d-0ad1-4fa3-a4c6-75e34be1e44b@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <Z4B8qhzPcjVwfeOVtdqg2jY0O1F7KaPjKHs0vc42dcg=.83c1e538-4a20-4762-89a2-97060e8933ab@github.com>
 <vebauRd6DIyA2qje9cw2YAVXuzHeUlyqVe7vdPvZVo0=.1d791a9f-3de3-4b37-b236-d7e1ea81855a@github.com>
 <vXKnwFri-UtLPcwFg86Om-dLk40CK9YWkM2ht_g9-VA=.8e4c856d-57eb-4bf5-bf1c-71905d958d9e@github.com>
 <xZjAlpBvr8wTPrPimwBPWzPDelA5s5w3jhkFL54m9P8=.7fd20387-c91e-42bf-8875-0c83679667be@github.com>
 <ofoTU7thT9CEgwCeKaQpT72zPMOwXz8tes2OQoOTrfY=.b3e0977d-0ad1-4fa3-a4c6-75e34be1e44b@github.com>
Message-ID: <vGPC_ojXtK-ViHMG5yAlA7TqqWYo4L39P_N8wTTtdPo=.2ad6ff58-4cbb-45af-9f9d-afd5279bb269@github.com>

On Wed, 2 Mar 2022 05:02:02 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> The problem is at 512 bit level.
>
> original 512 bit vector holding 16 integers = [ a15 a14 a13 a12, a11 a10 a9 a8 ,a7 a6 a5 a4 ,a3 a2 a1 a0 ]
>  unpackdq lower:
>                 512 bit (vec1) 
>    128           128        128      128
>  0 a13 0 a12  0 a9 0 a8  0 a5 0 a4  0 a1 0 a0
>  unpackdq higher:
>                 512 bit (vec1) 
>    128           128        128      128
>  0 a15 0 a14  0 a11 0 a10  0 a7 0 a6  0 a3 0 a2
>  Next sum of absolute difference operation followed by pack will squeez each 128 bit lane of two participant vectors
>  and interleave them in resulatant vector.
>          VEC1_L3     VEC1_L2     VEC1_L1   VEC1_L0              VEC2_L3     VEC2_L2      VEC2_L1    VEC2_L0           
>  [ 0 sa13 0 sa12  0 sa9 0 sa8  0 sa5 0 sa4  0 sa1 0 sa0 ] [ 0 sa15 0 sa14  0 sa11 0 sa10  0 sa7 0 sa6  0 sa3 0 sa2 ]
>  [ sa15 sa14 sa13 sa12   sa11 sa10 sa9 sa8  sa7 sa6 sa5 sa4  sa3 sa2 sa1 sa0]

Thanks for the clarification this looks good for 512 bit, I missed the reordering done by punpck.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From dlong at openjdk.java.net  Fri Mar  4 03:07:01 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 4 Mar 2022 03:07:01 GMT
Subject: RFR: 8279886: C1: Turn off SelectivePhiFunctions in presence of
 irreducible loops [v2]
In-Reply-To: <Yoat8TsWJuuo2NKA-3ze-kdcBqb_9jJwDL568NYH31k=.ff83b2da-8eac-4a5f-a514-433238897826@github.com>
References: <9hUbaevqiNT2GmsBxLbGYHYFmSMeDZZDaBkUpuJFBHk=.b7da7542-844d-4d8c-8f61-ee0eca5a3500@github.com>
 <Yoat8TsWJuuo2NKA-3ze-kdcBqb_9jJwDL568NYH31k=.ff83b2da-8eac-4a5f-a514-433238897826@github.com>
Message-ID: <TMaRw9EYEIp5zOCL6ThTQ5RkjNafxU59VWY2ky_7guk=.8fe2ab1f-96d5-4159-a3c2-896ef2a213cf@github.com>

On Tue, 1 Mar 2022 15:50:24 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> This change add irreducible loops detection to `BlockListBuilder::mark_loops()` - a loop marking routine necessary for the SSA conversion. Here is brief description of the algorithm (copy-pasted from the comments I left in the code).
>> 
>> The loop detection algorithm works as follows:
>> 
>> - We maintain the `_loop_map`, where for each block we have a bitmap indicating which loops contain this block.
>> - The CFG is recursively traversed (depth-first) and if we detect a loop, we assign the loop a unique number that is stored in the bitmap associated with the loop header block. Until we return back through that loop header the bitmap contains only a single bit corresponding to the loop number.
>> - The bit is then propagated for all the blocks in the loop after we exit them (post-order). There could be multiple bits of course in case of nested loops.
>> - When we exit the loop header we remove that single bit and assign the real loop state for it.
>> - Now, the tricky part here is how we detect irriducible loops. In the algorithm above the loop state bits are propagated to the predecessors. If we encounter an irreducible loop (a loop with multiple heads) we would see a node with some loop bit set that would then propagate back and be never cleared because we would never go back through the original loop header. Therefore if there are any irreducible loops the bits in the states for these loops are going to propagate back to the root.
>> 
>> Testing is clean: hs-tier{1-7}
>
> Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Add comments
>  - Detect irreducible loops during parsing/phi insertion.

Very nice!

-------------

Marked as reviewed by dlong (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7636

From yyang at openjdk.java.net  Fri Mar  4 03:20:15 2022
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 4 Mar 2022 03:20:15 GMT
Subject: RFR: 8282638: [JVMCI] Export array fill stubs to JVMCI compiler
Message-ID: <IA700lw7ASoS-4yFLB6AyjoTsEjwcgEhiuCwEKPz9vQ=.1b349a2e-8d56-4570-953a-87b2baba7d17@github.com>

Export array _jint_fill,_jshort_fill,jbyte_fill,_arrayof_jshort_fill,_arrayof_jbyte_fill,_arrayof_jint_fill to JVMCI compiler

-------------

Commit messages:
 - 8282638: [JVMCI] Export array fill stubs to JVMCI compiler

Changes: https://git.openjdk.java.net/jdk/pull/7685/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7685&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282638
  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7685.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7685/head:pull/7685

PR: https://git.openjdk.java.net/jdk/pull/7685

From iveresov at openjdk.java.net  Fri Mar  4 03:53:09 2022
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 4 Mar 2022 03:53:09 GMT
Subject: RFR: 8279886: C1: Turn off SelectivePhiFunctions in presence of
 irreducible loops [v2]
In-Reply-To: <BwbQB-AkL57g7N6wW0v0js9rYVontEt4JKqx2t2AJ-A=.09de7457-078a-4512-aa91-f6c673329c6f@github.com>
References: <9hUbaevqiNT2GmsBxLbGYHYFmSMeDZZDaBkUpuJFBHk=.b7da7542-844d-4d8c-8f61-ee0eca5a3500@github.com>
 <Yoat8TsWJuuo2NKA-3ze-kdcBqb_9jJwDL568NYH31k=.ff83b2da-8eac-4a5f-a514-433238897826@github.com>
 <BwbQB-AkL57g7N6wW0v0js9rYVontEt4JKqx2t2AJ-A=.09de7457-078a-4512-aa91-f6c673329c6f@github.com>
Message-ID: <P7kSi5HQNKALBOukTj-v3Abm2jNwrzk0U8Ok2Tkyd-k=.52ab74c2-1e7a-45e4-a9d7-27e3c26c9a29@github.com>

On Tue, 1 Mar 2022 21:07:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Add comments
>>  - Detect irreducible loops during parsing/phi insertion.
>
> Looks good.

Thanks @vnkozlov and @dean-long for the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7636

From iveresov at openjdk.java.net  Fri Mar  4 03:53:09 2022
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 4 Mar 2022 03:53:09 GMT
Subject: Integrated: 8279886: C1: Turn off SelectivePhiFunctions in presence of
 irreducible loops
In-Reply-To: <9hUbaevqiNT2GmsBxLbGYHYFmSMeDZZDaBkUpuJFBHk=.b7da7542-844d-4d8c-8f61-ee0eca5a3500@github.com>
References: <9hUbaevqiNT2GmsBxLbGYHYFmSMeDZZDaBkUpuJFBHk=.b7da7542-844d-4d8c-8f61-ee0eca5a3500@github.com>
Message-ID: <mSjgYR32qsoiD7Tg9Vl-rtryAjUwm7ymBZqLg1Hi1aI=.f8274440-be97-4b46-a0fc-a8206fe30936@github.com>

On Mon, 28 Feb 2022 20:46:26 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

> This change add irreducible loops detection to `BlockListBuilder::mark_loops()` - a loop marking routine necessary for the SSA conversion. Here is brief description of the algorithm (copy-pasted from the comments I left in the code).
> 
> The loop detection algorithm works as follows:
> 
> - We maintain the `_loop_map`, where for each block we have a bitmap indicating which loops contain this block.
> - The CFG is recursively traversed (depth-first) and if we detect a loop, we assign the loop a unique number that is stored in the bitmap associated with the loop header block. Until we return back through that loop header the bitmap contains only a single bit corresponding to the loop number.
> - The bit is then propagated for all the blocks in the loop after we exit them (post-order). There could be multiple bits of course in case of nested loops.
> - When we exit the loop header we remove that single bit and assign the real loop state for it.
> - Now, the tricky part here is how we detect irriducible loops. In the algorithm above the loop state bits are propagated to the predecessors. If we encounter an irreducible loop (a loop with multiple heads) we would see a node with some loop bit set that would then propagate back and be never cleared because we would never go back through the original loop header. Therefore if there are any irreducible loops the bits in the states for these loops are going to propagate back to the root.
> 
> Testing is clean: hs-tier{1-7}

This pull request has now been integrated.

Changeset: b629782b
Author:    Igor Veresov <iveresov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b629782b8d44e8aa8a99c6a3381663a6169aa1ad
Stats:     63 lines in 5 files changed: 27 ins; 7 del; 29 mod

8279886: C1: Turn off SelectivePhiFunctions in presence of irreducible loops

Reviewed-by: kvn, dlong

-------------

PR: https://git.openjdk.java.net/jdk/pull/7636

From jiefu at openjdk.java.net  Fri Mar  4 05:09:08 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 4 Mar 2022 05:09:08 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v6]
In-Reply-To: <2OyaRp6UdLYtDJSJQash1i6Nfo4jriWELQA30ITrwIY=.ab68593c-de96-493f-a215-0be40cb69a36@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <atA1KlK27dwDA_AEuBgA0goEn6lQc1uZ-xhCT08NZgU=.f02e1fa5-f289-44d5-9715-7efcfe73418d@github.com>
 <2OyaRp6UdLYtDJSJQash1i6Nfo4jriWELQA30ITrwIY=.ab68593c-de96-493f-a215-0be40cb69a36@github.com>
Message-ID: <Jo3XA87VAmFI6N6lUaP4oVLwtT4Emk54cPr7H-Z55fE=.19306b7a-1c51-49a9-b248-ee6365008bf5@github.com>

On Mon, 28 Feb 2022 23:42:13 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reviews
>
> The tool measures the throughput of the operations, which is the number of cycles per iteration. Because the processor can execute multiple instructions at the same time, to measure the latency, you should create a dependency chain between the output of the instruction and its input in the next iteration. The technique used by uops.info is to `movsx` (which is an instruction that is not elided) from the output operand back to the input operand, so that the processor must wait for the result of the previous iteration before executing the next one, instead of executing multiple iterations concurrently when there is a lack of dependencies.
> 
> A simple `lea rax, [rbp + rcx + 0x8]; movsx rbp, eax` gives the throughput of 4 cycles, minus the latency of the `movsx` which is 1 gives you the documented latency of 3 (this is the latency between the output and the base operand, similar experiment will give the same answer for the latency between the output and the index operand).
> 
> Thanks.

Hi @merykitty ,

Thanks for your update.

Instead of removing `leaI_rReg_immI`, I would suggest enabling it.

I tried to match it based on your latest patch like this and saw about 2% perf improvement of B_D_int.

diff --git a/src/hotspot/cpu/x86/x86_64.ad b/src/hotspot/cpu/x86/x86_64.ad
index f86dbbb..45f4730 100644
--- a/src/hotspot/cpu/x86/x86_64.ad
+++ b/src/hotspot/cpu/x86/x86_64.ad
@@ -7388,6 +7388,19 @@ instruct addI_rReg(rRegI dst, rRegI src, rFlagsReg cr)
   ins_pipe(ialu_reg_reg);
 %}
 
+instruct leaI_rReg_immI(rRegI dst, no_rbp_r13_RegI base, immI disp)
+%{
+  predicate(VM_Version::supports_fast_2op_lea());
+  match(Set dst (AddI base disp));
+
+  ins_cost(110);
+  format %{ "addr32 leal $dst, [$base + $disp]\t# int" %}
+  ins_encode %{
+    __ leal($dst$$Register, Address($base$$Register, $disp$$constant));
+  %}
+  ins_pipe(ialu_reg_reg);
+%}
+
 instruct addI_rReg_imm(rRegI dst, immI src, rFlagsReg cr)
 %{
   match(Set dst (AddI dst src));
diff --git a/test/micro/org/openjdk/bench/vm/compiler/LeaInstruction.java b/test/micro/org/openjdk/bench/vm/compiler/LeaInstruction.java
index 02b10d7..335c032 100644
--- a/test/micro/org/openjdk/bench/vm/compiler/LeaInstruction.java
+++ b/test/micro/org/openjdk/bench/vm/compiler/LeaInstruction.java
@@ -46,6 +46,17 @@ public class LeaInstruction {
     }
 
     @Benchmark
+    public void B_D_int(Blackhole bh) { 
+        int x = this.x, y = this.y;
+        for (int i = 0; i < ITERATION; i++) {
+            x = x + 10;
+            y = y + 20;
+            bh.consume(x);
+            bh.consume(y);
+        }
+    }
+
+    @Benchmark
     public void B_I_D_int(Blackhole bh) {
         int x = this.x, y = this.y;
         for (int i = 0; i < ITERATION; i++) {


There are also `leaL_rReg_immL` and `leaP_rReg_imm` to be enabled.

What do you think?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Fri Mar  4 05:09:09 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 4 Mar 2022 05:09:09 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v8]
In-Reply-To: <Xhms0oY8qb3-q5ZoUtvk_sGqDR1OarFB48x8F1buG_I=.eb3debf6-1297-4450-8199-83b40bb97beb@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <tNKnyG13TLhpmdmqj5rCrZ3nwiizmvuxghP-_byMdPg=.713531f5-531e-41b0-8abb-411cec6444d0@github.com>
 <Xhms0oY8qb3-q5ZoUtvk_sGqDR1OarFB48x8F1buG_I=.eb3debf6-1297-4450-8199-83b40bb97beb@github.com>
Message-ID: <Xaehv0630GWVsTmdnmY0uc6sp8xYmsc3ZPToiQMzXWA=.ec9f6729-72f5-4862-9634-695a1330fc24@github.com>

On Wed, 2 Mar 2022 14:41:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address reviews
>
> src/hotspot/cpu/x86/x86_64.ad line 7446:
> 
>> 7444: %}
>> 7445: 
>> 7446: instruct leaI_rReg_immI(rRegI dst, rRegI src0, immI src1)
> 
> I'm not sure if there would be any unexpected side-effect caused by the removal of `leaI_rReg_immI`.
> Why you said it seems never be matched?

The rule happens after `addI_rReg_imm` and has higher cost. I perceive it is there to define the peephole rule down below

https://github.com/openjdk/jdk/blob/b6c35ae44aeb31deb7a15ee2939156ed00b3df52/src/hotspot/cpu/x86/x86_64.ad#L13284

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Fri Mar  4 05:09:10 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 4 Mar 2022 05:09:10 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v7]
In-Reply-To: <LO-w_tH7qm5KvT2ScHkYXD1JaAPtoFzbTrqQo11y9Gw=.565cf46b-0673-4451-849d-2ba751f3a348@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <tNKnyG13TLhpmdmqj5rCrZ3nwiizmvuxghP-_byMdPg=.713531f5-531e-41b0-8abb-411cec6444d0@github.com>
 <LO-w_tH7qm5KvT2ScHkYXD1JaAPtoFzbTrqQo11y9Gw=.565cf46b-0673-4451-849d-2ba751f3a348@github.com>
Message-ID: <JyIp1al9BXX_JaqDM1eUDYYbAsua2IADkhFpTwOYX84=.6e3b69e0-6e72-4c4b-bbbf-baaa7e35b15e@github.com>

On Wed, 2 Mar 2022 23:13:17 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove irrelevent changes
>
> test/micro/org/openjdk/bench/vm/compiler/LeaInstruction.java line 32:
> 
>> 30: @BenchmarkMode(Mode.AverageTime)
>> 31: @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> 32: @Fork(value = 2, jvmArgsAppend = {"-XX:LoopUnrollLimit=1"})
> 
> How about `value = 1`?
> I think it would reduce the micro-bench testing time, right?

I have addressed the reviews. Thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From jiefu at openjdk.java.net  Fri Mar  4 05:18:03 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 4 Mar 2022 05:18:03 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v8]
In-Reply-To: <L_BRRjCU4wv4e1jEKhm-M9SN2qzxls-tRbgdaF-Xd60=.b6e31bd2-6bb8-48d0-96b8-06bf6bbd6121@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <L_BRRjCU4wv4e1jEKhm-M9SN2qzxls-tRbgdaF-Xd60=.b6e31bd2-6bb8-48d0-96b8-06bf6bbd6121@github.com>
Message-ID: <7bZ05MC1ruaU_VKnYRnuuhi_tjv4UGZafS6GMKiUQFo=.b54408f9-f5f8-4269-b6da-a0022b68bae5@github.com>

On Thu, 3 Mar 2022 00:30:54 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address reviews

Maybe you have also noticed that the gcc will also generate `lea` for this method with -O{1, 2, 3}.

int test(int d) {
  return d + 5;
}


So why not also enable it for Java?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From darcy at openjdk.java.net  Fri Mar  4 06:10:09 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Mar 2022 06:10:09 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v9]
In-Reply-To: <C8UrQ5i-1DBVeT7O3uFmyLkGTCmHLcRVkyupDPocqeg=.d7ecc45f-e9f2-4ab9-9d4f-8c084f0d1a6a@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>
 <C8UrQ5i-1DBVeT7O3uFmyLkGTCmHLcRVkyupDPocqeg=.d7ecc45f-e9f2-4ab9-9d4f-8c084f0d1a6a@github.com>
Message-ID: <HnLSn9vdNL5YBqaQXPS9QNzFF6CM37GzX1cF-HUVq7Y=.6e99b156-1b77-44e4-9b73-e7e389ab6ff8@github.com>

On Tue, 1 Mar 2022 06:17:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8279508: Adding descriptive comments.
>
> test/jdk/java/lang/Math/RoundTests.java line 32:
> 
>> 30:     public static void main(String... args) {
>> 31:         int failures = 0;
>> 32:         for (int i = 0; i < 100000; i++) {
> 
> Is there an idiom to trigger the auto-vectorization, perhaps using command line arguments, that doesn't bloat the running time of this test?

IMO RoundTests should have a explicit @run tag without any VM options as well.

Do the added VM options run on all platforms in question? What is the approximate time to run the test run compared to before?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From jiefu at openjdk.java.net  Fri Mar  4 06:12:07 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 4 Mar 2022 06:12:07 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v6]
In-Reply-To: <Jo3XA87VAmFI6N6lUaP4oVLwtT4Emk54cPr7H-Z55fE=.19306b7a-1c51-49a9-b248-ee6365008bf5@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <atA1KlK27dwDA_AEuBgA0goEn6lQc1uZ-xhCT08NZgU=.f02e1fa5-f289-44d5-9715-7efcfe73418d@github.com>
 <2OyaRp6UdLYtDJSJQash1i6Nfo4jriWELQA30ITrwIY=.ab68593c-de96-493f-a215-0be40cb69a36@github.com>
 <Jo3XA87VAmFI6N6lUaP4oVLwtT4Emk54cPr7H-Z55fE=.19306b7a-1c51-49a9-b248-ee6365008bf5@github.com>
Message-ID: <bBVUquRPYKNFdP09734awXbbNG9HlnQ_qq54NCzcIdA=.80b56110-40c2-41d8-b302-b679e28116da@github.com>

On Fri, 4 Mar 2022 05:05:22 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> +instruct leaI_rReg_immI(rRegI dst, no_rbp_r13_RegI base, immI disp)

Should be ` +instruct leaI_rReg_immI(rRegI dst, rRegI base, immI disp)` , right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Fri Mar  4 06:29:43 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 4 Mar 2022 06:29:43 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v9]
In-Reply-To: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
Message-ID: <fP-WKU7L1MgZAWSlORClmC3w3_GM9Fe88FbB9hWjnVA=.3f23b274-3373-47f7-aab4-14ab6454f939@github.com>

> Hi,
> 
> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  remove 0x67 prefix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7560/files
  - new: https://git.openjdk.java.net/jdk/pull/7560/files/7d9b1e25..d171e82a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=07-08

  Stats: 7 lines in 2 files changed: 0 ins; 3 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7560/head:pull/7560

PR: https://git.openjdk.java.net/jdk/pull/7560

From thartmann at openjdk.java.net  Fri Mar  4 06:54:01 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 4 Mar 2022 06:54:01 GMT
Subject: RFR: 8282573: ByteBufferTest.java: replace endless recursion with
 RuntimeException in void ck(double x, double y) [v2]
In-Reply-To: <jKDHPJNztE9gunzBixqIE0lCT_5LdGDzGmGaVxePL8Q=.df0641e9-9fe6-4697-911a-fa65305bb70d@github.com>
References: <IbrYwGg0FHZuJc435zaAxXm6CDdBwckmLvet474j1sc=.08398081-1f2c-4285-809e-8c087c89e99c@github.com>
 <jKDHPJNztE9gunzBixqIE0lCT_5LdGDzGmGaVxePL8Q=.df0641e9-9fe6-4697-911a-fa65305bb70d@github.com>
Message-ID: <1ILgzn3-A4b4HF--bG-B9GhWusUWhh_eImCCKwhDlkE=.4cc7d8f4-03f6-4ed8-85b8-9a115de6a3ec@github.com>

On Thu, 3 Mar 2022 16:26:41 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> There are two functions that check for equality.
>> void ck(long x, long y): already throws a RuntimeException if we observe inequality
>> void ck(double x, double y): called itself, leading to endless recursion and a StackOverflowError.
>> 
>> Instead of the recursion, I now also throw a RuntimeException.
>> 
>> This can currently be triggered with
>> `path-to-jtreg/jtreg -va -s -jdk:jdk-path -javaoptions:"-XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressGCM -XX:+OptoScheduling -XX:StressSeed=293843391" test/hotspot/jtreg/compiler/intrinsics/unsafe/HeapByteBufferTest.java `
>> (see bug [JDK-8282555](https://bugs.openjdk.java.net/browse/JDK-8282555))
>> 
>> This way I could verify that instead of StackOverflowError we now get RuntimeException, as desired.
>> Ran some basic tests to ensure I didn't break things.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unnecessary conditions

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7674

From duke at openjdk.java.net  Fri Mar  4 07:02:04 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 4 Mar 2022 07:02:04 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v9]
In-Reply-To: <fP-WKU7L1MgZAWSlORClmC3w3_GM9Fe88FbB9hWjnVA=.3f23b274-3373-47f7-aab4-14ab6454f939@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <fP-WKU7L1MgZAWSlORClmC3w3_GM9Fe88FbB9hWjnVA=.3f23b274-3373-47f7-aab4-14ab6454f939@github.com>
Message-ID: <YWie-q2PBzr-dH4URicQfPoQeSCRqXs99dM9Bq_ErzM=.1e8392ec-258b-4d6b-ba38-c7146762f785@github.com>

On Fri, 4 Mar 2022 06:29:43 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove 0x67 prefix

I would refrain from doing that, carelessly changing `add`s to `lea`s may bring negative results in real-world situations since the latter is a little larger in size and lower in throughput. IMO the best solution would be emitting `lea` after the coalescing of an `add` or `shl` and its input fails (e.g when the `dst` operand is needed for other operations), resulting in a sequence `mov r1, r2; add r1, r3/imm` become `lea r1, [r2 + r3/imm]`. This happens after the register allocation phase and well after the matching phase. I perceive the peephole rules are more appropriate for this transformation but I'm still exploring this idea.

The latest change removes the redundant 0x67 prefix from `leal` since it reduces the size of the instruction and without `REX.W` prefix the destination register is 32-bit and according to the manual, the result is:

> 64-bit effective address is calculated (default address size) and the lower 32 bits of the address are stored in the requested 32-bit register destination.

which will produce the same result as before. The `prefix(src, dst)` is brought out for uniformity with other instructions, the function itself does not do anything on x86_32 (see assembler_x86.inline.hpp) so it is not a concern.

Thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From jiefu at openjdk.java.net  Fri Mar  4 08:27:02 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 4 Mar 2022 08:27:02 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v9]
In-Reply-To: <YWie-q2PBzr-dH4URicQfPoQeSCRqXs99dM9Bq_ErzM=.1e8392ec-258b-4d6b-ba38-c7146762f785@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <fP-WKU7L1MgZAWSlORClmC3w3_GM9Fe88FbB9hWjnVA=.3f23b274-3373-47f7-aab4-14ab6454f939@github.com>
 <YWie-q2PBzr-dH4URicQfPoQeSCRqXs99dM9Bq_ErzM=.1e8392ec-258b-4d6b-ba38-c7146762f785@github.com>
Message-ID: <XovchSCeKv3WEbm-1G4dfO_3PDxtBDq1PwWRxxnJm-U=.917e2a6a-ab80-4d0a-911e-477acb0110eb@github.com>

On Fri, 4 Mar 2022 06:59:02 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> I would refrain from doing that, carelessly changing `add`s to `lea`s may bring negative results in real-world situations since the latter is a little larger in size and lower in throughput. IMO the best solution would be emitting `lea` after the coalescing of an `add` or `shl` and its input fails (e.g when the `dst` operand is needed for other operations), resulting in a sequence `mov r1, r2; add r1, r3/imm` become `lea r1, [r2 + r3/imm]`. This happens after the register allocation phase and well after the matching phase. I perceive the peephole rules are more appropriate for this transformation but I'm still exploring this idea.

Sounds reasonable.
Shall we also remove `leaP_rReg_imm `?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Fri Mar  4 08:29:40 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 4 Mar 2022 08:29:40 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v10]
In-Reply-To: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
Message-ID: <cdQ7cLMPxxW0p-nK1DdHcQTrfouGC2kvXjSiDxHiMTw=.753e3892-e538-4890-a9f0-dd493d5fbf78@github.com>

> Hi,
> 
> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  remove unreached rules

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7560/files
  - new: https://git.openjdk.java.net/jdk/pull/7560/files/d171e82a..69a1afc9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=08-09

  Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7560/head:pull/7560

PR: https://git.openjdk.java.net/jdk/pull/7560

From jiefu at openjdk.java.net  Fri Mar  4 08:46:05 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 4 Mar 2022 08:46:05 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v9]
In-Reply-To: <YWie-q2PBzr-dH4URicQfPoQeSCRqXs99dM9Bq_ErzM=.1e8392ec-258b-4d6b-ba38-c7146762f785@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <fP-WKU7L1MgZAWSlORClmC3w3_GM9Fe88FbB9hWjnVA=.3f23b274-3373-47f7-aab4-14ab6454f939@github.com>
 <YWie-q2PBzr-dH4URicQfPoQeSCRqXs99dM9Bq_ErzM=.1e8392ec-258b-4d6b-ba38-c7146762f785@github.com>
Message-ID: <7SOZqELdGZpse5jZjxLdRKXivjjAB_jRrJOJnvMmpq0=.ff2a8ea0-7169-4105-84c1-3eb77c7709cd@github.com>

On Fri, 4 Mar 2022 06:59:02 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> The latest change removes the redundant 0x67 prefix from `leal` since it reduces the size of the instruction and without `REX.W` prefix the destination register is 32-bit and according to the manual, the result is:
> 
> > 64-bit effective address is calculated (default address size) and the lower 32 bits of the address are stored in the requested 32-bit register destination.
> 
> which will produce the same result as before. The `prefix(src, dst)` is brought out for uniformity with other instructions, the function itself does not do anything on x86_32 (see assembler_x86.inline.hpp) so it is not a concern.

Did you check cases like 32-bit calculation overflow?
Maybe add a jtreg test to verify the results? 
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Fri Mar  4 09:51:02 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 4 Mar 2022 09:51:02 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v9]
In-Reply-To: <XovchSCeKv3WEbm-1G4dfO_3PDxtBDq1PwWRxxnJm-U=.917e2a6a-ab80-4d0a-911e-477acb0110eb@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <fP-WKU7L1MgZAWSlORClmC3w3_GM9Fe88FbB9hWjnVA=.3f23b274-3373-47f7-aab4-14ab6454f939@github.com>
 <YWie-q2PBzr-dH4URicQfPoQeSCRqXs99dM9Bq_ErzM=.1e8392ec-258b-4d6b-ba38-c7146762f785@github.com>
 <XovchSCeKv3WEbm-1G4dfO_3PDxtBDq1PwWRxxnJm-U=.917e2a6a-ab80-4d0a-911e-477acb0110eb@github.com>
Message-ID: <UtR2cFYsBbHWNcyiP76JNJUUjd6yrvRjrlgrNb1OLms=.e450263e-bdff-4131-98e5-cafb86bca66e@github.com>

On Fri, 4 Mar 2022 08:23:21 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Shall we also remove `leaP_rReg_imm` ?

Done.

> Did you check cases like 32-bit calculation overflow?
> Maybe add a jtreg test to verify the results?

According to Intel manual, volume 1, section 3.3.7:

> All 16-bit and 32-bit address calculations are zero-extended in IA-32e mode to form 64-bit addresses. Address calculations are first truncated to the effective address size of the current mode (64-bit mode or compatibility mode), as overridden by any address-size prefix. The result is then zero-extended to the full 64-bit address width.

It is trivial that truncation to 32 bit and zero extension from 32 bit keep the lower 32 bits untouched. Also, the lower 32 bits of integral additions and multiplications only depends on the lower 32 bits of the operands. As a result, calculations with 32-bit address, 32-bit operand give the same result as those with 64-bit address, 32-bit operand since the lower 32 bits are similar and the upper 32 bits are all zero. Also, looking at the generated code for (using `unsigned int` because overflow cause wrapping, similar to Java calculations)

    unsigned int test(unsigned int x, unsigned int y) {
        return x + y * 4 + 100;
    }

GCC conveniently output [`leal    0x64(%rdi,%rsi,4), %eax`](https://godbolt.org/z/M6o7zjoe3) with 64-bit address (without 0x67 prefix). So, we can be confident that we don't make a mistake here.

Thanks a lot.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From jiefu at openjdk.java.net  Fri Mar  4 11:56:03 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 4 Mar 2022 11:56:03 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v10]
In-Reply-To: <cdQ7cLMPxxW0p-nK1DdHcQTrfouGC2kvXjSiDxHiMTw=.753e3892-e538-4890-a9f0-dd493d5fbf78@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <cdQ7cLMPxxW0p-nK1DdHcQTrfouGC2kvXjSiDxHiMTw=.753e3892-e538-4890-a9f0-dd493d5fbf78@github.com>
Message-ID: <mtrkDxqFB9u7UQT6oNPWuSAVoJ3Nb8Im4MQeUUyGwNU=.c1b0ec86-2179-4724-aab4-6f20116b8b7c@github.com>

On Fri, 4 Mar 2022 08:29:40 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unreached rules

Looks good to me assuming that change in `Assembler::leal` is correct.
(I didn't do a double check of the change in `Assembler::leal` encoding.)

-------------

Marked as reviewed by jiefu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7560

From tanksherman27 at gmail.com  Fri Mar  4 12:21:21 2022
From: tanksherman27 at gmail.com (Julian Waters)
Date: Fri, 4 Mar 2022 20:21:21 +0800
Subject: On JDK-8281518
Message-ID: <CAP2b4GPLHFR_kRM_QXCM-bcccuD8PXkpxneOQHkRZNFVJbH16g@mail.gmail.com>

>From the discussion on JDK-8281518:
"What *would* get us benefit in a cost-effective way would be to take
this optimization and several previous ones (and future ones) and
refactor them into a single comprehensive analysis based on truth
tables, which would normalize bitwise expressions up to some particular
complexity (say, up to three input variables and up to depth 2, with
variety of operators). This is a minor research project, but (I think)
a worthy one."

Out of curiosity, do we have an exhaustive list of related optimizations
prior to this one already included in C2?

best regards,
Julian

From duke at openjdk.java.net  Fri Mar  4 12:50:05 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Fri, 4 Mar 2022 12:50:05 GMT
Subject: RFR: 8282573: ByteBufferTest.java: replace endless recursion with
 RuntimeException in void ck(double x, double y) [v2]
In-Reply-To: <MTp_OZ2rBZ9vFWa-P7GixJ7mh8m_B0SYKGHCJpdniZY=.9413f608-6cee-412a-9437-3e29cf74372a@github.com>
References: <IbrYwGg0FHZuJc435zaAxXm6CDdBwckmLvet474j1sc=.08398081-1f2c-4285-809e-8c087c89e99c@github.com>
 <jKDHPJNztE9gunzBixqIE0lCT_5LdGDzGmGaVxePL8Q=.df0641e9-9fe6-4697-911a-fa65305bb70d@github.com>
 <MTp_OZ2rBZ9vFWa-P7GixJ7mh8m_B0SYKGHCJpdniZY=.9413f608-6cee-412a-9437-3e29cf74372a@github.com>
Message-ID: <OPHjvRM8l1KGvXekOwXMZFZrygPcTqY8XM87V2IVD5M=.49ee6acb-2838-4cd0-b2ad-a0b09dca75f0@github.com>

On Thu, 3 Mar 2022 17:55:00 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed unnecessary conditions
>
> Marked as reviewed by psandoz (Reviewer).

Thanks @PaulSandoz and @TobiHartmann  for the help and the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7674

From duke at openjdk.java.net  Fri Mar  4 12:59:03 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Fri, 4 Mar 2022 12:59:03 GMT
Subject: Integrated: 8282573: ByteBufferTest.java: replace endless recursion
 with RuntimeException in void ck(double x, double y)
In-Reply-To: <IbrYwGg0FHZuJc435zaAxXm6CDdBwckmLvet474j1sc=.08398081-1f2c-4285-809e-8c087c89e99c@github.com>
References: <IbrYwGg0FHZuJc435zaAxXm6CDdBwckmLvet474j1sc=.08398081-1f2c-4285-809e-8c087c89e99c@github.com>
Message-ID: <-CkqAXqLpFWwYWmwhs6HKdH2IKaLSYehQPHeLFDSQ7c=.9fb58c4a-09fd-400a-964e-f60f6e5f881f@github.com>

On Thu, 3 Mar 2022 11:24:04 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> There are two functions that check for equality.
> void ck(long x, long y): already throws a RuntimeException if we observe inequality
> void ck(double x, double y): called itself, leading to endless recursion and a StackOverflowError.
> 
> Instead of the recursion, I now also throw a RuntimeException.
> 
> This can currently be triggered with
> `path-to-jtreg/jtreg -va -s -jdk:jdk-path -javaoptions:"-XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressGCM -XX:+OptoScheduling -XX:StressSeed=293843391" test/hotspot/jtreg/compiler/intrinsics/unsafe/HeapByteBufferTest.java `
> (see bug [JDK-8282555](https://bugs.openjdk.java.net/browse/JDK-8282555))
> 
> This way I could verify that instead of StackOverflowError we now get RuntimeException, as desired.
> Ran some basic tests to ensure I didn't break things.

This pull request has now been integrated.

Changeset: a584c904
Author:    Emanuel Peter <emanuel.peter at oracle.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a584c904a9e386d7ce80fb9cc6d49fece065d3da
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8282573: ByteBufferTest.java: replace endless recursion with RuntimeException in void ck(double x, double y)

Reviewed-by: psandoz, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7674

From jiefu at openjdk.java.net  Fri Mar  4 14:25:11 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 4 Mar 2022 14:25:11 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v10]
In-Reply-To: <cdQ7cLMPxxW0p-nK1DdHcQTrfouGC2kvXjSiDxHiMTw=.753e3892-e538-4890-a9f0-dd493d5fbf78@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <cdQ7cLMPxxW0p-nK1DdHcQTrfouGC2kvXjSiDxHiMTw=.753e3892-e538-4890-a9f0-dd493d5fbf78@github.com>
Message-ID: <150qK-2EDzRnISU8yLqFBYgeEVEcrjajQRKQrR3PeLs=.801f4add-c396-465c-9282-196aefa06e31@github.com>

On Fri, 4 Mar 2022 08:29:40 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unreached rules

src/hotspot/cpu/x86/x86_64.ad line 7747:

> 7745: %}
> 7746: 
> 7747: // XXX addP mem ops ????

This comment line is for leaP_rReg_imm, which should also be removed?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Fri Mar  4 14:34:08 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 4 Mar 2022 14:34:08 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v10]
In-Reply-To: <150qK-2EDzRnISU8yLqFBYgeEVEcrjajQRKQrR3PeLs=.801f4add-c396-465c-9282-196aefa06e31@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <cdQ7cLMPxxW0p-nK1DdHcQTrfouGC2kvXjSiDxHiMTw=.753e3892-e538-4890-a9f0-dd493d5fbf78@github.com>
 <150qK-2EDzRnISU8yLqFBYgeEVEcrjajQRKQrR3PeLs=.801f4add-c396-465c-9282-196aefa06e31@github.com>
Message-ID: <tgWJ91Ms0ZYEjqvcV26YCI-oUjgAXyEnab1f0r_WQjs=.55c02165-2205-4ac7-a61b-f7b8a7bfa7cf@github.com>

On Fri, 4 Mar 2022 14:21:42 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unreached rules
>
> src/hotspot/cpu/x86/x86_64.ad line 7747:
> 
>> 7745: %}
>> 7746: 
>> 7747: // XXX addP mem ops ????
> 
> This comment line is for leaP_rReg_imm, which should also be removed?

I believe it is for the missing rules of `AddP` with memory operands such as `addP_mem_rReg`

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Fri Mar  4 15:23:36 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Fri, 4 Mar 2022 15:23:36 GMT
Subject: RFR: 8282661: 2 compiler/intrinsics/unsafe/*ByteBufferTest.java tests
 fail after JDK-8282573
Message-ID: <z6QYgOckhWfuN1r7n-X0RWT27lXQq633E-KG6FnYDjU=.c6c6bb00-700a-4040-b7e7-97699abfd6c6@github.com>

Running tests now...

-------------

Commit messages:
 - 8282661: 2 compiler/intrinsics/unsafe/*ByteBufferTest.java tests fail after JDK-8282573

Changes: https://git.openjdk.java.net/jdk/pull/7699/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7699&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282661
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7699/head:pull/7699

PR: https://git.openjdk.java.net/jdk/pull/7699

From dcubed at openjdk.java.net  Fri Mar  4 15:33:06 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 4 Mar 2022 15:33:06 GMT
Subject: RFR: 8282573: ByteBufferTest.java: replace endless recursion with
 RuntimeException in void ck(double x, double y) [v2]
In-Reply-To: <jKDHPJNztE9gunzBixqIE0lCT_5LdGDzGmGaVxePL8Q=.df0641e9-9fe6-4697-911a-fa65305bb70d@github.com>
References: <IbrYwGg0FHZuJc435zaAxXm6CDdBwckmLvet474j1sc=.08398081-1f2c-4285-809e-8c087c89e99c@github.com>
 <jKDHPJNztE9gunzBixqIE0lCT_5LdGDzGmGaVxePL8Q=.df0641e9-9fe6-4697-911a-fa65305bb70d@github.com>
Message-ID: <WEX012n4xp-MrP43bJgpZaPSCbWEzueVjAqpLM2hJ5M=.1d7e7e7d-52e4-4d9d-8854-493e241a6c76@github.com>

On Thu, 3 Mar 2022 16:26:41 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> There are two functions that check for equality.
>> void ck(long x, long y): already throws a RuntimeException if we observe inequality
>> void ck(double x, double y): called itself, leading to endless recursion and a StackOverflowError.
>> 
>> Instead of the recursion, I now also throw a RuntimeException.
>> 
>> This can currently be triggered with
>> `path-to-jtreg/jtreg -va -s -jdk:jdk-path -javaoptions:"-XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressGCM -XX:+OptoScheduling -XX:StressSeed=293843391" test/hotspot/jtreg/compiler/intrinsics/unsafe/HeapByteBufferTest.java `
>> (see bug [JDK-8282555](https://bugs.openjdk.java.net/browse/JDK-8282555))
>> 
>> This way I could verify that instead of StackOverflowError we now get RuntimeException, as desired.
>> Ran some basic tests to ensure I didn't break things.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unnecessary conditions

test/hotspot/jtreg/compiler/intrinsics/unsafe/ByteBufferTest.java line 220:

> 218:     void ck(double x, double y) {
> 219:         if (x != y) {
> 220:             throw new RuntimeException(" x = " + Double.toString(x) + ", y = " + Double.toString(y)

You might want to add some explanation to the exception:
s/" x = "/"Expected x == y: x = "

or something like that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7674

From dcubed at openjdk.java.net  Fri Mar  4 15:54:05 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 4 Mar 2022 15:54:05 GMT
Subject: RFR: 8282661: 2 compiler/intrinsics/unsafe/*ByteBufferTest.java
 tests fail after JDK-8282573
In-Reply-To: <z6QYgOckhWfuN1r7n-X0RWT27lXQq633E-KG6FnYDjU=.c6c6bb00-700a-4040-b7e7-97699abfd6c6@github.com>
References: <z6QYgOckhWfuN1r7n-X0RWT27lXQq633E-KG6FnYDjU=.c6c6bb00-700a-4040-b7e7-97699abfd6c6@github.com>
Message-ID: <okBkjrvwpAwlkmnqVJR8vGAO1EXdeWj7i1nv3GeGtkU=.60856a8b-fbc6-444e-9546-9bdc806c702d@github.com>

On Fri, 4 Mar 2022 15:17:17 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> According to IEEE, any comparison with a NaN is false. Thus NaN =! NaN  is always true.
> To guard against this case, we also have the `x == x && y == y` case.

Changes requested by dcubed (Reviewer).

test/hotspot/jtreg/compiler/intrinsics/unsafe/ByteBufferTest.java line 219:

> 217: 
> 218:     void ck(double x, double y) {
> 219:         if (x == x && y == y && x != y) {

This line of logic is begging for a comment of some sort.
Especially to keep someone from coming along later and "optimizing" it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7699

From chagedorn at openjdk.java.net  Fri Mar  4 16:29:42 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 4 Mar 2022 16:29:42 GMT
Subject: RFR: 8282661: [BACKOUT] ByteBufferTest.java: replace endless
 recursion with RuntimeException in void ck(double x, double y) [v2]
In-Reply-To: <TJHvSayVf9iNjP-iDwC954H-lIzE486u46DMyYiX5qI=.39cd13c8-ae0f-4d4c-92b5-192cb985b915@github.com>
References: <z6QYgOckhWfuN1r7n-X0RWT27lXQq633E-KG6FnYDjU=.c6c6bb00-700a-4040-b7e7-97699abfd6c6@github.com>
 <TJHvSayVf9iNjP-iDwC954H-lIzE486u46DMyYiX5qI=.39cd13c8-ae0f-4d4c-92b5-192cb985b915@github.com>
Message-ID: <CWBjSFnHq_L3j53b2SGySTjeUJnK615JxwRw1LUSTQE=.fb17fb80-f684-4f37-bf18-98ced5062f7b@github.com>

On Fri, 4 Mar 2022 16:26:41 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> Backout [JDK-8282573](https://bugs.openjdk.java.net/browse/JDK-8282573).
>> The new fix lead to many tests failing.
>> And a new fix needs a little bit of thinking and testing.
>
> Emanuel Peter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "8282573: ByteBufferTest.java: replace endless recursion with RuntimeException in void ck(double x, double y)"
>    
>    This reverts commit a584c904a9e386d7ce80fb9cc6d49fece065d3da.
>  - Revert "8282661: 2 compiler/intrinsics/unsafe/*ByteBufferTest.java tests fail after JDK-8282573"
>    
>    This reverts commit 684e7b3f55d8f109eb096b1294600fa9fa8fbfbd.

Looks good and trivial.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7699

From duke at openjdk.java.net  Fri Mar  4 16:29:44 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Fri, 4 Mar 2022 16:29:44 GMT
Subject: RFR: 8282661: [BACKOUT] ByteBufferTest.java: replace endless
 recursion with RuntimeException in void ck(double x, double y)
In-Reply-To: <z6QYgOckhWfuN1r7n-X0RWT27lXQq633E-KG6FnYDjU=.c6c6bb00-700a-4040-b7e7-97699abfd6c6@github.com>
References: <z6QYgOckhWfuN1r7n-X0RWT27lXQq633E-KG6FnYDjU=.c6c6bb00-700a-4040-b7e7-97699abfd6c6@github.com>
Message-ID: <fxaDYRe2voSAh2aMkK9uhTNne1V5KQTn9R-ETzupAn4=.bad84577-0bad-4ca1-8f84-0e793c6382f3@github.com>

On Fri, 4 Mar 2022 15:17:17 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> Backout [JDK-8282573](https://bugs.openjdk.java.net/browse/JDK-8282573).
> The new fix lead to many tests failing.
> And a new fix needs a little bit of thinking and testing.

Sorry for the trainwreck.
Thanks @PaulSandoz @chhagedorn @dcubed-ojdk for the help and the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7699

From duke at openjdk.java.net  Fri Mar  4 16:29:31 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 4 Mar 2022 16:29:31 GMT
Subject: RFR: 8282509: [AIX] ResolvedTestClass fails on AIX with similar output
Message-ID: <5eb3C_3MU09ZBJSPs9ER4fM8u89e7T814CDtRDIdqAY=.04acec75-b1ca-44be-8bb2-140a51ca0a2b@github.com>

This is a tentative solution to a failure observed on AIX. The solution is tentative because I require help to ensure that something deeper and more problematic is not happening.

The test fails because the output produced by PrintCompilation produces `LambdaForm$MH/0x00000007c0002400` instead of `Invokers$Holder` as it does on other platforms. There is one other place the output is different, when `DirectMethodHandle$Holder` is replaced with `LambdaForm$DMH/0x00000007c0001c00`. Ignoring these name changes, the output of PrintCompilation is identical. I observe the same compilations (including the OSR/non-OSR, and same level) in the same order.

I would be grateful for help understanding the root of the difference behind the change. I have a few ideas, but I will let you build your own interpretations free from my potentially incorrect understanding (i.e. no spoilers). Thanks in advance.

-------------

Commit messages:
 - Trial Solution: Replaces shouldContain with shouldMatch + Regex in ResolvedClassTest

Changes: https://git.openjdk.java.net/jdk/pull/7701/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7701&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282509
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7701.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7701/head:pull/7701

PR: https://git.openjdk.java.net/jdk/pull/7701

From duke at openjdk.java.net  Fri Mar  4 16:29:32 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 4 Mar 2022 16:29:32 GMT
Subject: RFR: 8282509: [AIX] ResolvedTestClass fails on AIX with similar
 output
In-Reply-To: <5eb3C_3MU09ZBJSPs9ER4fM8u89e7T814CDtRDIdqAY=.04acec75-b1ca-44be-8bb2-140a51ca0a2b@github.com>
References: <5eb3C_3MU09ZBJSPs9ER4fM8u89e7T814CDtRDIdqAY=.04acec75-b1ca-44be-8bb2-140a51ca0a2b@github.com>
Message-ID: <vnZrvGMFTS0GSqJWMIH_BqWg9B6r6_kEA2UZlHnpj6Y=.ed997c84-c5ab-4208-8219-b5f89175d75c@github.com>

On Fri, 4 Mar 2022 16:22:47 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> This is a tentative solution to a failure observed on AIX. The solution is tentative because I require help to ensure that something deeper and more problematic is not happening.
> 
> The test fails because the output produced by PrintCompilation produces `LambdaForm$MH/0x00000007c0002400` instead of `Invokers$Holder` as it does on other platforms. There is one other place the output is different, when `DirectMethodHandle$Holder` is replaced with `LambdaForm$DMH/0x00000007c0001c00`. Ignoring these name changes, the output of PrintCompilation is identical. I observe the same compilations (including the OSR/non-OSR, and same level) in the same order.
> 
> I would be grateful for help understanding the root of the difference behind the change. I have a few ideas, but I will let you build your own interpretations free from my potentially incorrect understanding (i.e. no spoilers). Thanks in advance.

Dean Long mentioned on the issue that they were able to reproduce the issue with an exploded image. I don't have access to JBS (yet!) to comment there directly, so I'll mention here that I am building with make images, and not the default target.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7701

From duke at openjdk.java.net  Fri Mar  4 16:29:41 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Fri, 4 Mar 2022 16:29:41 GMT
Subject: RFR: 8282661: [BACKOUT] ByteBufferTest.java: replace endless
 recursion with RuntimeException in void ck(double x, double y) [v2]
In-Reply-To: <z6QYgOckhWfuN1r7n-X0RWT27lXQq633E-KG6FnYDjU=.c6c6bb00-700a-4040-b7e7-97699abfd6c6@github.com>
References: <z6QYgOckhWfuN1r7n-X0RWT27lXQq633E-KG6FnYDjU=.c6c6bb00-700a-4040-b7e7-97699abfd6c6@github.com>
Message-ID: <TJHvSayVf9iNjP-iDwC954H-lIzE486u46DMyYiX5qI=.39cd13c8-ae0f-4d4c-92b5-192cb985b915@github.com>

> Backout [JDK-8282573](https://bugs.openjdk.java.net/browse/JDK-8282573).
> The new fix lead to many tests failing.
> And a new fix needs a little bit of thinking and testing.

Emanuel Peter has updated the pull request incrementally with two additional commits since the last revision:

 - Revert "8282573: ByteBufferTest.java: replace endless recursion with RuntimeException in void ck(double x, double y)"
   
   This reverts commit a584c904a9e386d7ce80fb9cc6d49fece065d3da.
 - Revert "8282661: 2 compiler/intrinsics/unsafe/*ByteBufferTest.java tests fail after JDK-8282573"
   
   This reverts commit 684e7b3f55d8f109eb096b1294600fa9fa8fbfbd.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7699/files
  - new: https://git.openjdk.java.net/jdk/pull/7699/files/684e7b3f..cfc0d07e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7699&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7699&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7699.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7699/head:pull/7699

PR: https://git.openjdk.java.net/jdk/pull/7699

From psandoz at openjdk.java.net  Fri Mar  4 16:29:43 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 4 Mar 2022 16:29:43 GMT
Subject: RFR: 8282661: [BACKOUT] ByteBufferTest.java: replace endless
 recursion with RuntimeException in void ck(double x, double y) [v2]
In-Reply-To: <TJHvSayVf9iNjP-iDwC954H-lIzE486u46DMyYiX5qI=.39cd13c8-ae0f-4d4c-92b5-192cb985b915@github.com>
References: <z6QYgOckhWfuN1r7n-X0RWT27lXQq633E-KG6FnYDjU=.c6c6bb00-700a-4040-b7e7-97699abfd6c6@github.com>
 <TJHvSayVf9iNjP-iDwC954H-lIzE486u46DMyYiX5qI=.39cd13c8-ae0f-4d4c-92b5-192cb985b915@github.com>
Message-ID: <JCp1YkfZj8f5x5QdYmPTJaqA43rfLhKvfHGkbVpralE=.2f40c14d-c16c-4b48-9666-aa588aedeaf6@github.com>

On Fri, 4 Mar 2022 16:26:41 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> Backout [JDK-8282573](https://bugs.openjdk.java.net/browse/JDK-8282573).
>> The new fix lead to many tests failing.
>> And a new fix needs a little bit of thinking and testing.
>
> Emanuel Peter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert "8282573: ByteBufferTest.java: replace endless recursion with RuntimeException in void ck(double x, double y)"
>    
>    This reverts commit a584c904a9e386d7ce80fb9cc6d49fece065d3da.
>  - Revert "8282661: 2 compiler/intrinsics/unsafe/*ByteBufferTest.java tests fail after JDK-8282573"
>    
>    This reverts commit 684e7b3f55d8f109eb096b1294600fa9fa8fbfbd.

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7699

From duke at openjdk.java.net  Fri Mar  4 16:29:45 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Fri, 4 Mar 2022 16:29:45 GMT
Subject: Integrated: 8282661: [BACKOUT] ByteBufferTest.java: replace endless
 recursion with RuntimeException in void ck(double x, double y)
In-Reply-To: <z6QYgOckhWfuN1r7n-X0RWT27lXQq633E-KG6FnYDjU=.c6c6bb00-700a-4040-b7e7-97699abfd6c6@github.com>
References: <z6QYgOckhWfuN1r7n-X0RWT27lXQq633E-KG6FnYDjU=.c6c6bb00-700a-4040-b7e7-97699abfd6c6@github.com>
Message-ID: <vcKab2zUJdbzEz_z_npM7l3U9gYxJqQdIwx7Wpayec0=.328b39b5-fde5-44b4-a299-5b9db9587967@github.com>

On Fri, 4 Mar 2022 15:17:17 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> Backout [JDK-8282573](https://bugs.openjdk.java.net/browse/JDK-8282573).
> The new fix lead to many tests failing.
> And a new fix needs a little bit of thinking and testing.

This pull request has now been integrated.

Changeset: 603050bf
Author:    Emanuel Peter <emanuel.peter at oracle.com>
Committer: Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/603050bfe00d7a0185d84acab2a24a803aa86f82
Stats:     4 lines in 1 file changed: 0 ins; 2 del; 2 mod

8282661: [BACKOUT] ByteBufferTest.java: replace endless recursion with RuntimeException in void ck(double x, double y)

Reviewed-by: chagedorn, psandoz

-------------

PR: https://git.openjdk.java.net/jdk/pull/7699

From duke at openjdk.java.net  Fri Mar  4 16:33:55 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Fri, 4 Mar 2022 16:33:55 GMT
Subject: RFR: 8282509: [AIX] ResolvedTestClass fails on AIX with similar
 output [v2]
In-Reply-To: <5eb3C_3MU09ZBJSPs9ER4fM8u89e7T814CDtRDIdqAY=.04acec75-b1ca-44be-8bb2-140a51ca0a2b@github.com>
References: <5eb3C_3MU09ZBJSPs9ER4fM8u89e7T814CDtRDIdqAY=.04acec75-b1ca-44be-8bb2-140a51ca0a2b@github.com>
Message-ID: <zwLI-pEBRA-2k3gkdRN_AqsWZuGq2_YZ7qCiBBXinMM=.17635149-86d9-4408-9611-b22ffa1b8f4e@github.com>

> This is a tentative solution to a failure observed on AIX. The solution is tentative because I require help to ensure that something deeper and more problematic is not happening.
> 
> The test fails because the output produced by PrintCompilation produces `LambdaForm$MH/0x00000007c0002400` instead of `Invokers$Holder` as it does on other platforms. There is one other place the output is different, when `DirectMethodHandle$Holder` is replaced with `LambdaForm$DMH/0x00000007c0001c00`. Ignoring these name changes, the output of PrintCompilation is identical. I observe the same compilations (including the OSR/non-OSR, and same level) in the same order.
> 
> I would be grateful for help understanding the root of the difference behind the change. I have a few ideas, but I will let you build your own interpretations free from my potentially incorrect understanding (i.e. no spoilers). Thanks in advance.

Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:

  Remove leading chars not present in original test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7701/files
  - new: https://git.openjdk.java.net/jdk/pull/7701/files/8e77ff1b..4149b86c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7701&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7701&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7701.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7701/head:pull/7701

PR: https://git.openjdk.java.net/jdk/pull/7701

From duke at openjdk.java.net  Fri Mar  4 16:47:06 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 4 Mar 2022 16:47:06 GMT
Subject: RFR: 8282661: [BACKOUT] ByteBufferTest.java: replace endless
 recursion with RuntimeException in void ck(double x, double y) [v2]
In-Reply-To: <okBkjrvwpAwlkmnqVJR8vGAO1EXdeWj7i1nv3GeGtkU=.60856a8b-fbc6-444e-9546-9bdc806c702d@github.com>
References: <z6QYgOckhWfuN1r7n-X0RWT27lXQq633E-KG6FnYDjU=.c6c6bb00-700a-4040-b7e7-97699abfd6c6@github.com>
 <okBkjrvwpAwlkmnqVJR8vGAO1EXdeWj7i1nv3GeGtkU=.60856a8b-fbc6-444e-9546-9bdc806c702d@github.com>
Message-ID: <0DKraI5TbBEgriZ-99f6oHwG2rCAE26y54dC7NmRUQY=.a8fa3c30-9708-47e9-a078-98170ae2cb62@github.com>

On Fri, 4 Mar 2022 15:50:45 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert "8282573: ByteBufferTest.java: replace endless recursion with RuntimeException in void ck(double x, double y)"
>>    
>>    This reverts commit a584c904a9e386d7ce80fb9cc6d49fece065d3da.
>>  - Revert "8282661: 2 compiler/intrinsics/unsafe/*ByteBufferTest.java tests fail after JDK-8282573"
>>    
>>    This reverts commit 684e7b3f55d8f109eb096b1294600fa9fa8fbfbd.
>
> test/hotspot/jtreg/compiler/intrinsics/unsafe/ByteBufferTest.java line 219:
> 
>> 217: 
>> 218:     void ck(double x, double y) {
>> 219:         if (x == x && y == y && x != y) {
> 
> This line of logic is begging for a comment of some sort.
> Especially to keep someone from coming along later and "optimizing" it.

I suggest using `Double::isNan` instead of `x == x`

-------------

PR: https://git.openjdk.java.net/jdk/pull/7699

From jbhateja at openjdk.java.net  Fri Mar  4 19:08:09 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 4 Mar 2022 19:08:09 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v9]
In-Reply-To: <HnLSn9vdNL5YBqaQXPS9QNzFF6CM37GzX1cF-HUVq7Y=.6e99b156-1b77-44e4-9b73-e7e389ab6ff8@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>
 <C8UrQ5i-1DBVeT7O3uFmyLkGTCmHLcRVkyupDPocqeg=.d7ecc45f-e9f2-4ab9-9d4f-8c084f0d1a6a@github.com>
 <HnLSn9vdNL5YBqaQXPS9QNzFF6CM37GzX1cF-HUVq7Y=.6e99b156-1b77-44e4-9b73-e7e389ab6ff8@github.com>
Message-ID: <2jFjnftd7VluGsxgp8BK0vgHA68VrgGREj0fk7F6Dhk=.e40ddcaa-5a31-4115-976d-5f43e94b8ccf@github.com>

On Fri, 4 Mar 2022 06:06:52 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> test/jdk/java/lang/Math/RoundTests.java line 32:
>> 
>>> 30:     public static void main(String... args) {
>>> 31:         int failures = 0;
>>> 32:         for (int i = 0; i < 100000; i++) {
>> 
>> Is there an idiom to trigger the auto-vectorization, perhaps using command line arguments, that doesn't bloat the running time of this test?
>
> IMO RoundTests should have a explicit @run tag without any VM options as well.
> 
> Do the added VM options run on all platforms in question? What is the approximate time to run the test run compared to before?

Hi @jddarcy , 

Test has been modified on the same lines using generic options which manipulate compilation thresholds and agnostic to target platforms.

 * @run main/othervm -XX:Tier3CompileThreshold=100 -XX:CompileThresholdScaling=0.01 -XX:+TieredCompilation RoundTests

Verified that  RoundTests::test* methods gets compiled by c2.
Test execution time with and without change is almost same ~7.80sec over Skylake-server.

Regards

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From jbhateja at openjdk.java.net  Fri Mar  4 20:27:36 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 4 Mar 2022 20:27:36 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v8]
In-Reply-To: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
Message-ID: <vxDwpCRmu3HvXKL8NegsH_wBHLEkJzAFosN5WMyCx0g=.0a147a58-ebe3-42e7-b15e-22b7d6e45e4d@github.com>

> Summary of changes:
> 
> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
> 
> 
> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8281375: Review comments resolved.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7373/files
  - new: https://git.openjdk.java.net/jdk/pull/7373/files/1cdd068e..c54d962e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7373&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7373&range=06-07

  Stats: 73 lines in 4 files changed: 4 ins; 56 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7373.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7373/head:pull/7373

PR: https://git.openjdk.java.net/jdk/pull/7373

From kvn at openjdk.java.net  Sat Mar  5 00:02:03 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 5 Mar 2022 00:02:03 GMT
Subject: RFR: 8282142: [TestCase] compiler/inlining/ResolvedClassTest.java
 will fail when --with-jvm-features=-compiler1 [v3]
In-Reply-To: <phRjfJY6VUbEvFyfq5tO69cySrr1yCXwyvIgwvGT684=.676eaac4-3715-428e-8e2e-a191204d739a@github.com>
References: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
 <phRjfJY6VUbEvFyfq5tO69cySrr1yCXwyvIgwvGT684=.676eaac4-3715-428e-8e2e-a191204d739a@github.com>
Message-ID: <FIut1g6gL1xkkcNfFgiTC6eTG8i6nfakLl-ZfVV2mog=.ce68d47e-f67d-4cdb-8582-608eb59fea11@github.com>

On Mon, 28 Feb 2022 06:45:17 GMT, Haomin <duke at openjdk.java.net> wrote:

>> ?l when --with-jvm-features=-compiler1
>
> Haomin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282142: [TestCase] compiler/inlining/ResolvedClassTest.java will fail when --with-jvm-features=-compiler1

Okay.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7541

From duke at openjdk.java.net  Sat Mar  5 00:06:03 2022
From: duke at openjdk.java.net (Haomin)
Date: Sat, 5 Mar 2022 00:06:03 GMT
Subject: Integrated: 8282142: [TestCase]
 compiler/inlining/ResolvedClassTest.java will fail when
 --with-jvm-features=-compiler1
In-Reply-To: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
References: <n60leU8Bc5KNZq7qCCsl9tmu8-NTqwcGg0a1ClaYjRk=.58c7b7c3-c4f6-4ffa-8e9b-0d3afe1db54f@github.com>
Message-ID: <K7RKMw5jQ4LjHWkN_6UBzGZr739JvP1IkpIefpebpGA=.fc18f84f-7278-4002-95fd-3026880bf65d@github.com>

On Sat, 19 Feb 2022 03:49:58 GMT, Haomin <duke at openjdk.java.net> wrote:

> ?l when --with-jvm-features=-compiler1

This pull request has now been integrated.

Changeset: c459f8f4
Author:    wanghaomin <wanghaomin at loongson.cn>
Committer: Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c459f8f406a99cf78814bb5722f546ae1cdb6c6f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8282142: [TestCase] compiler/inlining/ResolvedClassTest.java will fail when --with-jvm-features=-compiler1

Reviewed-by: jiefu, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7541

From sviswanathan at openjdk.java.net  Sat Mar  5 00:58:06 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 5 Mar 2022 00:58:06 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v8]
In-Reply-To: <vxDwpCRmu3HvXKL8NegsH_wBHLEkJzAFosN5WMyCx0g=.0a147a58-ebe3-42e7-b15e-22b7d6e45e4d@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <vxDwpCRmu3HvXKL8NegsH_wBHLEkJzAFosN5WMyCx0g=.0a147a58-ebe3-42e7-b15e-22b7d6e45e4d@github.com>
Message-ID: <pfnYbqghKyAivd6P-YLL3TQfhD3XwPRuQRolcUiXmJk=.bc74dc40-b061-49fc-96f7-16545e101e37@github.com>

On Fri, 4 Mar 2022 20:27:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> 
>> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
>> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
>> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
>> 
>> 
>> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
>> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
>> 
>> Please review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8281375: Review comments resolved.

Marked as reviewed by sviswanathan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From sviswanathan at openjdk.java.net  Sat Mar  5 00:58:07 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 5 Mar 2022 00:58:07 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v7]
In-Reply-To: <LG_V6wVTd4UF_U2p8sa6ipe8v6UwiFi07GbG7dIi6jI=.a50902fc-0eea-4136-a77b-c717e6a3b329@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <kATPxslgFX2I4XTxlzpbOHK_4toQrppMxrtKFaIbgJI=.c098b898-89cd-4c29-9422-177450f1c399@github.com>
 <LG_V6wVTd4UF_U2p8sa6ipe8v6UwiFi07GbG7dIi6jI=.a50902fc-0eea-4136-a77b-c717e6a3b329@github.com>
Message-ID: <4XFyr694xjEc7sBptBgSWUGVI0WkG80has3tBxY5Rmw=.1c153717-09e0-4287-82fb-e78ac3d512fa@github.com>

On Thu, 3 Mar 2022 05:42:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8281375: Review comments resolved.
>
> Hi @sviswa7 , your comments have been addressed.

@jatin-bhateja  The patch looks good to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From psandoz at openjdk.java.net  Sat Mar  5 01:40:07 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Sat, 5 Mar 2022 01:40:07 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v8]
In-Reply-To: <vxDwpCRmu3HvXKL8NegsH_wBHLEkJzAFosN5WMyCx0g=.0a147a58-ebe3-42e7-b15e-22b7d6e45e4d@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <vxDwpCRmu3HvXKL8NegsH_wBHLEkJzAFosN5WMyCx0g=.0a147a58-ebe3-42e7-b15e-22b7d6e45e4d@github.com>
Message-ID: <cVhIOj0CTZJEjriVpyJfnaNT1LYWL88gK8b1_0XS3Nc=.55ef669b-17e2-40f7-9bb3-c5e5585fa4a1@github.com>

On Fri, 4 Mar 2022 20:27:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> 
>> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
>> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
>> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
>> 
>> 
>> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
>> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
>> 
>> Please review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8281375: Review comments resolved.

Running some tests.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From sviswanathan at openjdk.java.net  Sat Mar  5 01:40:07 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 5 Mar 2022 01:40:07 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v8]
In-Reply-To: <cVhIOj0CTZJEjriVpyJfnaNT1LYWL88gK8b1_0XS3Nc=.55ef669b-17e2-40f7-9bb3-c5e5585fa4a1@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <vxDwpCRmu3HvXKL8NegsH_wBHLEkJzAFosN5WMyCx0g=.0a147a58-ebe3-42e7-b15e-22b7d6e45e4d@github.com>
 <cVhIOj0CTZJEjriVpyJfnaNT1LYWL88gK8b1_0XS3Nc=.55ef669b-17e2-40f7-9bb3-c5e5585fa4a1@github.com>
Message-ID: <GBgMz_CtVHtvCfEtiIq65Qz9Koa5jNequJg3eIQ6wNU=.2cccb627-281d-4a34-b9dc-219bfee736a9@github.com>

On Sat, 5 Mar 2022 01:36:09 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8281375: Review comments resolved.
>
> Running some tests.

Thanks a lot @PaulSandoz.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From aph at openjdk.java.net  Sun Mar  6 09:35:08 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Sun, 6 Mar 2022 09:35:08 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v11]
In-Reply-To: <pISqYd60ZBAUKka4b7I1ADwLxQaDQigDYRyWvD6-buY=.6d7a7ab1-7a10-4e62-9f60-9f82dcefadd2@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <pISqYd60ZBAUKka4b7I1ADwLxQaDQigDYRyWvD6-buY=.6d7a7ab1-7a10-4e62-9f60-9f82dcefadd2@github.com>
Message-ID: <JZRQE05iyBsB3obYWVPHU8tJp2PxhCtCUb0d-wlv5rE=.ae7a4288-4bc7-4ab2-b427-7a41cd8f37a0@github.com>

On Wed, 2 Mar 2022 02:44:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
>> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279508: Removing +LogCompilation flag.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4157:

> 4155:   ExternalAddress mxcsr_std(StubRoutines::x86::addr_mxcsr_std());
> 4156:   ldmxcsr(new_mxcsr);
> 4157:   movl(scratch, 1056964608);

What is 1056964608 ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From jbhateja at openjdk.java.net  Sun Mar  6 11:47:01 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 6 Mar 2022 11:47:01 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v11]
In-Reply-To: <JZRQE05iyBsB3obYWVPHU8tJp2PxhCtCUb0d-wlv5rE=.ae7a4288-4bc7-4ab2-b427-7a41cd8f37a0@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <pISqYd60ZBAUKka4b7I1ADwLxQaDQigDYRyWvD6-buY=.6d7a7ab1-7a10-4e62-9f60-9f82dcefadd2@github.com>
 <JZRQE05iyBsB3obYWVPHU8tJp2PxhCtCUb0d-wlv5rE=.ae7a4288-4bc7-4ab2-b427-7a41cd8f37a0@github.com>
Message-ID: <78mhhL5dqkY5LQY2U2i_DF6MvgYBQiDIrieGcBOCGAA=.ec16edf8-24d2-4658-92ff-5d20f03e7620@github.com>

On Sun, 6 Mar 2022 09:31:27 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8279508: Removing +LogCompilation flag.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4157:
> 
>> 4155:   ExternalAddress mxcsr_std(StubRoutines::x86::addr_mxcsr_std());
>> 4156:   ldmxcsr(new_mxcsr);
>> 4157:   movl(scratch, 1056964608);
> 
> What is 1056964608 ?

Raw bits corresponding to floating point value 0.5f.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From aph at openjdk.java.net  Sun Mar  6 13:52:00 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Sun, 6 Mar 2022 13:52:00 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v11]
In-Reply-To: <pISqYd60ZBAUKka4b7I1ADwLxQaDQigDYRyWvD6-buY=.6d7a7ab1-7a10-4e62-9f60-9f82dcefadd2@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <pISqYd60ZBAUKka4b7I1ADwLxQaDQigDYRyWvD6-buY=.6d7a7ab1-7a10-4e62-9f60-9f82dcefadd2@github.com>
Message-ID: <IP8nkdgSL6-3KcegHJYa4ZeLpX-CasmzVmXqEt7jhxg=.0a5c949c-8373-4b3a-ab43-2cfb42e73e5c@github.com>

On Wed, 2 Mar 2022 02:44:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
>> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279508: Removing +LogCompilation flag.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4157:

> 4155:   ExternalAddress mxcsr_std(StubRoutines::x86::addr_mxcsr_std());
> 4156:   ldmxcsr(new_mxcsr);
> 4157:   movl(scratch, 1056964608);

Suggestion:

  movl(scratch, 1056964608); // Raw bits corresponding to floating point value 0.5f.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From xgong at openjdk.java.net  Mon Mar  7 01:31:04 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 7 Mar 2022 01:31:04 GMT
Subject: RFR: 8282432: Optimize masked "test" Vector API with predicate
 feature [v2]
In-Reply-To: <PZYFGsRTFUuVcp_KAxIiqkmFJG8_RVyNB5CIJB5KZZI=.ba35562e-b7d8-43e6-9d67-aed521373fe8@github.com>
References: <RlORBnCyrfaaTry0T08GvIcNFPFptQcFuMLRp7_xa6M=.4872305b-525d-4bee-9ec6-354950b87605@github.com>
 <Kt2y_yNkybBAXAS4z-rmKXBmE19qfooLEnTM6mCWejI=.4267af7f-1916-4cfc-9f9e-5ccb6227c019@github.com>
 <PZYFGsRTFUuVcp_KAxIiqkmFJG8_RVyNB5CIJB5KZZI=.ba35562e-b7d8-43e6-9d67-aed521373fe8@github.com>
Message-ID: <y03u9VqNNS6AoeHnnYrRrdOOtFTiglVw_VDdvcRhvek=.31635b6d-4a8c-4629-9d79-161578336979@github.com>

On Thu, 3 Mar 2022 17:40:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> I guess the following: `mask.cast(IntVector.species(shape())` is more efficient than: `m.cast(vspecies().asIntegral()))` ?

Yeah, that's one point. Another main reason is `m.cast(vspecies().asIntegral()))`  cannot be handled well in the superclass due to the java generic issues.

Thanks for the reiview @PaulSandoz !

-------------

PR: https://git.openjdk.java.net/jdk/pull/7654

From jbhateja at openjdk.java.net  Mon Mar  7 02:09:27 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 7 Mar 2022 02:09:27 GMT
Subject: RFR: 8282711: Accelerate Math.signum function for AVX and AVX512
 target.
Message-ID: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>

- Patch auto-vectorizes Math.signum operation for floating point types.
- Efficient JIT sequence is being generated for AVX512 and legacy X86 targets.
- Following is the performance data for include JMH micro.

System : Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz  (40C 2S Icelake Server) 

Benchmark | (SIZE) | Baseline AVX (ns/op) | Withopt AVX (ns/op) | Gain Ratio | Basline AVX512 (ns/op) | Withopt AVX512 (ns/op) | Gain Ratio
-- | -- | -- | -- | -- | -- | -- | --
VectorSignum.doubleSignum | 256 | 174.357 | 68.374 | 2.550048264 | 173.679 | 31.013 | 5.600199916
VectorSignum.doubleSignum | 512 | 334.231 | 128.762 | 2.595727 | 334.625 | 59.377 | 5.635599643
VectorSignum.doubleSignum | 1024 | 655.679 | 251.566 | 2.606389576 | 655.267 | 116.736 | 5.613238418
VectorSignum.doubleSignum | 2048 | 1292.165 | 499.924 | 2.584722878 | 1301.7 | 228.064 | 5.707608391
VectorSignum.floatSignum | 256 | 176.064 | 39.864 | 4.416616496 | 174.639 | 25.372 | 6.883138893
VectorSignum.floatSignum | 512 | 337.565 | 71.027 | 4.752629282 | 331.506 | 36.64 | 9.047652838
VectorSignum.floatSignum | 1024 | 661.488 | 131.074 | 5.046675924 | 644.621 | 63.88 | 10.09112398
VectorSignum.floatSignum | 2048 | 1299.685 | 253.271 | 5.13159817 | 1279.658 | 118.995 | 10.75388042


Kindly review and share feedback.

Best Regards,
Jatin

-------------

Commit messages:
 - 8282711: Accelerate Math.signum function for AVX and AVX512 target.

Changes: https://git.openjdk.java.net/jdk/pull/7717/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7717&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282711
  Stats: 261 lines in 14 files changed: 260 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7717.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7717/head:pull/7717

PR: https://git.openjdk.java.net/jdk/pull/7717

From xliu at openjdk.java.net  Mon Mar  7 05:43:30 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 7 Mar 2022 05:43:30 GMT
Subject: RFR: 8282715: typo compileony in test Test8005033.java
Message-ID: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>

This patch doesn't change the testing functionality. It was compiled before. HotSpot failed to handle compiler directive 'compileony'. As a result, it has to compile all methods.  

Here is the warning message

CompileCommand: An error occurred during parsing
Error: Unrecognized option 'compileony'
Line: 'compileony,compiler.codegen.Test8005033::testBitCount'

Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
Use: '-XX:CompileCommand=help' for more information and to list all option.

After correcting the typo, hotspot only compiles the method it is supposed to test. Test time of fastdebug build reduces from 16.778s to 0.226s.

-------------

Commit messages:
 - 8282715: typo compileony in test Test8005033.java

Changes: https://git.openjdk.java.net/jdk/pull/7718/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7718&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282715
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7718.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7718/head:pull/7718

PR: https://git.openjdk.java.net/jdk/pull/7718

From jiefu at openjdk.java.net  Mon Mar  7 06:03:02 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 7 Mar 2022 06:03:02 GMT
Subject: RFR: 8282715: typo compileony in test Test8005033.java
In-Reply-To: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
References: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
Message-ID: <3gBRgvg9yAeLR3w927PpdgfjHCG2VVzonrmDOUMryNU=.c18099bc-a71c-4e53-9d97-ee290455a60d@github.com>

On Mon, 7 Mar 2022 05:33:26 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This patch doesn't change the testing functionality. It was compiled before. HotSpot failed to handle compiler directive 'compileony'. As a result, it has to compile all methods.  
> 
> Here is the warning message
> 
> CompileCommand: An error occurred during parsing
> Error: Unrecognized option 'compileony'
> Line: 'compileony,compiler.codegen.Test8005033::testBitCount'
> 
> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
> Use: '-XX:CompileCommand=help' for more information and to list all option.
> 
> After correcting the typo, hotspot only compiles the method it is supposed to test. Test time of fastdebug build reduces from 16.778s to 0.226s.

test/hotspot/jtreg/compiler/codegen/Test8005033.java line 2:

> 1: /*
> 2:  * Copyright (c) 2012, 2022 SAP SE. All rights reserved.

We'd better not change the copyright line other than Oracle's.
Maybe, you can start a newline of yours after it.

test/hotspot/jtreg/compiler/codegen/Test8005033.java line 30:

> 28:  *
> 29:  * @run main/othervm -Xcomp
> 30:  *      -XX:CompileCommand=compileonly,compiler.codegen.Test8005033::testBitCount

This looks reasonable to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7718

From haosun at openjdk.java.net  Mon Mar  7 08:53:20 2022
From: haosun at openjdk.java.net (Hao Sun)
Date: Mon, 7 Mar 2022 08:53:20 GMT
Subject: RFR: 8265263: AArch64: Combine vneg with right shift count
Message-ID: <6APGll3m5cYjHelXsVqrfzEmzUaiTBHQHZOlsB2C1OM=.0d34fc7f-4b0a-430d-b519-336a34969efc@github.com>

### Implementation

In AArch64 NEON, vector shift right is implemented by vector shift left
instructions (SSHL[1] and USHL[2]) with negative shift count value. In
C2 backend, we generate a `neg` to given shift value followed by `sshl`
or `ushl` instruction.

For vector shift right, the vector shift count has two origins:
1) it can be duplicated from scalar variable/immediate(case-1),
2) it can be loaded directly from one vector(case-2).

This patch aims to optimize case-1. Specifically, we move the negate
from RShiftV* rules to RShiftCntV rule. As a result, the negate can be
hoisted outside of the loop if it's a loop invariant.

In this patch,
1) we split vshiftcnt* rules into vslcnt* and vsrcnt* rules to handle
shift left and shift right respectively. Compared to vslcnt* rules, the
negate is conducted in vsrcnt*.
2) for each vsra* and vsrl* rules, we create one variant, i.e. vsra*_var
and vsrl*_var. We use vsra* and vsrl* rules to handle case-1, and use
vsra*_var and vsrl*_var rules to handle case-2. Note that
ShiftVNode::is_var_shift() can be used to distinguish case-1 from
case-2.
3) we add one assertion for the vs*_imm rules as we have done on
ARM32[3].
4) several style issues are resolved.

### Example

Take function `rShiftInt()` in the newly added micro benchmark
VectorShiftRight.java as an example.


public void rShiftInt() {
    for (int i = 0; i < SIZE; i++) {
        intsB[i] = intsA[i] >> count;
    }
}


Arithmetic shift right is conducted inside a big loop. The following
code snippet shows the disassembly code generated by auto-vectorization
before we apply current patch. We can see that `neg` is conducted in the
loop body.


0x0000ffff89057a64:   dup     v16.16b, w13              <-- dup
0x0000ffff89057a68:   mov     w12, #0x7d00                    // #32000
0x0000ffff89057a6c:   sub     w13, w2, w10
0x0000ffff89057a70:   cmp     w2, w10
0x0000ffff89057a74:   csel    w13, wzr, w13, lt
0x0000ffff89057a78:   mov     w8, #0x7d00                     // #32000
0x0000ffff89057a7c:   cmp     w13, w8
0x0000ffff89057a80:   csel    w13, w12, w13, hi
0x0000ffff89057a84:   add     w14, w13, w10
0x0000ffff89057a88:   nop
0x0000ffff89057a8c:   nop
0x0000ffff89057a90:   sbfiz   x13, x10, #2, #32         <-- loop entry
0x0000ffff89057a94:   add     x15, x17, x13
0x0000ffff89057a98:   ldr     q17, [x15,#16]
0x0000ffff89057a9c:   add     x13, x0, x13
0x0000ffff89057aa0:   neg     v18.16b, v16.16b          <-- neg
0x0000ffff89057aa4:   sshl    v17.4s, v17.4s, v18.4s    <-- shift right
0x0000ffff89057aa8:   str     q17, [x13,#16]
0x0000ffff89057aac:   ...
0x0000ffff89057b1c:   add     w10, w10, #0x20
0x0000ffff89057b20:   cmp     w10, w14
0x0000ffff89057b24:   b.lt    0x0000ffff89057a90        <-- loop end


Here is the disassembly code after we apply current patch. We can see
that the negate is no longer conducted inside the loop, and it is
hoisted to the outside.


0x0000ffff8d053a68:   neg     w14, w13                  <---- neg
0x0000ffff8d053a6c:   dup     v16.16b, w14              <---- dup
0x0000ffff8d053a70:   sub     w14, w2, w10
0x0000ffff8d053a74:   cmp     w2, w10
0x0000ffff8d053a78:   csel    w14, wzr, w14, lt
0x0000ffff8d053a7c:   mov     w8, #0x7d00                     // #32000
0x0000ffff8d053a80:   cmp     w14, w8
0x0000ffff8d053a84:   csel    w14, w12, w14, hi
0x0000ffff8d053a88:   add     w13, w14, w10
0x0000ffff8d053a8c:   nop
0x0000ffff8d053a90:   sbfiz   x14, x10, #2, #32         <-- loop entry
0x0000ffff8d053a94:   add     x15, x17, x14
0x0000ffff8d053a98:   ldr     q17, [x15,#16]
0x0000ffff8d053a9c:   sshl    v17.4s, v17.4s, v16.4s    <-- shift right
0x0000ffff8d053aa0:   add     x14, x0, x14
0x0000ffff8d053aa4:   str     q17, [x14,#16]
0x0000ffff8d053aa8:   ...
0x0000ffff8d053afc:   add     w10, w10, #0x20
0x0000ffff8d053b00:   cmp     w10, w13
0x0000ffff8d053b04:   b.lt    0x0000ffff8d053a90        <-- loop end


### Testing

Tier1~3 tests passed on Linux/AArch64 platform.

### Performance Evaluation

- Auto-vectorization

One micro benchmark, i.e. VectorShiftRight.java, is added by this patch
in order to evaluate the optimization on vector shift right.

The following table shows the result. Column `Score-1` shows the score
before we apply current patch, and column `Score-2` shows the score when
we apply current patch.

We witness about 30% ~ 53% improvement on microbenchmarks.


Benchmark                      Units    Score-1    Score-2
VectorShiftRight.rShiftByte   ops/ms  10601.980  13816.353
VectorShiftRight.rShiftInt    ops/ms   3592.831   5502.941
VectorShiftRight.rShiftLong   ops/ms   1584.012   2425.247
VectorShiftRight.rShiftShort  ops/ms   6643.414   9728.762
VectorShiftRight.urShiftByte  ops/ms   2066.965   2048.336 (*)
VectorShiftRight.urShiftChar  ops/ms   6660.805   9728.478
VectorShiftRight.urShiftInt   ops/ms   3592.909   5514.928
VectorShiftRight.urShiftLong  ops/ms   1583.995   2422.991

*: Logical shift right for Byte type(urShiftByte) is not vectorized, as
disscussed in [4].


- VectorAPI

Furthermore, we also evaluate the impact of this patch on VectorAPI
benchmarks, e.g., [5]. Details can be found in the table below. Columns
`Score-1` and `Score-2` show the scores before and after applying
current patch.


Benchmark                  Units    Score-1    Score-2
Byte128Vector.LSHL        ops/ms  10867.666  10873.993
Byte128Vector.LSHLShift   ops/ms  10945.729  10945.741
Byte128Vector.LSHR        ops/ms   8629.305   8629.343
Byte128Vector.LSHRShift   ops/ms   8245.864  10303.521   <--
Byte128Vector.ASHR        ops/ms   8619.691   8629.438
Byte128Vector.ASHRShift   ops/ms   8245.860  10305.027   <--
Int128Vector.LSHL         ops/ms   3104.213   3103.702
Int128Vector.LSHLShift    ops/ms   3114.354   3114.371
Int128Vector.LSHR         ops/ms   2380.717   2380.693
Int128Vector.LSHRShift    ops/ms   2312.871   2992.377   <--
Int128Vector.ASHR         ops/ms   2380.668   2380.647
Int128Vector.ASHRShift    ops/ms   2312.894   2992.332   <--
Long128Vector.LSHL        ops/ms   1586.907   1587.591
Long128Vector.LSHLShift   ops/ms   1589.469   1589.540
Long128Vector.LSHR        ops/ms   1209.754   1209.687
Long128Vector.LSHRShift   ops/ms   1174.718   1527.502   <--
Long128Vector.ASHR        ops/ms   1209.713   1209.669
Long128Vector.ASHRShift   ops/ms   1174.712   1527.174   <--
Short128Vector.LSHL       ops/ms   5945.542   5943.770
Short128Vector.LSHLShift  ops/ms   5984.743   5984.640
Short128Vector.LSHR       ops/ms   4613.378   4613.577
Short128Vector.LSHRShift  ops/ms   4486.023   5746.466   <--
Short128Vector.ASHR       ops/ms   4613.389   4613.478
Short128Vector.ASHRShift  ops/ms   4486.019   5746.368   <--


1) For logical shift left(LSHL and LSHLShift), and shift right with
variable vector shift count(LSHR and ASHR) cases, we didn't find much
changes, which is expected.

2) For shift right with scalar shift count(LSHRShift and ASHRShift)
case, about 25% ~ 30% improvement can be observed, and this benefit is
introduced by current patch.

[1] https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/SSHL--Signed-Shift-Left--register--
[2] https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/USHL--Unsigned-Shift-Left--register--
[3] https://github.com/openjdk/jdk18/pull/41
[4] https://github.com/openjdk/jdk/pull/1087
[5] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L509

-------------

Commit messages:
 - 8265263: AArch64: Combine vneg with right shift count

Changes: https://git.openjdk.java.net/jdk/pull/7724/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7724&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265263
  Stats: 856 lines in 4 files changed: 479 ins; 44 del; 333 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7724.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7724/head:pull/7724

PR: https://git.openjdk.java.net/jdk/pull/7724

From duke at openjdk.java.net  Mon Mar  7 09:16:15 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Mon, 7 Mar 2022 09:16:15 GMT
Subject: RFR: 8282665: [REDO] ByteBufferTest.java: replace endless recursion
 with RuntimeException in void ck(double x, double y)
Message-ID: <GkxbMy2Qw-zKDCZCsv759XPa6iluwVBQVGssKijyPi4=.10562a25-43af-412c-8489-43249076ff8d@github.com>

Until now, ck for doubles ignored the case when either x or y was NaN, it for example would let pass x=NaN and y=2.0.
Further, instead of throwing an exception, it went into infinite recursion, with an eventual StackOverflowError.
Now, we throw an exception that prints the values. I fixed the logic, and added an explanation.

Testing is running...

-------------

Commit messages:
 - fix whitespaces
 - 8282665: [REDO] ByteBufferTest.java: replace endless recursion with RuntimeException in void ck(double x, double y)

Changes: https://git.openjdk.java.net/jdk/pull/7723/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7723&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282665
  Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7723.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7723/head:pull/7723

PR: https://git.openjdk.java.net/jdk/pull/7723

From sgehwolf at openjdk.java.net  Mon Mar  7 09:59:56 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 7 Mar 2022 09:59:56 GMT
Subject: RFR: 8281266: [JVMCI] MetaUtil.toInternalName() doesn't handle
 hidden classes correctly
In-Reply-To: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>
References: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>
Message-ID: <oBJmg3pIYRNKv9hW2pAkT8yFODnzJGG8whd-V-ruV_s=.4e47cd19-926c-4e4b-a9f8-9b3ca663e8e7@github.com>

On Fri, 4 Feb 2022 12:01:46 GMT, Foivos <duke at openjdk.java.net> wrote:

> https://github.com/openjdk/jdk/commit/7cc137105928ec109a29d9315565f7f49af3cf2b introduced hidden classes with internal names like `com/example/Foo.1234` that get changed to `com.example.Foo/1234` by `Class.getName()` which are not properly handled by `MetaUtil`'s `toInternalName` and `internalNameToJava`
> 
> This PR fixes this along with the corresponding test that used to work on the assumption that the internal class names didn't contain the `.` character and that java class names didn't contain the `/` character except for lambdas (which are now treated as hidden classes as well), an assumption that no longer holds.

This looks fine to me. Perhaps @dougxc or @tkrodriguez want to have a look at this too?

src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaUtil.java line 127:

> 125:         switch (name.charAt(0)) {
> 126:             case 'L': {
> 127:                 String result = replacePackageAndHiddenSeparators(name.substring(1, name.length() - 1), '/', '.');

Consider extracting constants `/` (as `PACKAGE_SEP_INTERNAL` perhaps)  and `.` (as `HIDDEN_SEP_INTERNAL`). You could then also create the inversely defined constants `PACKAGE_SEP_JAVA` and `HIDDEN_SEP_JAVA`. It would make the code slightly easier to read.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7346

From duke at openjdk.java.net  Mon Mar  7 10:25:47 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Mon, 7 Mar 2022 10:25:47 GMT
Subject: RFR: 8282665: [REDO] ByteBufferTest.java: replace endless
 recursion with RuntimeException in void ck(double x, double y) [v2]
In-Reply-To: <GkxbMy2Qw-zKDCZCsv759XPa6iluwVBQVGssKijyPi4=.10562a25-43af-412c-8489-43249076ff8d@github.com>
References: <GkxbMy2Qw-zKDCZCsv759XPa6iluwVBQVGssKijyPi4=.10562a25-43af-412c-8489-43249076ff8d@github.com>
Message-ID: <-34q5-7FfYMtgEgjaQabZtD0Bt4Hvnvk2bRJLeq_YU8=.1c90c5fb-87b7-4cd1-9079-b8e711e4b3ce@github.com>

> Until now, ck for doubles ignored the case when either x or y was NaN, it for example would let pass x=NaN and y=2.0.
> Further, instead of throwing an exception, it went into infinite recursion, with an eventual StackOverflowError.
> Now, we throw an exception that prints the values. I fixed the logic, and added an explanation.
> 
> All tests are passing.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  state reason for failure in Exception

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7723/files
  - new: https://git.openjdk.java.net/jdk/pull/7723/files/9bee927f..a96fbb5d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7723&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7723&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7723.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7723/head:pull/7723

PR: https://git.openjdk.java.net/jdk/pull/7723

From dnsimon at openjdk.java.net  Mon Mar  7 10:26:08 2022
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Mon, 7 Mar 2022 10:26:08 GMT
Subject: RFR: 8281266: [JVMCI] MetaUtil.toInternalName() doesn't handle
 hidden classes correctly
In-Reply-To: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>
References: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>
Message-ID: <EpI26TD_VNGQQze7N9kdOh8_Pt90VwMOgRLUl7oVevo=.d3967d60-5286-4e51-ae1c-2b0dbcd8e185@github.com>

On Fri, 4 Feb 2022 12:01:46 GMT, Foivos <duke at openjdk.java.net> wrote:

> https://github.com/openjdk/jdk/commit/7cc137105928ec109a29d9315565f7f49af3cf2b introduced hidden classes with internal names like `com/example/Foo.1234` that get changed to `com.example.Foo/1234` by `Class.getName()` which are not properly handled by `MetaUtil`'s `toInternalName` and `internalNameToJava`
> 
> This PR fixes this along with the corresponding test that used to work on the assumption that the internal class names didn't contain the `.` character and that java class names didn't contain the `/` character except for lambdas (which are now treated as hidden classes as well), an assumption that no longer holds.

Marked as reviewed by dnsimon (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7346

From adinn at openjdk.java.net  Mon Mar  7 11:12:04 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Mon, 7 Mar 2022 11:12:04 GMT
Subject: RFR: 8265263: AArch64: Combine vneg with right shift count
In-Reply-To: <6APGll3m5cYjHelXsVqrfzEmzUaiTBHQHZOlsB2C1OM=.0d34fc7f-4b0a-430d-b519-336a34969efc@github.com>
References: <6APGll3m5cYjHelXsVqrfzEmzUaiTBHQHZOlsB2C1OM=.0d34fc7f-4b0a-430d-b519-336a34969efc@github.com>
Message-ID: <r41jYE7C1P7rGAiIXaG_yf4TrucWPS-62dLt0ubaQnQ=.8fc710d2-7ba0-40dc-9dfc-de1729d10511@github.com>

On Mon, 7 Mar 2022 08:46:12 GMT, Hao Sun <haosun at openjdk.org> wrote:

> ### Implementation
> 
> In AArch64 NEON, vector shift right is implemented by vector shift left
> instructions (SSHL[1] and USHL[2]) with negative shift count value. In
> C2 backend, we generate a `neg` to given shift value followed by `sshl`
> or `ushl` instruction.
> 
> For vector shift right, the vector shift count has two origins:
> 1) it can be duplicated from scalar variable/immediate(case-1),
> 2) it can be loaded directly from one vector(case-2).
> 
> This patch aims to optimize case-1. Specifically, we move the negate
> from RShiftV* rules to RShiftCntV rule. As a result, the negate can be
> hoisted outside of the loop if it's a loop invariant.
> 
> In this patch,
> 1) we split vshiftcnt* rules into vslcnt* and vsrcnt* rules to handle
> shift left and shift right respectively. Compared to vslcnt* rules, the
> negate is conducted in vsrcnt*.
> 2) for each vsra* and vsrl* rules, we create one variant, i.e. vsra*_var
> and vsrl*_var. We use vsra* and vsrl* rules to handle case-1, and use
> vsra*_var and vsrl*_var rules to handle case-2. Note that
> ShiftVNode::is_var_shift() can be used to distinguish case-1 from
> case-2.
> 3) we add one assertion for the vs*_imm rules as we have done on
> ARM32[3].
> 4) several style issues are resolved.
> 
> ### Example
> 
> Take function `rShiftInt()` in the newly added micro benchmark
> VectorShiftRight.java as an example.
> 
> 
> public void rShiftInt() {
>     for (int i = 0; i < SIZE; i++) {
>         intsB[i] = intsA[i] >> count;
>     }
> }
> 
> 
> Arithmetic shift right is conducted inside a big loop. The following
> code snippet shows the disassembly code generated by auto-vectorization
> before we apply current patch. We can see that `neg` is conducted in the
> loop body.
> 
> 
> 0x0000ffff89057a64:   dup     v16.16b, w13              <-- dup
> 0x0000ffff89057a68:   mov     w12, #0x7d00                    // #32000
> 0x0000ffff89057a6c:   sub     w13, w2, w10
> 0x0000ffff89057a70:   cmp     w2, w10
> 0x0000ffff89057a74:   csel    w13, wzr, w13, lt
> 0x0000ffff89057a78:   mov     w8, #0x7d00                     // #32000
> 0x0000ffff89057a7c:   cmp     w13, w8
> 0x0000ffff89057a80:   csel    w13, w12, w13, hi
> 0x0000ffff89057a84:   add     w14, w13, w10
> 0x0000ffff89057a88:   nop
> 0x0000ffff89057a8c:   nop
> 0x0000ffff89057a90:   sbfiz   x13, x10, #2, #32         <-- loop entry
> 0x0000ffff89057a94:   add     x15, x17, x13
> 0x0000ffff89057a98:   ldr     q17, [x15,#16]
> 0x0000ffff89057a9c:   add     x13, x0, x13
> 0x0000ffff89057aa0:   neg     v18.16b, v16.16b          <-- neg
> 0x0000ffff89057aa4:   sshl    v17.4s, v17.4s, v18.4s    <-- shift right
> 0x0000ffff89057aa8:   str     q17, [x13,#16]
> 0x0000ffff89057aac:   ...
> 0x0000ffff89057b1c:   add     w10, w10, #0x20
> 0x0000ffff89057b20:   cmp     w10, w14
> 0x0000ffff89057b24:   b.lt    0x0000ffff89057a90        <-- loop end
> 
> 
> Here is the disassembly code after we apply current patch. We can see
> that the negate is no longer conducted inside the loop, and it is
> hoisted to the outside.
> 
> 
> 0x0000ffff8d053a68:   neg     w14, w13                  <---- neg
> 0x0000ffff8d053a6c:   dup     v16.16b, w14              <---- dup
> 0x0000ffff8d053a70:   sub     w14, w2, w10
> 0x0000ffff8d053a74:   cmp     w2, w10
> 0x0000ffff8d053a78:   csel    w14, wzr, w14, lt
> 0x0000ffff8d053a7c:   mov     w8, #0x7d00                     // #32000
> 0x0000ffff8d053a80:   cmp     w14, w8
> 0x0000ffff8d053a84:   csel    w14, w12, w14, hi
> 0x0000ffff8d053a88:   add     w13, w14, w10
> 0x0000ffff8d053a8c:   nop
> 0x0000ffff8d053a90:   sbfiz   x14, x10, #2, #32         <-- loop entry
> 0x0000ffff8d053a94:   add     x15, x17, x14
> 0x0000ffff8d053a98:   ldr     q17, [x15,#16]
> 0x0000ffff8d053a9c:   sshl    v17.4s, v17.4s, v16.4s    <-- shift right
> 0x0000ffff8d053aa0:   add     x14, x0, x14
> 0x0000ffff8d053aa4:   str     q17, [x14,#16]
> 0x0000ffff8d053aa8:   ...
> 0x0000ffff8d053afc:   add     w10, w10, #0x20
> 0x0000ffff8d053b00:   cmp     w10, w13
> 0x0000ffff8d053b04:   b.lt    0x0000ffff8d053a90        <-- loop end
> 
> 
> ### Testing
> 
> Tier1~3 tests passed on Linux/AArch64 platform.
> 
> ### Performance Evaluation
> 
> - Auto-vectorization
> 
> One micro benchmark, i.e. VectorShiftRight.java, is added by this patch
> in order to evaluate the optimization on vector shift right.
> 
> The following table shows the result. Column `Score-1` shows the score
> before we apply current patch, and column `Score-2` shows the score when
> we apply current patch.
> 
> We witness about 30% ~ 53% improvement on microbenchmarks.
> 
> 
> Benchmark                      Units    Score-1    Score-2
> VectorShiftRight.rShiftByte   ops/ms  10601.980  13816.353
> VectorShiftRight.rShiftInt    ops/ms   3592.831   5502.941
> VectorShiftRight.rShiftLong   ops/ms   1584.012   2425.247
> VectorShiftRight.rShiftShort  ops/ms   6643.414   9728.762
> VectorShiftRight.urShiftByte  ops/ms   2066.965   2048.336 (*)
> VectorShiftRight.urShiftChar  ops/ms   6660.805   9728.478
> VectorShiftRight.urShiftInt   ops/ms   3592.909   5514.928
> VectorShiftRight.urShiftLong  ops/ms   1583.995   2422.991
> 
> *: Logical shift right for Byte type(urShiftByte) is not vectorized, as
> disscussed in [4].
> 
> 
> - VectorAPI
> 
> Furthermore, we also evaluate the impact of this patch on VectorAPI
> benchmarks, e.g., [5]. Details can be found in the table below. Columns
> `Score-1` and `Score-2` show the scores before and after applying
> current patch.
> 
> 
> Benchmark                  Units    Score-1    Score-2
> Byte128Vector.LSHL        ops/ms  10867.666  10873.993
> Byte128Vector.LSHLShift   ops/ms  10945.729  10945.741
> Byte128Vector.LSHR        ops/ms   8629.305   8629.343
> Byte128Vector.LSHRShift   ops/ms   8245.864  10303.521   <--
> Byte128Vector.ASHR        ops/ms   8619.691   8629.438
> Byte128Vector.ASHRShift   ops/ms   8245.860  10305.027   <--
> Int128Vector.LSHL         ops/ms   3104.213   3103.702
> Int128Vector.LSHLShift    ops/ms   3114.354   3114.371
> Int128Vector.LSHR         ops/ms   2380.717   2380.693
> Int128Vector.LSHRShift    ops/ms   2312.871   2992.377   <--
> Int128Vector.ASHR         ops/ms   2380.668   2380.647
> Int128Vector.ASHRShift    ops/ms   2312.894   2992.332   <--
> Long128Vector.LSHL        ops/ms   1586.907   1587.591
> Long128Vector.LSHLShift   ops/ms   1589.469   1589.540
> Long128Vector.LSHR        ops/ms   1209.754   1209.687
> Long128Vector.LSHRShift   ops/ms   1174.718   1527.502   <--
> Long128Vector.ASHR        ops/ms   1209.713   1209.669
> Long128Vector.ASHRShift   ops/ms   1174.712   1527.174   <--
> Short128Vector.LSHL       ops/ms   5945.542   5943.770
> Short128Vector.LSHLShift  ops/ms   5984.743   5984.640
> Short128Vector.LSHR       ops/ms   4613.378   4613.577
> Short128Vector.LSHRShift  ops/ms   4486.023   5746.466   <--
> Short128Vector.ASHR       ops/ms   4613.389   4613.478
> Short128Vector.ASHRShift  ops/ms   4486.019   5746.368   <--
> 
> 
> 1) For logical shift left(LSHL and LSHLShift), and shift right with
> variable vector shift count(LSHR and ASHR) cases, we didn't find much
> changes, which is expected.
> 
> 2) For shift right with scalar shift count(LSHRShift and ASHRShift)
> case, about 25% ~ 30% improvement can be observed, and this benefit is
> introduced by current patch.
> 
> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/SSHL--Signed-Shift-Left--register--
> [2] https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/USHL--Unsigned-Shift-Left--register--
> [3] https://github.com/openjdk/jdk18/pull/41
> [4] https://github.com/openjdk/jdk/pull/1087
> [5] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L509

This looks fine. Very nice work.

-------------

Marked as reviewed by adinn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7724

From haosun at openjdk.java.net  Mon Mar  7 12:54:03 2022
From: haosun at openjdk.java.net (Hao Sun)
Date: Mon, 7 Mar 2022 12:54:03 GMT
Subject: RFR: 8265263: AArch64: Combine vneg with right shift count
In-Reply-To: <6APGll3m5cYjHelXsVqrfzEmzUaiTBHQHZOlsB2C1OM=.0d34fc7f-4b0a-430d-b519-336a34969efc@github.com>
References: <6APGll3m5cYjHelXsVqrfzEmzUaiTBHQHZOlsB2C1OM=.0d34fc7f-4b0a-430d-b519-336a34969efc@github.com>
Message-ID: <Tb4KgMHMld6gJ77CMa8hl2GFtkPmwMNO_Ve0-xsy0I0=.761b378c-a9b9-470b-988a-4ce088c05a02@github.com>

On Mon, 7 Mar 2022 08:46:12 GMT, Hao Sun <haosun at openjdk.org> wrote:

> ### Implementation
> 
> In AArch64 NEON, vector shift right is implemented by vector shift left
> instructions (SSHL[1] and USHL[2]) with negative shift count value. In
> C2 backend, we generate a `neg` to given shift value followed by `sshl`
> or `ushl` instruction.
> 
> For vector shift right, the vector shift count has two origins:
> 1) it can be duplicated from scalar variable/immediate(case-1),
> 2) it can be loaded directly from one vector(case-2).
> 
> This patch aims to optimize case-1. Specifically, we move the negate
> from RShiftV* rules to RShiftCntV rule. As a result, the negate can be
> hoisted outside of the loop if it's a loop invariant.
> 
> In this patch,
> 1) we split vshiftcnt* rules into vslcnt* and vsrcnt* rules to handle
> shift left and shift right respectively. Compared to vslcnt* rules, the
> negate is conducted in vsrcnt*.
> 2) for each vsra* and vsrl* rules, we create one variant, i.e. vsra*_var
> and vsrl*_var. We use vsra* and vsrl* rules to handle case-1, and use
> vsra*_var and vsrl*_var rules to handle case-2. Note that
> ShiftVNode::is_var_shift() can be used to distinguish case-1 from
> case-2.
> 3) we add one assertion for the vs*_imm rules as we have done on
> ARM32[3].
> 4) several style issues are resolved.
> 
> ### Example
> 
> Take function `rShiftInt()` in the newly added micro benchmark
> VectorShiftRight.java as an example.
> 
> 
> public void rShiftInt() {
>     for (int i = 0; i < SIZE; i++) {
>         intsB[i] = intsA[i] >> count;
>     }
> }
> 
> 
> Arithmetic shift right is conducted inside a big loop. The following
> code snippet shows the disassembly code generated by auto-vectorization
> before we apply current patch. We can see that `neg` is conducted in the
> loop body.
> 
> 
> 0x0000ffff89057a64:   dup     v16.16b, w13              <-- dup
> 0x0000ffff89057a68:   mov     w12, #0x7d00                    // #32000
> 0x0000ffff89057a6c:   sub     w13, w2, w10
> 0x0000ffff89057a70:   cmp     w2, w10
> 0x0000ffff89057a74:   csel    w13, wzr, w13, lt
> 0x0000ffff89057a78:   mov     w8, #0x7d00                     // #32000
> 0x0000ffff89057a7c:   cmp     w13, w8
> 0x0000ffff89057a80:   csel    w13, w12, w13, hi
> 0x0000ffff89057a84:   add     w14, w13, w10
> 0x0000ffff89057a88:   nop
> 0x0000ffff89057a8c:   nop
> 0x0000ffff89057a90:   sbfiz   x13, x10, #2, #32         <-- loop entry
> 0x0000ffff89057a94:   add     x15, x17, x13
> 0x0000ffff89057a98:   ldr     q17, [x15,#16]
> 0x0000ffff89057a9c:   add     x13, x0, x13
> 0x0000ffff89057aa0:   neg     v18.16b, v16.16b          <-- neg
> 0x0000ffff89057aa4:   sshl    v17.4s, v17.4s, v18.4s    <-- shift right
> 0x0000ffff89057aa8:   str     q17, [x13,#16]
> 0x0000ffff89057aac:   ...
> 0x0000ffff89057b1c:   add     w10, w10, #0x20
> 0x0000ffff89057b20:   cmp     w10, w14
> 0x0000ffff89057b24:   b.lt    0x0000ffff89057a90        <-- loop end
> 
> 
> Here is the disassembly code after we apply current patch. We can see
> that the negate is no longer conducted inside the loop, and it is
> hoisted to the outside.
> 
> 
> 0x0000ffff8d053a68:   neg     w14, w13                  <---- neg
> 0x0000ffff8d053a6c:   dup     v16.16b, w14              <---- dup
> 0x0000ffff8d053a70:   sub     w14, w2, w10
> 0x0000ffff8d053a74:   cmp     w2, w10
> 0x0000ffff8d053a78:   csel    w14, wzr, w14, lt
> 0x0000ffff8d053a7c:   mov     w8, #0x7d00                     // #32000
> 0x0000ffff8d053a80:   cmp     w14, w8
> 0x0000ffff8d053a84:   csel    w14, w12, w14, hi
> 0x0000ffff8d053a88:   add     w13, w14, w10
> 0x0000ffff8d053a8c:   nop
> 0x0000ffff8d053a90:   sbfiz   x14, x10, #2, #32         <-- loop entry
> 0x0000ffff8d053a94:   add     x15, x17, x14
> 0x0000ffff8d053a98:   ldr     q17, [x15,#16]
> 0x0000ffff8d053a9c:   sshl    v17.4s, v17.4s, v16.4s    <-- shift right
> 0x0000ffff8d053aa0:   add     x14, x0, x14
> 0x0000ffff8d053aa4:   str     q17, [x14,#16]
> 0x0000ffff8d053aa8:   ...
> 0x0000ffff8d053afc:   add     w10, w10, #0x20
> 0x0000ffff8d053b00:   cmp     w10, w13
> 0x0000ffff8d053b04:   b.lt    0x0000ffff8d053a90        <-- loop end
> 
> 
> ### Testing
> 
> Tier1~3 tests passed on Linux/AArch64 platform.
> 
> ### Performance Evaluation
> 
> - Auto-vectorization
> 
> One micro benchmark, i.e. VectorShiftRight.java, is added by this patch
> in order to evaluate the optimization on vector shift right.
> 
> The following table shows the result. Column `Score-1` shows the score
> before we apply current patch, and column `Score-2` shows the score when
> we apply current patch.
> 
> We witness about 30% ~ 53% improvement on microbenchmarks.
> 
> 
> Benchmark                      Units    Score-1    Score-2
> VectorShiftRight.rShiftByte   ops/ms  10601.980  13816.353
> VectorShiftRight.rShiftInt    ops/ms   3592.831   5502.941
> VectorShiftRight.rShiftLong   ops/ms   1584.012   2425.247
> VectorShiftRight.rShiftShort  ops/ms   6643.414   9728.762
> VectorShiftRight.urShiftByte  ops/ms   2066.965   2048.336 (*)
> VectorShiftRight.urShiftChar  ops/ms   6660.805   9728.478
> VectorShiftRight.urShiftInt   ops/ms   3592.909   5514.928
> VectorShiftRight.urShiftLong  ops/ms   1583.995   2422.991
> 
> *: Logical shift right for Byte type(urShiftByte) is not vectorized, as
> disscussed in [4].
> 
> 
> - VectorAPI
> 
> Furthermore, we also evaluate the impact of this patch on VectorAPI
> benchmarks, e.g., [5]. Details can be found in the table below. Columns
> `Score-1` and `Score-2` show the scores before and after applying
> current patch.
> 
> 
> Benchmark                  Units    Score-1    Score-2
> Byte128Vector.LSHL        ops/ms  10867.666  10873.993
> Byte128Vector.LSHLShift   ops/ms  10945.729  10945.741
> Byte128Vector.LSHR        ops/ms   8629.305   8629.343
> Byte128Vector.LSHRShift   ops/ms   8245.864  10303.521   <--
> Byte128Vector.ASHR        ops/ms   8619.691   8629.438
> Byte128Vector.ASHRShift   ops/ms   8245.860  10305.027   <--
> Int128Vector.LSHL         ops/ms   3104.213   3103.702
> Int128Vector.LSHLShift    ops/ms   3114.354   3114.371
> Int128Vector.LSHR         ops/ms   2380.717   2380.693
> Int128Vector.LSHRShift    ops/ms   2312.871   2992.377   <--
> Int128Vector.ASHR         ops/ms   2380.668   2380.647
> Int128Vector.ASHRShift    ops/ms   2312.894   2992.332   <--
> Long128Vector.LSHL        ops/ms   1586.907   1587.591
> Long128Vector.LSHLShift   ops/ms   1589.469   1589.540
> Long128Vector.LSHR        ops/ms   1209.754   1209.687
> Long128Vector.LSHRShift   ops/ms   1174.718   1527.502   <--
> Long128Vector.ASHR        ops/ms   1209.713   1209.669
> Long128Vector.ASHRShift   ops/ms   1174.712   1527.174   <--
> Short128Vector.LSHL       ops/ms   5945.542   5943.770
> Short128Vector.LSHLShift  ops/ms   5984.743   5984.640
> Short128Vector.LSHR       ops/ms   4613.378   4613.577
> Short128Vector.LSHRShift  ops/ms   4486.023   5746.466   <--
> Short128Vector.ASHR       ops/ms   4613.389   4613.478
> Short128Vector.ASHRShift  ops/ms   4486.019   5746.368   <--
> 
> 
> 1) For logical shift left(LSHL and LSHLShift), and shift right with
> variable vector shift count(LSHR and ASHR) cases, we didn't find much
> changes, which is expected.
> 
> 2) For shift right with scalar shift count(LSHRShift and ASHRShift)
> case, about 25% ~ 30% improvement can be observed, and this benefit is
> introduced by current patch.
> 
> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/SSHL--Signed-Shift-Left--register--
> [2] https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/USHL--Unsigned-Shift-Left--register--
> [3] https://github.com/openjdk/jdk18/pull/41
> [4] https://github.com/openjdk/jdk/pull/1087
> [5] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L509

Hi @dean-long this is the follow-up patch to our previous commit on ARM32. Could you help to review it when you got a chance? Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7724

From thartmann at openjdk.java.net  Mon Mar  7 13:55:05 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 7 Mar 2022 13:55:05 GMT
Subject: RFR: 8278296: Generalize long range check transformation [v7]
In-Reply-To: <5rM8EWPO7RSeKXP1aOtDVtYJv1w5GYGv7mj5AR3A6OA=.f9cb94a8-2894-4e59-a0af-4b5ea72f01e8@github.com>
References: <Khntpfq1O8Ea-1lFIi3di44_E9YmuVsayLDVgc7xV0A=.b4996073-64c1-4cda-b778-d242c06ccc43@github.com>
 <5rM8EWPO7RSeKXP1aOtDVtYJv1w5GYGv7mj5AR3A6OA=.f9cb94a8-2894-4e59-a0af-4b5ea72f01e8@github.com>
Message-ID: <kOSElLrNiylZSXjyqPzHjMU4wG5Ag49yIk-MGkyHNrE=.caf41213-918a-4dbd-8865-ce364e062710@github.com>

On Thu, 3 Mar 2022 09:06:43 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> 8259609 (C2: optimize long range checks in long counted loops) only
>> covered the case of a counted loop with a positive stride and a range
>> check with a positive scale. This change generalizes the long range
>> check transformation to all 4 combinations of stride and scale signs.
>> 
>> The stride > 0, scale > 0 case (covered 8259609) was tweaked so it now
>> uses Qmax computed as the inclusive limit of j*K+Q. That helps in
>> generalizing the formulas to other cases.
>> 
>> The addition of PhaseIdealLoop::is_scaled_iv_plus_extra_offset() was
>> required for the case of negative scale in an int loop. The range
>> check then has the shape:
>> 
>> (CmpUL (AddL (ConvI2L (SubI ConI (LshiftI (Phi
>> 
>> with ConI, the zero constant.
>> 
>> This change also addresses this comment from John:
>> 
>> https://github.com/openjdk/jdk/pull/6576#discussion_r765343664
>> 
>> as part of 8276116 (C2: optimize long range checks in int counted loops)
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   build fix

I gave this a good amount of testing, all passed.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6989

From duke at openjdk.java.net  Mon Mar  7 15:13:31 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Mon, 7 Mar 2022 15:13:31 GMT
Subject: RFR: 8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0)
 failed: Don't process dead nodes
Message-ID: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>

Problem:
Sometimes nodes are generated, and then not properly added to any other node, nor added to the worklist, so that it could be deleted. In some cases, a node can thus survive after IGVN and enter into `ConnectionGraph::compute_escape`, where no dead nodes are expected (except constants).

In `ArrayCopyNode::prepare_array_copy`:
In one, I now add the new ConvI2LNode to the worklist if we are aborting.
In the other case, I could safely reorder the code, such new ConvI2LNode would only be generated once we know we are not going to abort.

In `SubTypeCheckNode::Ideal`:
Replaced `set_req` with `set_req_X`, such that the input-node that is replaced (which is now potentially a dead node) is put on the worklist.

Running running...

-------------

Commit messages:
 - removing zombie catcher
 - Revert "another assert, probably want to fix it or remove it eventually"
 - Revert "adding another sanity check"
 - adding another sanity check
 - another assert, probably want to fix it or remove it eventually
 - fix another case where we may have left dead nodes behind
 - 8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0) failed: Don't process dead nodes

Changes: https://git.openjdk.java.net/jdk/pull/7728/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7728&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282590
  Stats: 20 lines in 2 files changed: 15 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7728.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7728/head:pull/7728

PR: https://git.openjdk.java.net/jdk/pull/7728

From duke at openjdk.java.net  Mon Mar  7 16:25:25 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 7 Mar 2022 16:25:25 GMT
Subject: RFR: 8282509: [AIX] ResolvedTestClass fails on AIX with similar
 output [v3]
In-Reply-To: <5eb3C_3MU09ZBJSPs9ER4fM8u89e7T814CDtRDIdqAY=.04acec75-b1ca-44be-8bb2-140a51ca0a2b@github.com>
References: <5eb3C_3MU09ZBJSPs9ER4fM8u89e7T814CDtRDIdqAY=.04acec75-b1ca-44be-8bb2-140a51ca0a2b@github.com>
Message-ID: <fr5IVsWDcO4aRHv_V7p_D3LZR3IFMvK3GfwrO0iVN3o=.4ef5feb9-0849-4b44-9e8e-314ecaee9449@github.com>

> This is a tentative solution to a failure observed on AIX. The solution is tentative because I require help to ensure that something deeper and more problematic is not happening.
> 
> The test fails because the output produced by PrintCompilation produces `LambdaForm$MH/0x00000007c0002400` instead of `Invokers$Holder` as it does on other platforms. There is one other place the output is different, when `DirectMethodHandle$Holder` is replaced with `LambdaForm$DMH/0x00000007c0001c00`. Ignoring these name changes, the output of PrintCompilation is identical. I observe the same compilations (including the OSR/non-OSR, and same level) in the same order.
> 
> I would be grateful for help understanding the root of the difference behind the change. I have a few ideas, but I will let you build your own interpretations free from my potentially incorrect understanding (i.e. no spoilers). Thanks in advance.

Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Remove leading chars not present in original test
 - Trial Solution: Replaces shouldContain with shouldMatch + Regex in ResolvedClassTest

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7701/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7701&range=02
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7701.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7701/head:pull/7701

PR: https://git.openjdk.java.net/jdk/pull/7701

From roland at openjdk.java.net  Mon Mar  7 16:30:04 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 7 Mar 2022 16:30:04 GMT
Subject: RFR: 8278296: Generalize long range check transformation [v5]
In-Reply-To: <DpjmQlQbMVZoWPmsAuutzQc5HBeVARL5Uv0JsxhoPVc=.aca304be-e3a6-4a0a-a85a-8c3549f787b2@github.com>
References: <Khntpfq1O8Ea-1lFIi3di44_E9YmuVsayLDVgc7xV0A=.b4996073-64c1-4cda-b778-d242c06ccc43@github.com>
 <tQI4zYKoYVc1Izd9libv95_22lImNIyB6hHMsR93Igk=.80fd7bed-2f90-476f-a9ec-2698cc9c2abb@github.com>
 <DpjmQlQbMVZoWPmsAuutzQc5HBeVARL5Uv0JsxhoPVc=.aca304be-e3a6-4a0a-a85a-8c3549f787b2@github.com>
Message-ID: <WD2tw0__tq5HcBXSOi75PNTxsvpEF4i96Ju5BNy-uzQ=.fa092b70-1a97-4024-a766-625d8fb3979f@github.com>

On Wed, 9 Feb 2022 07:40:29 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> Executed some quick testing and the build failed:
> 
> [2022-02-09T07:35:21,066Z] /System/Volumes/Data/mesos/work_dir/slaves/c82600aa-2448-475c-8c08-6f02a5b3f3af-S24361/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a8285c9b-cd39-45ef-ab77-b0841e9ffa80/runs/2f83fde2-cc8b-421e-90d1-b402cd6b2d90/workspace/open/src/hotspot/share/opto/loopTransform.cpp:2574:47: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
> [2022-02-09T07:35:21,066Z]     if (is_iv(exp->in(which = 1), iv, exp_bt) && exp->in(2)->is_Con() ||
> [2022-02-09T07:35:21,066Z]         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~ ~~
> [2022-02-09T07:35:21,066Z] /System/Volumes/Data/mesos/work_dir/slaves/c82600aa-2448-475c-8c08-6f02a5b3f3af-S24361/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a8285c9b-cd39-45ef-ab77-b0841e9ffa80/runs/2f83fde2-cc8b-421e-90d1-b402cd6b2d90/workspace/open/src/hotspot/share/opto/loopTransform.cpp:2574:47: note: place parentheses around the '&&' expression to silence this warning
> [2022-02-09T07:35:21,066Z]     if (is_iv(exp->in(which = 1), iv, exp_bt) && exp->in(2)->is_Con() ||
> [2022-02-09T07:35:21,067Z]                                               ^
> [2022-02-09T07:35:21,067Z]         (                                                            )
> [2022-02-09T07:35:21,067Z] /System/Volumes/Data/mesos/work_dir/slaves/c82600aa-2448-475c-8c08-6f02a5b3f3af-S24361/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a8285c9b-cd39-45ef-ab77-b0841e9ffa80/runs/2f83fde2-cc8b-421e-90d1-b402cd6b2d90/workspace/open/src/hotspot/share/opto/loopTransform.cpp:2575:47: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
> [2022-02-09T07:35:21,067Z]         is_iv(exp->in(which = 2), iv, exp_bt) && exp->in(1)->is_Con()) {
> [2022-02-09T07:35:21,067Z]         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
> [2022-02-09T07:35:21,067Z] /System/Volumes/Data/mesos/work_dir/slaves/c82600aa-2448-475c-8c08-6f02a5b3f3af-S24361/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/a8285c9b-cd39-45ef-ab77-b0841e9ffa80/runs/2f83fde2-cc8b-421e-90d1-b402cd6b2d90/workspace/open/src/hotspot/share/opto/loopTransform.cpp:2575:47: note: place parentheses around the '&&' expression to silence this warning
> [2022-02-09T07:35:21,067Z]         is_iv(exp->in(which = 2), iv, exp_bt) && exp->in(1)->is_Con()) {
> [2022-02-09T07:35:21,067Z]                                               ^

@TobiHartmann thanks for the review/testing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6989

From roland at openjdk.java.net  Mon Mar  7 16:30:05 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 7 Mar 2022 16:30:05 GMT
Subject: Integrated: 8278296: Generalize long range check transformation
In-Reply-To: <Khntpfq1O8Ea-1lFIi3di44_E9YmuVsayLDVgc7xV0A=.b4996073-64c1-4cda-b778-d242c06ccc43@github.com>
References: <Khntpfq1O8Ea-1lFIi3di44_E9YmuVsayLDVgc7xV0A=.b4996073-64c1-4cda-b778-d242c06ccc43@github.com>
Message-ID: <TVNoJGNa2KCSRaY4d-GlIjgJL3S0_4IQVz8UtAfNWhA=.c9c98301-9504-4d90-b728-b7e269863b8f@github.com>

On Fri, 7 Jan 2022 15:18:04 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> 8259609 (C2: optimize long range checks in long counted loops) only
> covered the case of a counted loop with a positive stride and a range
> check with a positive scale. This change generalizes the long range
> check transformation to all 4 combinations of stride and scale signs.
> 
> The stride > 0, scale > 0 case (covered 8259609) was tweaked so it now
> uses Qmax computed as the inclusive limit of j*K+Q. That helps in
> generalizing the formulas to other cases.
> 
> The addition of PhaseIdealLoop::is_scaled_iv_plus_extra_offset() was
> required for the case of negative scale in an int loop. The range
> check then has the shape:
> 
> (CmpUL (AddL (ConvI2L (SubI ConI (LshiftI (Phi
> 
> with ConI, the zero constant.
> 
> This change also addresses this comment from John:
> 
> https://github.com/openjdk/jdk/pull/6576#discussion_r765343664
> 
> as part of 8276116 (C2: optimize long range checks in int counted loops)

This pull request has now been integrated.

Changeset: ef266d77
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ef266d77b6eb54d7e30a0aafd8a3e8c8f4f0e43a
Stats:     723 lines in 7 files changed: 489 ins; 79 del; 155 mod

8278296: Generalize long range check transformation

Reviewed-by: jrose, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/6989

From roland at openjdk.java.net  Mon Mar  7 16:53:45 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 7 Mar 2022 16:53:45 GMT
Subject: RFR: 8281322: irTests/TestLongRangeChecks.java fails with strip
 mining off [v2]
In-Reply-To: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
References: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
Message-ID: <ixA6EHpg9_hXp6PWplszRwrhWVX4g43MZ8DQrIvwNm8=.f8ee5a39-d0f5-42e9-9b07-1b152dd7ee78@github.com>

> Some of the long range check transformations take advantage of the
> safepoint captured by loop strip mining to extract jvm state (in order
> to add back empty predicates to the inner loop of a loop nest). As a
> consequence, irTests/TestLongRangeChecks.java fails with strip mining
> off and users might experience performance anomalies where changing
> GCs affect purely computational code.
> 
> The strip mined loop nest creation is a 2 step process:
> 
> 1- when a CountedLoop is created, an OuterStripMinedLoop is also added
>   but it's not fully constructed
> 
> 2- at macro expansion time, the OuterStripMinedLoop is turned into an
>   actual loop by adding Phis and a proper exit condition
> 
> I propose always doing 1- whether loop strip mining is enabled or
> not. This causes the safepoint to always be captured. Loop strip ming
> is not expected to get in the way of loop transformations so this
> change in itself should be performance neutral. Then at 2-, if loop
> strip mining is not enabled, the OuterStripMinedLoop can be removed
> and the safepoint moved back into the loop in case
> LoopStripMiningIter=1 or simply removed too.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - more
 - Merge branch 'master' into JDK-8281322
 - more
 - cleanup
 - merge fix
 - Merge branch 'master' into JDK-8281322
 - more
 - more
 - more
 - Merge branch 'master' into JDK-8281322
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/5c187e34...a3876c4a

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7364/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7364&range=01
  Stats: 480 lines in 4 files changed: 291 ins; 184 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7364/head:pull/7364

PR: https://git.openjdk.java.net/jdk/pull/7364

From xliu at openjdk.java.net  Mon Mar  7 16:58:06 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 7 Mar 2022 16:58:06 GMT
Subject: RFR: 8282715: typo compileony in test Test8005033.java
In-Reply-To: <3gBRgvg9yAeLR3w927PpdgfjHCG2VVzonrmDOUMryNU=.c18099bc-a71c-4e53-9d97-ee290455a60d@github.com>
References: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
 <3gBRgvg9yAeLR3w927PpdgfjHCG2VVzonrmDOUMryNU=.c18099bc-a71c-4e53-9d97-ee290455a60d@github.com>
Message-ID: <a8Mt2XL3EDvaU6HFrOgM7-AJTfd0D78XB2TZ4ve6Vvg=.257d1e6a-9346-4d8f-a667-8411cf9a0fa5@github.com>

On Mon, 7 Mar 2022 06:00:06 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> This patch doesn't change the testing functionality. It was compiled before. HotSpot failed to handle compiler directive 'compileony'. As a result, it has to compile all methods.  
>> 
>> Here is the warning message
>> 
>> CompileCommand: An error occurred during parsing
>> Error: Unrecognized option 'compileony'
>> Line: 'compileony,compiler.codegen.Test8005033::testBitCount'
>> 
>> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
>> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
>> Use: '-XX:CompileCommand=help' for more information and to list all option.
>> 
>> After correcting the typo, hotspot only compiles the method it is supposed to test. Test time of fastdebug build reduces from 16.778s to 0.226s.
>
> test/hotspot/jtreg/compiler/codegen/Test8005033.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2012, 2022 SAP SE. All rights reserved.
> 
> We'd better not change the copyright line other than Oracle's.
> Maybe, you can start a newline of yours after it.

hi, JIefu, 
Is there a rule for this case? 
I search and found many SAP SE copyright line has [beg, end] years.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7718

From duke at openjdk.java.net  Mon Mar  7 16:56:46 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Mon, 7 Mar 2022 16:56:46 GMT
Subject: RFR: 8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0)
 failed: Don't process dead nodes [v2]
In-Reply-To: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
References: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
Message-ID: <gzm-ehxbHBVU8dbUTEDghmFL91MxGdy80qD8X0d24ag=.f3c746db-8a7e-412a-90f2-6cc3f8c2046b@github.com>

> Problem:
> Sometimes nodes are generated, and then not properly added to any other node, nor added to the worklist, so that it could be deleted. In some cases, a node can thus survive after IGVN and enter into `ConnectionGraph::compute_escape`, where no dead nodes are expected (except constants).
> 
> In `ArrayCopyNode::prepare_array_copy`:
> In one, I now add the new ConvI2LNode to the worklist if we are aborting.
> In the other case, I could safely reorder the code, such new ConvI2LNode would only be generated once we know we are not going to abort.
> 
> In `SubTypeCheckNode::Ideal`:
> Replaced `set_req` with `set_req_X`, such that the input-node that is replaced (which is now potentially a dead node) is put on the worklist.
> 
> Running Tests...
> Wanted to add regression test, but that one now fails sadly.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  added regression test, and fixed a small similar bug as the others

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7728/files
  - new: https://git.openjdk.java.net/jdk/pull/7728/files/513f6ea9..95478505

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7728&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7728&range=00-01

  Stats: 22 lines in 2 files changed: 22 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7728.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7728/head:pull/7728

PR: https://git.openjdk.java.net/jdk/pull/7728

From roland at openjdk.java.net  Mon Mar  7 16:59:05 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 7 Mar 2022 16:59:05 GMT
Subject: RFR: 8281322: C2: always construct strip mined loop initially
 (even if strip mining is disabled) [v2]
In-Reply-To: <ixA6EHpg9_hXp6PWplszRwrhWVX4g43MZ8DQrIvwNm8=.f8ee5a39-d0f5-42e9-9b07-1b152dd7ee78@github.com>
References: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
 <ixA6EHpg9_hXp6PWplszRwrhWVX4g43MZ8DQrIvwNm8=.f8ee5a39-d0f5-42e9-9b07-1b152dd7ee78@github.com>
Message-ID: <WOAbZqe4vari_8mfpv-c5UJWs64grh51mQADxBX6F18=.5b9c3a99-e832-4d33-89dc-fcc1a76d550d@github.com>

On Mon, 7 Mar 2022 16:53:45 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Some of the long range check transformations take advantage of the
>> safepoint captured by loop strip mining to extract jvm state (in order
>> to add back empty predicates to the inner loop of a loop nest). As a
>> consequence, irTests/TestLongRangeChecks.java fails with strip mining
>> off and users might experience performance anomalies where changing
>> GCs affect purely computational code.
>> 
>> The strip mined loop nest creation is a 2 step process:
>> 
>> 1- when a CountedLoop is created, an OuterStripMinedLoop is also added
>>   but it's not fully constructed
>> 
>> 2- at macro expansion time, the OuterStripMinedLoop is turned into an
>>   actual loop by adding Phis and a proper exit condition
>> 
>> I propose always doing 1- whether loop strip mining is enabled or
>> not. This causes the safepoint to always be captured. Loop strip ming
>> is not expected to get in the way of loop transformations so this
>> change in itself should be performance neutral. Then at 2-, if loop
>> strip mining is not enabled, the OuterStripMinedLoop can be removed
>> and the safepoint moved back into the loop in case
>> LoopStripMiningIter=1 or simply removed too.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - more
>  - Merge branch 'master' into JDK-8281322
>  - more
>  - cleanup
>  - merge fix
>  - Merge branch 'master' into JDK-8281322
>  - more
>  - more
>  - more
>  - Merge branch 'master' into JDK-8281322
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/5c187e34...a3876c4a

I pushed a number of new commits that address 3 issues (with LoopStripMiningIter=1):
1- the previous logic would drop nodes pinned on the backedge when the loop nest is transformed back to a single loop.
2- sunk stores need to be moved back into the loop which requires the inner loop's memory graph to be updated. I reused existing logic for that (OuterStripMinedLoopNode::fix_sunk_stores())
3- long counted loop support has a similar transform from a loop nest back to a single counted loop. That transform didn't have part 2 above. I'm not sure if it can cause actually bugs as I expect the counted loop to be transformed back to a loop nest next. In any case, rather than duplicate the logic, I refactored the code so it calls the new OuterStripMinedLoopNode::transform_to_counted_loop() instead. Having it callable from both igvn and loop opts requires some care.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7364

From roland at openjdk.java.net  Mon Mar  7 17:05:19 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 7 Mar 2022 17:05:19 GMT
Subject: RFR: 8281322: C2: always construct strip mined loop initially
 (even if strip mining is disabled) [v3]
In-Reply-To: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
References: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
Message-ID: <mDsYrUL6BZtHcZ6BjmN73Tfu967kTxxeK64bVn-eS4Y=.d2d168c3-9d8a-4e5d-8004-91962361441b@github.com>

> Some of the long range check transformations take advantage of the
> safepoint captured by loop strip mining to extract jvm state (in order
> to add back empty predicates to the inner loop of a loop nest). As a
> consequence, irTests/TestLongRangeChecks.java fails with strip mining
> off and users might experience performance anomalies where changing
> GCs affect purely computational code.
> 
> The strip mined loop nest creation is a 2 step process:
> 
> 1- when a CountedLoop is created, an OuterStripMinedLoop is also added
>   but it's not fully constructed
> 
> 2- at macro expansion time, the OuterStripMinedLoop is turned into an
>   actual loop by adding Phis and a proper exit condition
> 
> I propose always doing 1- whether loop strip mining is enabled or
> not. This causes the safepoint to always be captured. Loop strip ming
> is not expected to get in the way of loop transformations so this
> change in itself should be performance neutral. Then at 2-, if loop
> strip mining is not enabled, the OuterStripMinedLoop can be removed
> and the safepoint moved back into the loop in case
> LoopStripMiningIter=1 or simply removed too.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into JDK-8281322
 - more
 - Merge branch 'master' into JDK-8281322
 - more
 - cleanup
 - merge fix
 - Merge branch 'master' into JDK-8281322
 - more
 - more
 - more
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/ef266d77...e277b7d1

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7364/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7364&range=02
  Stats: 478 lines in 4 files changed: 291 ins; 182 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7364/head:pull/7364

PR: https://git.openjdk.java.net/jdk/pull/7364

From duke at openjdk.java.net  Mon Mar  7 17:12:57 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Mon, 7 Mar 2022 17:12:57 GMT
Subject: RFR: 8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0)
 failed: Don't process dead nodes [v3]
In-Reply-To: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
References: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
Message-ID: <EIZWIYgLTjphT8N2zvdzhVEFezY_gjUlyc1uCNVgipg=.76faac62-c10d-4840-8b49-ce10b1e47d5c@github.com>

> Problem:
> Sometimes nodes are generated, and then not properly added to any other node, nor added to the worklist, so that it could be deleted. In some cases, a node can thus survive after IGVN and enter into `ConnectionGraph::compute_escape`, where no dead nodes are expected (except constants).
> 
> In `ArrayCopyNode::prepare_array_copy`:
> In one, I now add the new ConvI2LNode to the worklist if we are aborting.
> In the other case, I could safely reorder the code, such new ConvI2LNode would only be generated once we know we are not going to abort.
> 
> In `SubTypeCheckNode::Ideal`:
> Replaced `set_req` with `set_req_X`, such that the input-node that is replaced (which is now potentially a dead node) is put on the worklist.
> 
> In `ArrayCopyNode::Ideal`:
> If we decide to `return NULL` we also need to add the potentially dead forward / backward memory nodes to the worklist, they may turn out to be dead.
> 
> Added a regression test: the test + flag combination that first reproduced this issue.
> 
> Tests are running.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  limit it to just the dead cases

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7728/files
  - new: https://git.openjdk.java.net/jdk/pull/7728/files/95478505..da132d29

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7728&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7728&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7728.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7728/head:pull/7728

PR: https://git.openjdk.java.net/jdk/pull/7728

From roland at openjdk.java.net  Mon Mar  7 17:18:39 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 7 Mar 2022 17:18:39 GMT
Subject: RFR: 8281322: C2: always construct strip mined loop initially
 (even if strip mining is disabled) [v4]
In-Reply-To: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
References: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
Message-ID: <Eia1OglOOzTW2plgeEpnnSVvzR0R5ar2tTz8F3VYOnw=.6bf16fe5-694f-4a61-9300-1a661242db85@github.com>

> Some of the long range check transformations take advantage of the
> safepoint captured by loop strip mining to extract jvm state (in order
> to add back empty predicates to the inner loop of a loop nest). As a
> consequence, irTests/TestLongRangeChecks.java fails with strip mining
> off and users might experience performance anomalies where changing
> GCs affect purely computational code.
> 
> The strip mined loop nest creation is a 2 step process:
> 
> 1- when a CountedLoop is created, an OuterStripMinedLoop is also added
>   but it's not fully constructed
> 
> 2- at macro expansion time, the OuterStripMinedLoop is turned into an
>   actual loop by adding Phis and a proper exit condition
> 
> I propose always doing 1- whether loop strip mining is enabled or
> not. This causes the safepoint to always be captured. Loop strip ming
> is not expected to get in the way of loop transformations so this
> change in itself should be performance neutral. Then at 2-, if loop
> strip mining is not enabled, the OuterStripMinedLoop can be removed
> and the safepoint moved back into the loop in case
> LoopStripMiningIter=1 or simply removed too.

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  build fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7364/files
  - new: https://git.openjdk.java.net/jdk/pull/7364/files/e277b7d1..62d8d875

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7364&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7364&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7364/head:pull/7364

PR: https://git.openjdk.java.net/jdk/pull/7364

From psandoz at openjdk.java.net  Mon Mar  7 19:11:08 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 7 Mar 2022 19:11:08 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v8]
In-Reply-To: <vxDwpCRmu3HvXKL8NegsH_wBHLEkJzAFosN5WMyCx0g=.0a147a58-ebe3-42e7-b15e-22b7d6e45e4d@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <vxDwpCRmu3HvXKL8NegsH_wBHLEkJzAFosN5WMyCx0g=.0a147a58-ebe3-42e7-b15e-22b7d6e45e4d@github.com>
Message-ID: <Yc5XzgyEwgOdyG3X_cMXwbJUCaq4XvhqZaxhXOU_5JI=.99896e8c-f398-4bf9-9893-77eaefa0c374@github.com>

On Fri, 4 Mar 2022 20:27:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> 
>> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
>> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
>> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
>> 
>> 
>> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
>> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
>> 
>> Please review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8281375: Review comments resolved.

Tests pass.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From jnimeh at openjdk.java.net  Mon Mar  7 19:40:23 2022
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Mon, 7 Mar 2022 19:40:23 GMT
Subject: RFR: 8282312: Minor corrections to evbroadcasti32x4 intrinsic on x86
Message-ID: <JEl5K9ZEJ2W5v3XqKCpnDwQLofLp_OfIBfPjqg3XRrM=.f05a448c-904d-4313-a5f5-a90ac67fae3b@github.com>

Hello,

This makes a small change to the evbroadcasti32x4 method to make it consistent with the Intel SDM for the vbroadcasti32x4 instruction.  It sets the requirements to AVX512F rather than AVX512DQ, changes the Op/En field to be T4 instead of T2 and sets the width to 32-bits rather than 64.

Hotspot tier1 through 4 tests passed.  I also performed a 100,000 iteration run of the TestChecksum, TestCRC and TestCRC32 regression tests with intrinsics/diagnostics printing turned on so I could see that the methods that call the kernel_crc32_avx512 macro are invoked.

JBS: https://bugs.openjdk.java.net/browse/JDK-8282312

-------------

Commit messages:
 - Merge
 - 8282312: Minor corrections to evbroadcasti32x4 intrinsic on x86

Changes: https://git.openjdk.java.net/jdk/pull/7732/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7732&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282312
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7732.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7732/head:pull/7732

PR: https://git.openjdk.java.net/jdk/pull/7732

From xliu at openjdk.java.net  Mon Mar  7 23:10:38 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 7 Mar 2022 23:10:38 GMT
Subject: RFR: 8282715: typo compileony in test Test8005033.java [v2]
In-Reply-To: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
References: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
Message-ID: <xuREW6RIavBwvPl0le68boZcltygsdDYPVaMVQKpWzg=.a667db74-8506-4675-bbdc-bc75e2f856d7@github.com>

> This patch doesn't change the testing functionality. It was compiled before. HotSpot failed to handle compiler directive 'compileony'. As a result, it has to compile all methods.  
> 
> Here is the warning message
> 
> CompileCommand: An error occurred during parsing
> Error: Unrecognized option 'compileony'
> Line: 'compileony,compiler.codegen.Test8005033::testBitCount'
> 
> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
> Use: '-XX:CompileCommand=help' for more information and to list all option.
> 
> After correcting the typo, hotspot only compiles the method it is supposed to test. Test time of fastdebug build reduces from 16.778s to 0.226s.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  avoid changing the copyright header of SAP.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7718/files
  - new: https://git.openjdk.java.net/jdk/pull/7718/files/0babec73..95d20e4e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7718&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7718&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7718.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7718/head:pull/7718

PR: https://git.openjdk.java.net/jdk/pull/7718

From xliu at openjdk.java.net  Mon Mar  7 23:15:04 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 7 Mar 2022 23:15:04 GMT
Subject: RFR: 8282715: typo compileony in test Test8005033.java [v2]
In-Reply-To: <3gBRgvg9yAeLR3w927PpdgfjHCG2VVzonrmDOUMryNU=.c18099bc-a71c-4e53-9d97-ee290455a60d@github.com>
References: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
 <3gBRgvg9yAeLR3w927PpdgfjHCG2VVzonrmDOUMryNU=.c18099bc-a71c-4e53-9d97-ee290455a60d@github.com>
Message-ID: <dmG5VpCMh3zo5xqhIb4LQRuhzM12Rx03QQzYTHB4-2I=.d493b875-8fc7-40ce-8b02-aad0ca7f69f8@github.com>

On Mon, 7 Mar 2022 06:00:06 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   avoid changing the copyright header of SAP.
>
> test/hotspot/jtreg/compiler/codegen/Test8005033.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2012, 2022 SAP SE. All rights reserved.
> 
> We'd better not change the copyright line other than Oracle's.
> Maybe, you can start a newline of yours after it.

hi, @DamonFool , 

Now I think I understand your concern. OCA says that contributors share their rights with Oracle.  I am not Oracle. I don't have permission to change other people's copyright headers.  I revert that and use ours. is that okay now? 

thanks,
--lx

-------------

PR: https://git.openjdk.java.net/jdk/pull/7718

From psandoz at openjdk.java.net  Mon Mar  7 23:27:07 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 7 Mar 2022 23:27:07 GMT
Subject: RFR: 8282665: [REDO] ByteBufferTest.java: replace endless
 recursion with RuntimeException in void ck(double x, double y) [v2]
In-Reply-To: <-34q5-7FfYMtgEgjaQabZtD0Bt4Hvnvk2bRJLeq_YU8=.1c90c5fb-87b7-4cd1-9079-b8e711e4b3ce@github.com>
References: <GkxbMy2Qw-zKDCZCsv759XPa6iluwVBQVGssKijyPi4=.10562a25-43af-412c-8489-43249076ff8d@github.com>
 <-34q5-7FfYMtgEgjaQabZtD0Bt4Hvnvk2bRJLeq_YU8=.1c90c5fb-87b7-4cd1-9079-b8e711e4b3ce@github.com>
Message-ID: <-U9x_GWkbm1YJd5O7OVMW81kGf4cxV7oh7OxHH0KFpU=.10dfbdc5-2821-48de-8eec-864d4fe5c66b@github.com>

On Mon, 7 Mar 2022 10:25:47 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> Until now, ck for doubles ignored the case when either x or y was NaN, it for example would let pass x=NaN and y=2.0.
>> Further, instead of throwing an exception, it went into infinite recursion, with an eventual StackOverflowError.
>> Now, we throw an exception that prints the values. I fixed the logic, and added an explanation.
>> 
>> All tests are passing.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   state reason for failure in Exception

I wonder if we can simplify and replace the test with `Double.compare(x, y) != 0`? Can you test that?

That introduces a new condition since `-0.0 == 0.0` is `true` (yes, another odd difference!) where as `Double.compare(-0.0, 0.0) != 0`

-------------

PR: https://git.openjdk.java.net/jdk/pull/7723

From jiefu at openjdk.java.net  Mon Mar  7 23:44:58 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 7 Mar 2022 23:44:58 GMT
Subject: RFR: 8282715: typo compileony in test Test8005033.java [v2]
In-Reply-To: <xuREW6RIavBwvPl0le68boZcltygsdDYPVaMVQKpWzg=.a667db74-8506-4675-bbdc-bc75e2f856d7@github.com>
References: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
 <xuREW6RIavBwvPl0le68boZcltygsdDYPVaMVQKpWzg=.a667db74-8506-4675-bbdc-bc75e2f856d7@github.com>
Message-ID: <XUettF3tEMXg72IMYqmS_BHgHeez7O3iCzVmkZlXfik=.f650b493-dc8a-499f-8d6e-ebe6a24758a9@github.com>

On Mon, 7 Mar 2022 23:10:38 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch doesn't change the testing functionality. It was compiled before. HotSpot failed to handle compiler directive 'compileony'. As a result, it has to compile all methods.  
>> 
>> Here is the warning message
>> 
>> CompileCommand: An error occurred during parsing
>> Error: Unrecognized option 'compileony'
>> Line: 'compileony,compiler.codegen.Test8005033::testBitCount'
>> 
>> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
>> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
>> Use: '-XX:CompileCommand=help' for more information and to list all option.
>> 
>> After correcting the typo, hotspot only compiles the method it is supposed to test. Test time of fastdebug build reduces from 16.778s to 0.226s.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   avoid changing the copyright header of SAP.

test/hotspot/jtreg/compiler/codegen/Test8005033.java line 2:

> 1: /*
> 2:  * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.

Since this file was first created by SAP, I would suggest adding yours after SAP's copyright line.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7718

From xliu at openjdk.java.net  Tue Mar  8 00:24:50 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 8 Mar 2022 00:24:50 GMT
Subject: RFR: 8282715: typo compileony in test Test8005033.java [v3]
In-Reply-To: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
References: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
Message-ID: <GaNu_h3CfBH0i7xbR8b4EFwanwNg1Y4UkIsMD-eOGKk=.6987f5bc-51a5-4260-ab01-704b7ef23c58@github.com>

> This patch doesn't change the testing functionality. It was compiled before. HotSpot failed to handle compiler directive 'compileony'. As a result, it has to compile all methods.  
> 
> Here is the warning message
> 
> CompileCommand: An error occurred during parsing
> Error: Unrecognized option 'compileony'
> Line: 'compileony,compiler.codegen.Test8005033::testBitCount'
> 
> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
> Use: '-XX:CompileCommand=help' for more information and to list all option.
> 
> After correcting the typo, hotspot only compiles the method it is supposed to test. Test time of fastdebug build reduces from 16.778s to 0.226s.

Xin Liu has updated the pull request incrementally with one additional commit since the last revision:

  put our copyright header behind the original author's.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7718/files
  - new: https://git.openjdk.java.net/jdk/pull/7718/files/95d20e4e..b92c2db2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7718&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7718&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7718.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7718/head:pull/7718

PR: https://git.openjdk.java.net/jdk/pull/7718

From jiefu at openjdk.java.net  Tue Mar  8 01:19:03 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 8 Mar 2022 01:19:03 GMT
Subject: RFR: 8282715: typo compileony in test Test8005033.java [v3]
In-Reply-To: <GaNu_h3CfBH0i7xbR8b4EFwanwNg1Y4UkIsMD-eOGKk=.6987f5bc-51a5-4260-ab01-704b7ef23c58@github.com>
References: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
 <GaNu_h3CfBH0i7xbR8b4EFwanwNg1Y4UkIsMD-eOGKk=.6987f5bc-51a5-4260-ab01-704b7ef23c58@github.com>
Message-ID: <Z4xq_uTDVyk24H4s0DY3WUyFzVJv_ozJT-GvJdZBFIw=.8f1ae574-ed11-4e60-9292-b362e3be9210@github.com>

On Tue, 8 Mar 2022 00:24:50 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch doesn't change the testing functionality. It was compiled before. HotSpot failed to handle compiler directive 'compileony'. As a result, it has to compile all methods.  
>> 
>> Here is the warning message
>> 
>> CompileCommand: An error occurred during parsing
>> Error: Unrecognized option 'compileony'
>> Line: 'compileony,compiler.codegen.Test8005033::testBitCount'
>> 
>> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
>> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
>> Use: '-XX:CompileCommand=help' for more information and to list all option.
>> 
>> After correcting the typo, hotspot only compiles the method it is supposed to test. Test time of fastdebug build reduces from 16.778s to 0.226s.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   put our copyright header behind the original author's.

Looks good and trivial.
Thanks for fixing it.

-------------

Marked as reviewed by jiefu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7718

From jbhateja at openjdk.java.net  Tue Mar  8 01:36:08 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 8 Mar 2022 01:36:08 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v8]
In-Reply-To: <Yc5XzgyEwgOdyG3X_cMXwbJUCaq4XvhqZaxhXOU_5JI=.99896e8c-f398-4bf9-9893-77eaefa0c374@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <vxDwpCRmu3HvXKL8NegsH_wBHLEkJzAFosN5WMyCx0g=.0a147a58-ebe3-42e7-b15e-22b7d6e45e4d@github.com>
 <Yc5XzgyEwgOdyG3X_cMXwbJUCaq4XvhqZaxhXOU_5JI=.99896e8c-f398-4bf9-9893-77eaefa0c374@github.com>
Message-ID: <NyhSShcx0Uytr1Hx2_EfzcYOiASC0l93ingNDna9zjg=.cc955b10-7d45-41f3-a03c-5057930a9441@github.com>

On Mon, 7 Mar 2022 19:08:11 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Tests pass.

Thanks @PaulSandoz. X86 backend changes have been reviewed by @sviswa7, do we need second approval on this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From dlong at openjdk.java.net  Tue Mar  8 02:21:59 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 8 Mar 2022 02:21:59 GMT
Subject: RFR: 8282312: Minor corrections to evbroadcasti32x4 intrinsic on
 x86
In-Reply-To: <JEl5K9ZEJ2W5v3XqKCpnDwQLofLp_OfIBfPjqg3XRrM=.f05a448c-904d-4313-a5f5-a90ac67fae3b@github.com>
References: <JEl5K9ZEJ2W5v3XqKCpnDwQLofLp_OfIBfPjqg3XRrM=.f05a448c-904d-4313-a5f5-a90ac67fae3b@github.com>
Message-ID: <qIpyV2npVUsJenT5rja7QfZGtAbrJeGW1xUIb-uxGBU=.13fecabf-3a2d-4b79-8ca0-64e8b3c42f2b@github.com>

On Mon, 7 Mar 2022 18:08:25 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> Hello,
> 
> This makes a small change to the evbroadcasti32x4 method to make it consistent with the Intel SDM for the vbroadcasti32x4 instruction.  It sets the requirements to AVX512F rather than AVX512DQ, changes the Op/En field to be T4 instead of T2 and sets the width to 32-bits rather than 64.
> 
> Hotspot tier1 through 4 tests passed.  I also performed a 100,000 iteration run of the TestChecksum, TestCRC and TestCRC32 regression tests with intrinsics/diagnostics printing turned on so I could see that the methods that call the kernel_crc32_avx512 macro are invoked.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8282312

Looks good.

-------------

Marked as reviewed by dlong (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7732

From dlong at openjdk.java.net  Tue Mar  8 03:43:06 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 8 Mar 2022 03:43:06 GMT
Subject: RFR: 8265263: AArch64: Combine vneg with right shift count
In-Reply-To: <6APGll3m5cYjHelXsVqrfzEmzUaiTBHQHZOlsB2C1OM=.0d34fc7f-4b0a-430d-b519-336a34969efc@github.com>
References: <6APGll3m5cYjHelXsVqrfzEmzUaiTBHQHZOlsB2C1OM=.0d34fc7f-4b0a-430d-b519-336a34969efc@github.com>
Message-ID: <jMBPSolCmoiv9hB09HOMytUEh7w_nMT1eU28JoOluDk=.587d50f7-e6af-4bf6-a2a8-4cf32d0b970d@github.com>

On Mon, 7 Mar 2022 08:46:12 GMT, Hao Sun <haosun at openjdk.org> wrote:

> ### Implementation
> 
> In AArch64 NEON, vector shift right is implemented by vector shift left
> instructions (SSHL[1] and USHL[2]) with negative shift count value. In
> C2 backend, we generate a `neg` to given shift value followed by `sshl`
> or `ushl` instruction.
> 
> For vector shift right, the vector shift count has two origins:
> 1) it can be duplicated from scalar variable/immediate(case-1),
> 2) it can be loaded directly from one vector(case-2).
> 
> This patch aims to optimize case-1. Specifically, we move the negate
> from RShiftV* rules to RShiftCntV rule. As a result, the negate can be
> hoisted outside of the loop if it's a loop invariant.
> 
> In this patch,
> 1) we split vshiftcnt* rules into vslcnt* and vsrcnt* rules to handle
> shift left and shift right respectively. Compared to vslcnt* rules, the
> negate is conducted in vsrcnt*.
> 2) for each vsra* and vsrl* rules, we create one variant, i.e. vsra*_var
> and vsrl*_var. We use vsra* and vsrl* rules to handle case-1, and use
> vsra*_var and vsrl*_var rules to handle case-2. Note that
> ShiftVNode::is_var_shift() can be used to distinguish case-1 from
> case-2.
> 3) we add one assertion for the vs*_imm rules as we have done on
> ARM32[3].
> 4) several style issues are resolved.
> 
> ### Example
> 
> Take function `rShiftInt()` in the newly added micro benchmark
> VectorShiftRight.java as an example.
> 
> 
> public void rShiftInt() {
>     for (int i = 0; i < SIZE; i++) {
>         intsB[i] = intsA[i] >> count;
>     }
> }
> 
> 
> Arithmetic shift right is conducted inside a big loop. The following
> code snippet shows the disassembly code generated by auto-vectorization
> before we apply current patch. We can see that `neg` is conducted in the
> loop body.
> 
> 
> 0x0000ffff89057a64:   dup     v16.16b, w13              <-- dup
> 0x0000ffff89057a68:   mov     w12, #0x7d00                    // #32000
> 0x0000ffff89057a6c:   sub     w13, w2, w10
> 0x0000ffff89057a70:   cmp     w2, w10
> 0x0000ffff89057a74:   csel    w13, wzr, w13, lt
> 0x0000ffff89057a78:   mov     w8, #0x7d00                     // #32000
> 0x0000ffff89057a7c:   cmp     w13, w8
> 0x0000ffff89057a80:   csel    w13, w12, w13, hi
> 0x0000ffff89057a84:   add     w14, w13, w10
> 0x0000ffff89057a88:   nop
> 0x0000ffff89057a8c:   nop
> 0x0000ffff89057a90:   sbfiz   x13, x10, #2, #32         <-- loop entry
> 0x0000ffff89057a94:   add     x15, x17, x13
> 0x0000ffff89057a98:   ldr     q17, [x15,#16]
> 0x0000ffff89057a9c:   add     x13, x0, x13
> 0x0000ffff89057aa0:   neg     v18.16b, v16.16b          <-- neg
> 0x0000ffff89057aa4:   sshl    v17.4s, v17.4s, v18.4s    <-- shift right
> 0x0000ffff89057aa8:   str     q17, [x13,#16]
> 0x0000ffff89057aac:   ...
> 0x0000ffff89057b1c:   add     w10, w10, #0x20
> 0x0000ffff89057b20:   cmp     w10, w14
> 0x0000ffff89057b24:   b.lt    0x0000ffff89057a90        <-- loop end
> 
> 
> Here is the disassembly code after we apply current patch. We can see
> that the negate is no longer conducted inside the loop, and it is
> hoisted to the outside.
> 
> 
> 0x0000ffff8d053a68:   neg     w14, w13                  <---- neg
> 0x0000ffff8d053a6c:   dup     v16.16b, w14              <---- dup
> 0x0000ffff8d053a70:   sub     w14, w2, w10
> 0x0000ffff8d053a74:   cmp     w2, w10
> 0x0000ffff8d053a78:   csel    w14, wzr, w14, lt
> 0x0000ffff8d053a7c:   mov     w8, #0x7d00                     // #32000
> 0x0000ffff8d053a80:   cmp     w14, w8
> 0x0000ffff8d053a84:   csel    w14, w12, w14, hi
> 0x0000ffff8d053a88:   add     w13, w14, w10
> 0x0000ffff8d053a8c:   nop
> 0x0000ffff8d053a90:   sbfiz   x14, x10, #2, #32         <-- loop entry
> 0x0000ffff8d053a94:   add     x15, x17, x14
> 0x0000ffff8d053a98:   ldr     q17, [x15,#16]
> 0x0000ffff8d053a9c:   sshl    v17.4s, v17.4s, v16.4s    <-- shift right
> 0x0000ffff8d053aa0:   add     x14, x0, x14
> 0x0000ffff8d053aa4:   str     q17, [x14,#16]
> 0x0000ffff8d053aa8:   ...
> 0x0000ffff8d053afc:   add     w10, w10, #0x20
> 0x0000ffff8d053b00:   cmp     w10, w13
> 0x0000ffff8d053b04:   b.lt    0x0000ffff8d053a90        <-- loop end
> 
> 
> ### Testing
> 
> Tier1~3 tests passed on Linux/AArch64 platform.
> 
> ### Performance Evaluation
> 
> - Auto-vectorization
> 
> One micro benchmark, i.e. VectorShiftRight.java, is added by this patch
> in order to evaluate the optimization on vector shift right.
> 
> The following table shows the result. Column `Score-1` shows the score
> before we apply current patch, and column `Score-2` shows the score when
> we apply current patch.
> 
> We witness about 30% ~ 53% improvement on microbenchmarks.
> 
> 
> Benchmark                      Units    Score-1    Score-2
> VectorShiftRight.rShiftByte   ops/ms  10601.980  13816.353
> VectorShiftRight.rShiftInt    ops/ms   3592.831   5502.941
> VectorShiftRight.rShiftLong   ops/ms   1584.012   2425.247
> VectorShiftRight.rShiftShort  ops/ms   6643.414   9728.762
> VectorShiftRight.urShiftByte  ops/ms   2066.965   2048.336 (*)
> VectorShiftRight.urShiftChar  ops/ms   6660.805   9728.478
> VectorShiftRight.urShiftInt   ops/ms   3592.909   5514.928
> VectorShiftRight.urShiftLong  ops/ms   1583.995   2422.991
> 
> *: Logical shift right for Byte type(urShiftByte) is not vectorized, as
> disscussed in [4].
> 
> 
> - VectorAPI
> 
> Furthermore, we also evaluate the impact of this patch on VectorAPI
> benchmarks, e.g., [5]. Details can be found in the table below. Columns
> `Score-1` and `Score-2` show the scores before and after applying
> current patch.
> 
> 
> Benchmark                  Units    Score-1    Score-2
> Byte128Vector.LSHL        ops/ms  10867.666  10873.993
> Byte128Vector.LSHLShift   ops/ms  10945.729  10945.741
> Byte128Vector.LSHR        ops/ms   8629.305   8629.343
> Byte128Vector.LSHRShift   ops/ms   8245.864  10303.521   <--
> Byte128Vector.ASHR        ops/ms   8619.691   8629.438
> Byte128Vector.ASHRShift   ops/ms   8245.860  10305.027   <--
> Int128Vector.LSHL         ops/ms   3104.213   3103.702
> Int128Vector.LSHLShift    ops/ms   3114.354   3114.371
> Int128Vector.LSHR         ops/ms   2380.717   2380.693
> Int128Vector.LSHRShift    ops/ms   2312.871   2992.377   <--
> Int128Vector.ASHR         ops/ms   2380.668   2380.647
> Int128Vector.ASHRShift    ops/ms   2312.894   2992.332   <--
> Long128Vector.LSHL        ops/ms   1586.907   1587.591
> Long128Vector.LSHLShift   ops/ms   1589.469   1589.540
> Long128Vector.LSHR        ops/ms   1209.754   1209.687
> Long128Vector.LSHRShift   ops/ms   1174.718   1527.502   <--
> Long128Vector.ASHR        ops/ms   1209.713   1209.669
> Long128Vector.ASHRShift   ops/ms   1174.712   1527.174   <--
> Short128Vector.LSHL       ops/ms   5945.542   5943.770
> Short128Vector.LSHLShift  ops/ms   5984.743   5984.640
> Short128Vector.LSHR       ops/ms   4613.378   4613.577
> Short128Vector.LSHRShift  ops/ms   4486.023   5746.466   <--
> Short128Vector.ASHR       ops/ms   4613.389   4613.478
> Short128Vector.ASHRShift  ops/ms   4486.019   5746.368   <--
> 
> 
> 1) For logical shift left(LSHL and LSHLShift), and shift right with
> variable vector shift count(LSHR and ASHR) cases, we didn't find much
> changes, which is expected.
> 
> 2) For shift right with scalar shift count(LSHRShift and ASHRShift)
> case, about 25% ~ 30% improvement can be observed, and this benefit is
> introduced by current patch.
> 
> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/SSHL--Signed-Shift-Left--register--
> [2] https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/USHL--Unsigned-Shift-Left--register--
> [3] https://github.com/openjdk/jdk18/pull/41
> [4] https://github.com/openjdk/jdk/pull/1087
> [5] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L509

Marked as reviewed by dlong (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7724

From haosun at openjdk.java.net  Tue Mar  8 03:52:05 2022
From: haosun at openjdk.java.net (Hao Sun)
Date: Tue, 8 Mar 2022 03:52:05 GMT
Subject: RFR: 8265263: AArch64: Combine vneg with right shift count
In-Reply-To: <6APGll3m5cYjHelXsVqrfzEmzUaiTBHQHZOlsB2C1OM=.0d34fc7f-4b0a-430d-b519-336a34969efc@github.com>
References: <6APGll3m5cYjHelXsVqrfzEmzUaiTBHQHZOlsB2C1OM=.0d34fc7f-4b0a-430d-b519-336a34969efc@github.com>
Message-ID: <9lJ0sPgaIFdynDhWoHvKsTB3uWlPfyjeDVvsSO7WE-c=.217762fc-60ba-491e-a87a-cba5f92e8408@github.com>

On Mon, 7 Mar 2022 08:46:12 GMT, Hao Sun <haosun at openjdk.org> wrote:

> ### Implementation
> 
> In AArch64 NEON, vector shift right is implemented by vector shift left
> instructions (SSHL[1] and USHL[2]) with negative shift count value. In
> C2 backend, we generate a `neg` to given shift value followed by `sshl`
> or `ushl` instruction.
> 
> For vector shift right, the vector shift count has two origins:
> 1) it can be duplicated from scalar variable/immediate(case-1),
> 2) it can be loaded directly from one vector(case-2).
> 
> This patch aims to optimize case-1. Specifically, we move the negate
> from RShiftV* rules to RShiftCntV rule. As a result, the negate can be
> hoisted outside of the loop if it's a loop invariant.
> 
> In this patch,
> 1) we split vshiftcnt* rules into vslcnt* and vsrcnt* rules to handle
> shift left and shift right respectively. Compared to vslcnt* rules, the
> negate is conducted in vsrcnt*.
> 2) for each vsra* and vsrl* rules, we create one variant, i.e. vsra*_var
> and vsrl*_var. We use vsra* and vsrl* rules to handle case-1, and use
> vsra*_var and vsrl*_var rules to handle case-2. Note that
> ShiftVNode::is_var_shift() can be used to distinguish case-1 from
> case-2.
> 3) we add one assertion for the vs*_imm rules as we have done on
> ARM32[3].
> 4) several style issues are resolved.
> 
> ### Example
> 
> Take function `rShiftInt()` in the newly added micro benchmark
> VectorShiftRight.java as an example.
> 
> 
> public void rShiftInt() {
>     for (int i = 0; i < SIZE; i++) {
>         intsB[i] = intsA[i] >> count;
>     }
> }
> 
> 
> Arithmetic shift right is conducted inside a big loop. The following
> code snippet shows the disassembly code generated by auto-vectorization
> before we apply current patch. We can see that `neg` is conducted in the
> loop body.
> 
> 
> 0x0000ffff89057a64:   dup     v16.16b, w13              <-- dup
> 0x0000ffff89057a68:   mov     w12, #0x7d00                    // #32000
> 0x0000ffff89057a6c:   sub     w13, w2, w10
> 0x0000ffff89057a70:   cmp     w2, w10
> 0x0000ffff89057a74:   csel    w13, wzr, w13, lt
> 0x0000ffff89057a78:   mov     w8, #0x7d00                     // #32000
> 0x0000ffff89057a7c:   cmp     w13, w8
> 0x0000ffff89057a80:   csel    w13, w12, w13, hi
> 0x0000ffff89057a84:   add     w14, w13, w10
> 0x0000ffff89057a88:   nop
> 0x0000ffff89057a8c:   nop
> 0x0000ffff89057a90:   sbfiz   x13, x10, #2, #32         <-- loop entry
> 0x0000ffff89057a94:   add     x15, x17, x13
> 0x0000ffff89057a98:   ldr     q17, [x15,#16]
> 0x0000ffff89057a9c:   add     x13, x0, x13
> 0x0000ffff89057aa0:   neg     v18.16b, v16.16b          <-- neg
> 0x0000ffff89057aa4:   sshl    v17.4s, v17.4s, v18.4s    <-- shift right
> 0x0000ffff89057aa8:   str     q17, [x13,#16]
> 0x0000ffff89057aac:   ...
> 0x0000ffff89057b1c:   add     w10, w10, #0x20
> 0x0000ffff89057b20:   cmp     w10, w14
> 0x0000ffff89057b24:   b.lt    0x0000ffff89057a90        <-- loop end
> 
> 
> Here is the disassembly code after we apply current patch. We can see
> that the negate is no longer conducted inside the loop, and it is
> hoisted to the outside.
> 
> 
> 0x0000ffff8d053a68:   neg     w14, w13                  <---- neg
> 0x0000ffff8d053a6c:   dup     v16.16b, w14              <---- dup
> 0x0000ffff8d053a70:   sub     w14, w2, w10
> 0x0000ffff8d053a74:   cmp     w2, w10
> 0x0000ffff8d053a78:   csel    w14, wzr, w14, lt
> 0x0000ffff8d053a7c:   mov     w8, #0x7d00                     // #32000
> 0x0000ffff8d053a80:   cmp     w14, w8
> 0x0000ffff8d053a84:   csel    w14, w12, w14, hi
> 0x0000ffff8d053a88:   add     w13, w14, w10
> 0x0000ffff8d053a8c:   nop
> 0x0000ffff8d053a90:   sbfiz   x14, x10, #2, #32         <-- loop entry
> 0x0000ffff8d053a94:   add     x15, x17, x14
> 0x0000ffff8d053a98:   ldr     q17, [x15,#16]
> 0x0000ffff8d053a9c:   sshl    v17.4s, v17.4s, v16.4s    <-- shift right
> 0x0000ffff8d053aa0:   add     x14, x0, x14
> 0x0000ffff8d053aa4:   str     q17, [x14,#16]
> 0x0000ffff8d053aa8:   ...
> 0x0000ffff8d053afc:   add     w10, w10, #0x20
> 0x0000ffff8d053b00:   cmp     w10, w13
> 0x0000ffff8d053b04:   b.lt    0x0000ffff8d053a90        <-- loop end
> 
> 
> ### Testing
> 
> Tier1~3 tests passed on Linux/AArch64 platform.
> 
> ### Performance Evaluation
> 
> - Auto-vectorization
> 
> One micro benchmark, i.e. VectorShiftRight.java, is added by this patch
> in order to evaluate the optimization on vector shift right.
> 
> The following table shows the result. Column `Score-1` shows the score
> before we apply current patch, and column `Score-2` shows the score when
> we apply current patch.
> 
> We witness about 30% ~ 53% improvement on microbenchmarks.
> 
> 
> Benchmark                      Units    Score-1    Score-2
> VectorShiftRight.rShiftByte   ops/ms  10601.980  13816.353
> VectorShiftRight.rShiftInt    ops/ms   3592.831   5502.941
> VectorShiftRight.rShiftLong   ops/ms   1584.012   2425.247
> VectorShiftRight.rShiftShort  ops/ms   6643.414   9728.762
> VectorShiftRight.urShiftByte  ops/ms   2066.965   2048.336 (*)
> VectorShiftRight.urShiftChar  ops/ms   6660.805   9728.478
> VectorShiftRight.urShiftInt   ops/ms   3592.909   5514.928
> VectorShiftRight.urShiftLong  ops/ms   1583.995   2422.991
> 
> *: Logical shift right for Byte type(urShiftByte) is not vectorized, as
> disscussed in [4].
> 
> 
> - VectorAPI
> 
> Furthermore, we also evaluate the impact of this patch on VectorAPI
> benchmarks, e.g., [5]. Details can be found in the table below. Columns
> `Score-1` and `Score-2` show the scores before and after applying
> current patch.
> 
> 
> Benchmark                  Units    Score-1    Score-2
> Byte128Vector.LSHL        ops/ms  10867.666  10873.993
> Byte128Vector.LSHLShift   ops/ms  10945.729  10945.741
> Byte128Vector.LSHR        ops/ms   8629.305   8629.343
> Byte128Vector.LSHRShift   ops/ms   8245.864  10303.521   <--
> Byte128Vector.ASHR        ops/ms   8619.691   8629.438
> Byte128Vector.ASHRShift   ops/ms   8245.860  10305.027   <--
> Int128Vector.LSHL         ops/ms   3104.213   3103.702
> Int128Vector.LSHLShift    ops/ms   3114.354   3114.371
> Int128Vector.LSHR         ops/ms   2380.717   2380.693
> Int128Vector.LSHRShift    ops/ms   2312.871   2992.377   <--
> Int128Vector.ASHR         ops/ms   2380.668   2380.647
> Int128Vector.ASHRShift    ops/ms   2312.894   2992.332   <--
> Long128Vector.LSHL        ops/ms   1586.907   1587.591
> Long128Vector.LSHLShift   ops/ms   1589.469   1589.540
> Long128Vector.LSHR        ops/ms   1209.754   1209.687
> Long128Vector.LSHRShift   ops/ms   1174.718   1527.502   <--
> Long128Vector.ASHR        ops/ms   1209.713   1209.669
> Long128Vector.ASHRShift   ops/ms   1174.712   1527.174   <--
> Short128Vector.LSHL       ops/ms   5945.542   5943.770
> Short128Vector.LSHLShift  ops/ms   5984.743   5984.640
> Short128Vector.LSHR       ops/ms   4613.378   4613.577
> Short128Vector.LSHRShift  ops/ms   4486.023   5746.466   <--
> Short128Vector.ASHR       ops/ms   4613.389   4613.478
> Short128Vector.ASHRShift  ops/ms   4486.019   5746.368   <--
> 
> 
> 1) For logical shift left(LSHL and LSHLShift), and shift right with
> variable vector shift count(LSHR and ASHR) cases, we didn't find much
> changes, which is expected.
> 
> 2) For shift right with scalar shift count(LSHRShift and ASHRShift)
> case, about 25% ~ 30% improvement can be observed, and this benefit is
> introduced by current patch.
> 
> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/SSHL--Signed-Shift-Left--register--
> [2] https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/USHL--Unsigned-Shift-Left--register--
> [3] https://github.com/openjdk/jdk18/pull/41
> [4] https://github.com/openjdk/jdk/pull/1087
> [5] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L509

Thanks a lot for your review!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7724

From dholmes at openjdk.java.net  Tue Mar  8 04:51:02 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Mar 2022 04:51:02 GMT
Subject: RFR: 8282715: typo compileony in test Test8005033.java [v3]
In-Reply-To: <GaNu_h3CfBH0i7xbR8b4EFwanwNg1Y4UkIsMD-eOGKk=.6987f5bc-51a5-4260-ab01-704b7ef23c58@github.com>
References: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
 <GaNu_h3CfBH0i7xbR8b4EFwanwNg1Y4UkIsMD-eOGKk=.6987f5bc-51a5-4260-ab01-704b7ef23c58@github.com>
Message-ID: <jzRZIK18foLilUhJEIhmRBkjDyDFK-lpvzffR-Hx_4s=.e0ec709a-9361-4748-91fc-fc931112b8fa@github.com>

On Tue, 8 Mar 2022 00:24:50 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch doesn't change the testing functionality. It was compiled before. HotSpot failed to handle compiler directive 'compileony'. As a result, it has to compile all methods.  
>> 
>> Here is the warning message
>> 
>> CompileCommand: An error occurred during parsing
>> Error: Unrecognized option 'compileony'
>> Line: 'compileony,compiler.codegen.Test8005033::testBitCount'
>> 
>> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
>> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
>> Use: '-XX:CompileCommand=help' for more information and to list all option.
>> 
>> After correcting the typo, hotspot only compiles the method it is supposed to test. Test time of fastdebug build reduces from 16.778s to 0.226s.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   put our copyright header behind the original author's.

The fix is good but I still don't understands why we don't see the test fail with:

CompileCommand: An error occurred during parsing
Error: Unrecognized option 'compileony'
Line: 'compileony,compiler.codegen.Test8005033::testBitCount' 

??

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7718

From dholmes at openjdk.java.net  Tue Mar  8 04:51:02 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Mar 2022 04:51:02 GMT
Subject: RFR: 8282715: typo compileony in test Test8005033.java [v2]
In-Reply-To: <XUettF3tEMXg72IMYqmS_BHgHeez7O3iCzVmkZlXfik=.f650b493-dc8a-499f-8d6e-ebe6a24758a9@github.com>
References: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
 <xuREW6RIavBwvPl0le68boZcltygsdDYPVaMVQKpWzg=.a667db74-8506-4675-bbdc-bc75e2f856d7@github.com>
 <XUettF3tEMXg72IMYqmS_BHgHeez7O3iCzVmkZlXfik=.f650b493-dc8a-499f-8d6e-ebe6a24758a9@github.com>
Message-ID: <K0OFL6gvmrmRmJzXMtHUruOzEUX2HmsWSyX72eUwKJg=.e096266c-1ee6-4552-9cd7-3a4dd0e95e1d@github.com>

On Mon, 7 Mar 2022 23:42:14 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   avoid changing the copyright header of SAP.
>
> test/hotspot/jtreg/compiler/codegen/Test8005033.java line 2:
> 
>> 1: /*
>> 2:  * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
> 
> Since this file was first created by SAP, I would suggest adding yours after SAP's copyright line.
> Thanks.

IANAL But a simple typo fix doesn't seem worthy of a copyright claim.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7718

From jnimeh at openjdk.java.net  Tue Mar  8 05:54:01 2022
From: jnimeh at openjdk.java.net (Jamil Nimeh)
Date: Tue, 8 Mar 2022 05:54:01 GMT
Subject: Integrated: 8282312: Minor corrections to evbroadcasti32x4 intrinsic
 on x86
In-Reply-To: <JEl5K9ZEJ2W5v3XqKCpnDwQLofLp_OfIBfPjqg3XRrM=.f05a448c-904d-4313-a5f5-a90ac67fae3b@github.com>
References: <JEl5K9ZEJ2W5v3XqKCpnDwQLofLp_OfIBfPjqg3XRrM=.f05a448c-904d-4313-a5f5-a90ac67fae3b@github.com>
Message-ID: <00iGNSPAJ-TH10cVIW84qWghootDo5KDsJzCkHCvNGE=.ccfe0844-8ba7-4ebc-bbf8-dedfb79e19fb@github.com>

On Mon, 7 Mar 2022 18:08:25 GMT, Jamil Nimeh <jnimeh at openjdk.org> wrote:

> Hello,
> 
> This makes a small change to the evbroadcasti32x4 method to make it consistent with the Intel SDM for the vbroadcasti32x4 instruction.  It sets the requirements to AVX512F rather than AVX512DQ, changes the Op/En field to be T4 instead of T2 and sets the width to 32-bits rather than 64.
> 
> Hotspot tier1 through 4 tests passed.  I also performed a 100,000 iteration run of the TestChecksum, TestCRC and TestCRC32 regression tests with intrinsics/diagnostics printing turned on so I could see that the methods that call the kernel_crc32_avx512 macro are invoked.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8282312

This pull request has now been integrated.

Changeset: 8b45dbda
Author:    Jamil Nimeh <jnimeh at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8b45dbdae6e5dee85ef65ce25850ce692ad3e965
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8282312: Minor corrections to evbroadcasti32x4 intrinsic on x86

Reviewed-by: dlong

-------------

PR: https://git.openjdk.java.net/jdk/pull/7732

From duke at openjdk.java.net  Tue Mar  8 06:34:05 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 8 Mar 2022 06:34:05 GMT
Subject: RFR: 8282711: Accelerate Math.signum function for AVX and AVX512
 target.
In-Reply-To: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
References: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
Message-ID: <Z9ImroHtcWzW27znXxQstZnQARD90_qajv8jg9N9cmM=.177a99c1-69e2-4e95-b09e-923cf5b8c046@github.com>

On Mon, 7 Mar 2022 02:01:55 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - Patch auto-vectorizes Math.signum operation for floating point types.
> - Efficient JIT sequence is being generated for AVX512 and legacy X86 targets.
> - Following is the performance data for include JMH micro.
> 
> System : Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz  (40C 2S Icelake Server) 
> 
> Benchmark | (SIZE) | Baseline AVX (ns/op) | Withopt AVX (ns/op) | Gain Ratio | Basline AVX512 (ns/op) | Withopt AVX512 (ns/op) | Gain Ratio
> -- | -- | -- | -- | -- | -- | -- | --
> VectorSignum.doubleSignum | 256 | 174.357 | 68.374 | 2.550048264 | 173.679 | 31.013 | 5.600199916
> VectorSignum.doubleSignum | 512 | 334.231 | 128.762 | 2.595727 | 334.625 | 59.377 | 5.635599643
> VectorSignum.doubleSignum | 1024 | 655.679 | 251.566 | 2.606389576 | 655.267 | 116.736 | 5.613238418
> VectorSignum.doubleSignum | 2048 | 1292.165 | 499.924 | 2.584722878 | 1301.7 | 228.064 | 5.707608391
> VectorSignum.floatSignum | 256 | 176.064 | 39.864 | 4.416616496 | 174.639 | 25.372 | 6.883138893
> VectorSignum.floatSignum | 512 | 337.565 | 71.027 | 4.752629282 | 331.506 | 36.64 | 9.047652838
> VectorSignum.floatSignum | 1024 | 661.488 | 131.074 | 5.046675924 | 644.621 | 63.88 | 10.09112398
> VectorSignum.floatSignum | 2048 | 1299.685 | 253.271 | 5.13159817 | 1279.658 | 118.995 | 10.75388042
> 
> 
> Kindly review and share feedback.
> 
> Best Regards,
> Jatin

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4313:

> 4311:     evmovdquq(dst, k0, one, true, vec_enc);
> 4312:     evmovdquq(dst, ktmp2, xtmp1, true, vec_enc);
> 4313:     evblendmpd(dst, ktmp1, dst, src, true, vec_enc);

I believe you could achieve better register management using the following sequence. Also I would suggest using `evmovupd`or `evmovups` to avoid potential data bypass delay.

    evpmovq2m(ktmp1, src, vec_enc);
    evmovdquq(dst, k0, one, false, vec_enc);
    evsubpd(dst, ktmp1, zero, one, true, vec_enc);
    evfpclasspd(ktmp1, src, 0x7, vec_enc);
    evblendmpd(dst, ktmp1, dst, zero, true, vec_enc);

-------------

PR: https://git.openjdk.java.net/jdk/pull/7717

From duke at openjdk.java.net  Tue Mar  8 06:45:00 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 8 Mar 2022 06:45:00 GMT
Subject: RFR: 8282711: Accelerate Math.signum function for AVX and AVX512
 target.
In-Reply-To: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
References: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
Message-ID: <sJDX3jluYL7PlK7dsSoZgmkGgq8RviU0BO5mHAwV6sQ=.be09104a-e399-4558-b566-758fb0a4d852@github.com>

On Mon, 7 Mar 2022 02:01:55 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - Patch auto-vectorizes Math.signum operation for floating point types.
> - Efficient JIT sequence is being generated for AVX512 and legacy X86 targets.
> - Following is the performance data for include JMH micro.
> 
> System : Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz  (40C 2S Icelake Server) 
> 
> Benchmark | (SIZE) | Baseline AVX (ns/op) | Withopt AVX (ns/op) | Gain Ratio | Basline AVX512 (ns/op) | Withopt AVX512 (ns/op) | Gain Ratio
> -- | -- | -- | -- | -- | -- | -- | --
> VectorSignum.doubleSignum | 256 | 174.357 | 68.374 | 2.550048264 | 173.679 | 31.013 | 5.600199916
> VectorSignum.doubleSignum | 512 | 334.231 | 128.762 | 2.595727 | 334.625 | 59.377 | 5.635599643
> VectorSignum.doubleSignum | 1024 | 655.679 | 251.566 | 2.606389576 | 655.267 | 116.736 | 5.613238418
> VectorSignum.doubleSignum | 2048 | 1292.165 | 499.924 | 2.584722878 | 1301.7 | 228.064 | 5.707608391
> VectorSignum.floatSignum | 256 | 176.064 | 39.864 | 4.416616496 | 174.639 | 25.372 | 6.883138893
> VectorSignum.floatSignum | 512 | 337.565 | 71.027 | 4.752629282 | 331.506 | 36.64 | 9.047652838
> VectorSignum.floatSignum | 1024 | 661.488 | 131.074 | 5.046675924 | 644.621 | 63.88 | 10.09112398
> VectorSignum.floatSignum | 2048 | 1299.685 | 253.271 | 5.13159817 | 1279.658 | 118.995 | 10.75388042
> 
> 
> Kindly review and share feedback.
> 
> Best Regards,
> Jatin

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4334:

> 4332:     vsubpd(xtmp3, zero, one, vec_enc);
> 4333:     vblendvpd(dst, xtmp3, one, xtmp2, vec_enc);
> 4334:     vblendvpd(dst, dst, src, xtmp1, vec_enc);

The same applies here, suggestion:

    vsubpd(dst, zero, one, vec_enc);
    vcmppd(xtmp1, src, zero, Assembler::LT_OQ, vec_enc);
    vblendvpd(dst, xtmp1, one, dst, vec_enc);
    vcmppd(xtmp1, src, zero, Assembler::EQ_UQ, vec_enc);
    vblendvpd(dst, xtmp1, dst, zero, vec_enc);

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7717

From duke at openjdk.java.net  Tue Mar  8 07:00:08 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 8 Mar 2022 07:00:08 GMT
Subject: RFR: 8282711: Accelerate Math.signum function for AVX and AVX512
 target.
In-Reply-To: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
References: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
Message-ID: <B0cRAAuq8EB00D6JFKx1gOapmDM3Fa0U6iv47JRLbyY=.e8ec3411-dd23-4483-aa8b-ccb6b4c878e5@github.com>

On Mon, 7 Mar 2022 02:01:55 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> - Patch auto-vectorizes Math.signum operation for floating point types.
> - Efficient JIT sequence is being generated for AVX512 and legacy X86 targets.
> - Following is the performance data for include JMH micro.
> 
> System : Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz  (40C 2S Icelake Server) 
> 
> Benchmark | (SIZE) | Baseline AVX (ns/op) | Withopt AVX (ns/op) | Gain Ratio | Basline AVX512 (ns/op) | Withopt AVX512 (ns/op) | Gain Ratio
> -- | -- | -- | -- | -- | -- | -- | --
> VectorSignum.doubleSignum | 256 | 174.357 | 68.374 | 2.550048264 | 173.679 | 31.013 | 5.600199916
> VectorSignum.doubleSignum | 512 | 334.231 | 128.762 | 2.595727 | 334.625 | 59.377 | 5.635599643
> VectorSignum.doubleSignum | 1024 | 655.679 | 251.566 | 2.606389576 | 655.267 | 116.736 | 5.613238418
> VectorSignum.doubleSignum | 2048 | 1292.165 | 499.924 | 2.584722878 | 1301.7 | 228.064 | 5.707608391
> VectorSignum.floatSignum | 256 | 176.064 | 39.864 | 4.416616496 | 174.639 | 25.372 | 6.883138893
> VectorSignum.floatSignum | 512 | 337.565 | 71.027 | 4.752629282 | 331.506 | 36.64 | 9.047652838
> VectorSignum.floatSignum | 1024 | 661.488 | 131.074 | 5.046675924 | 644.621 | 63.88 | 10.09112398
> VectorSignum.floatSignum | 2048 | 1299.685 | 253.271 | 5.13159817 | 1279.658 | 118.995 | 10.75388042
> 
> 
> Kindly review and share feedback.
> 
> Best Regards,
> Jatin

src/hotspot/cpu/x86/x86.ad line 1868:

> 1866:       if (UseAVX < 1 ||
> 1867:           (size_in_bits == 512 && !VM_Version::supports_avx512dq()) ||
> 1868:           (size_in_bits == 256 && !VM_Version::supports_avx2())) {

May I ask why do we need avx2 for 256-bit, thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7717

From thartmann at openjdk.java.net  Tue Mar  8 07:54:07 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 8 Mar 2022 07:54:07 GMT
Subject: RFR: 8282715: typo compileony in test Test8005033.java [v3]
In-Reply-To: <jzRZIK18foLilUhJEIhmRBkjDyDFK-lpvzffR-Hx_4s=.e0ec709a-9361-4748-91fc-fc931112b8fa@github.com>
References: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
 <GaNu_h3CfBH0i7xbR8b4EFwanwNg1Y4UkIsMD-eOGKk=.6987f5bc-51a5-4260-ab01-704b7ef23c58@github.com>
 <jzRZIK18foLilUhJEIhmRBkjDyDFK-lpvzffR-Hx_4s=.e0ec709a-9361-4748-91fc-fc931112b8fa@github.com>
Message-ID: <rGd7krXOq52zr9HOU63-U7I5pLSlhrrFkzzSUMMDsfs=.814dc534-8e59-452c-a9a4-f7b124d18d80@github.com>

On Tue, 8 Mar 2022 04:47:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The fix is good but I still don't understands why we don't see the test fail with

It's because `CompilerOracle::print_parse_error` just prints an error but does not exit the VM. Now I'm wondering if that is intended. We should probably change that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7718

From xgong at openjdk.java.net  Tue Mar  8 07:54:44 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 8 Mar 2022 07:54:44 GMT
Subject: RFR: 8282431: AArch64: Add optimized rules for masked vector
 multiply-add/sub for SVE
Message-ID: <bRRrWEoEmJk24aLM-eRglGGIttZ2eAIBexmskoh4tdw=.34cca7f0-92b5-4e02-9019-036a29dfc066@github.com>

We have the optimized match rules for vector `"fmls,fnmla,fnmls,mla,mls"` for ARM SVE. Similarly we can also add the rules for the relative masked operations to generate the optimized predicated instructions.

With this patch the following masked vector multiply-add for a byte vector:

  mul z18.b, p7/m, z18.b, z17.b
  add z17.b, p0/m, z17.b, z18.b

could be optimized to: 

   mla z19.b, p0/m, z18.b, z17.b

 And so does the multiply-sub operations. Also the following masked fused multiply-substract for a float vector:

  fneg    z18.s, p7/m, z18.s
  fmad    z17.s, p0/m, z18.s, z16.s

could be optimized to: 

  fmsb z17.s, p0/m, z18.s, z16.s"

 And the same to the relative negated fused operations.

This patch also fixes the potential issues for the usage of `NegVF/D` in match rules. The explicit check of non-predicated vector for `NegVF/D` must be added to the match rule predicate if the `NegVF/D` is assumed to be non-masked. Otherwise, the jvm might crash if a masked` NegVF/D` with two operands is matched into a rule which assumes the `NegVF/D` in subtree has one operand.

Also add the jtreg tests for all the touched vector operations.

-------------

Commit messages:
 - 8282431: AArch64: Add optimized rules for masked vector multiply-add/sub for SVE

Changes: https://git.openjdk.java.net/jdk/pull/7737/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7737&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282431
  Stats: 971 lines in 6 files changed: 863 ins; 0 del; 108 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7737.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7737/head:pull/7737

PR: https://git.openjdk.java.net/jdk/pull/7737

From duke at openjdk.java.net  Tue Mar  8 08:43:41 2022
From: duke at openjdk.java.net (Foivos)
Date: Tue, 8 Mar 2022 08:43:41 GMT
Subject: RFR: 8281266: [JVMCI] MetaUtil.toInternalName() doesn't handle
 hidden classes correctly [v2]
In-Reply-To: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>
References: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>
Message-ID: <zvuUjFEhlvHRTEIbKyAMD3fI5U6-ThQfj6sVZMPHUY4=.dac39c33-0cf8-433f-ae87-43af77e2b25c@github.com>

> https://github.com/openjdk/jdk/commit/7cc137105928ec109a29d9315565f7f49af3cf2b introduced hidden classes with internal names like `com/example/Foo.1234` that get changed to `com.example.Foo/1234` by `Class.getName()` which are not properly handled by `MetaUtil`'s `toInternalName` and `internalNameToJava`
> 
> This PR fixes this along with the corresponding test that used to work on the assumption that the internal class names didn't contain the `.` character and that java class names didn't contain the `/` character except for lambdas (which are now treated as hidden classes as well), an assumption that no longer holds.

Foivos has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Fix handling of hidden classes in MetaUtil
  
  7cc137105928ec109a29d9315565f7f49af3cf2b introduced hidden classes with
  internal names like com/example/Foo.1234 that get changed to
  com.example.Foo/1234 by Class.getName() which are not properly handled
  by MetaUtil's toInternalName and internalNameToJava

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7346/files
  - new: https://git.openjdk.java.net/jdk/pull/7346/files/90934723..f0ac427c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7346&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7346&range=00-01

  Stats: 17 lines in 1 file changed: 12 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7346.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7346/head:pull/7346

PR: https://git.openjdk.java.net/jdk/pull/7346

From duke at openjdk.java.net  Tue Mar  8 08:43:42 2022
From: duke at openjdk.java.net (Foivos)
Date: Tue, 8 Mar 2022 08:43:42 GMT
Subject: RFR: 8281266: [JVMCI] MetaUtil.toInternalName() doesn't handle
 hidden classes correctly [v2]
In-Reply-To: <oBJmg3pIYRNKv9hW2pAkT8yFODnzJGG8whd-V-ruV_s=.4e47cd19-926c-4e4b-a9f8-9b3ca663e8e7@github.com>
References: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>
 <oBJmg3pIYRNKv9hW2pAkT8yFODnzJGG8whd-V-ruV_s=.4e47cd19-926c-4e4b-a9f8-9b3ca663e8e7@github.com>
Message-ID: <ra45iGNq-fhX3Vj6xRlqkGI3pKXqkNHZf1AZjjSvbFg=.acc3b675-4835-40ae-8219-d060bb52ef73@github.com>

On Mon, 7 Mar 2022 09:52:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Foivos has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Fix handling of hidden classes in MetaUtil
>>   
>>   7cc137105928ec109a29d9315565f7f49af3cf2b introduced hidden classes with
>>   internal names like com/example/Foo.1234 that get changed to
>>   com.example.Foo/1234 by Class.getName() which are not properly handled
>>   by MetaUtil's toInternalName and internalNameToJava
>
> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.meta/src/jdk/vm/ci/meta/MetaUtil.java line 127:
> 
>> 125:         switch (name.charAt(0)) {
>> 126:             case 'L': {
>> 127:                 String result = replacePackageAndHiddenSeparators(name.substring(1, name.length() - 1), '/', '.');
> 
> Consider extracting constants `/` (as `PACKAGE_SEP_INTERNAL` perhaps)  and `.` (as `HIDDEN_SEP_INTERNAL`). You could then also create the inversely defined constants `PACKAGE_SEP_JAVA` and `HIDDEN_SEP_JAVA`. It would make the code slightly easier to read.

?? 

Done!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7346

From duke at openjdk.java.net  Tue Mar  8 09:02:03 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Tue, 8 Mar 2022 09:02:03 GMT
Subject: RFR: 8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0)
 failed: Don't process dead nodes [v4]
In-Reply-To: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
References: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
Message-ID: <u9JBcxv2KOlaZFcnU4K9LjiatClctH31ZnQ2D7Xznq8=.79df4f33-83f2-4fdf-a4d2-4236311c1598@github.com>

> Problem:
> Sometimes nodes are generated, and then not properly added to any other node, nor added to the worklist, so that it could be deleted. In some cases, a node can thus survive after IGVN and enter into `ConnectionGraph::compute_escape`, where no dead nodes are expected (except constants).
> 
> In `ArrayCopyNode::prepare_array_copy`:
> In one, I now add the new ConvI2LNode to the worklist if we are aborting.
> In the other case, I could safely reorder the code, such new ConvI2LNode would only be generated once we know we are not going to abort.
> 
> In `SubTypeCheckNode::Ideal`:
> Replaced `set_req` with `set_req_X`, such that the input-node that is replaced (which is now potentially a dead node) is put on the worklist.
> 
> In `ArrayCopyNode::Ideal`:
> If we decide to `return NULL` we also need to add the potentially dead forward / backward memory nodes to the worklist, they may turn out to be dead.
> 
> Added a regression test: the test + flag combination that first reproduced this issue.
> 
> Tests running...

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  fixing typo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7728/files
  - new: https://git.openjdk.java.net/jdk/pull/7728/files/da132d29..2a50afde

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7728&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7728&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7728.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7728/head:pull/7728

PR: https://git.openjdk.java.net/jdk/pull/7728

From duke at openjdk.java.net  Tue Mar  8 09:25:51 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Tue, 8 Mar 2022 09:25:51 GMT
Subject: RFR: 8282665: [REDO] ByteBufferTest.java: replace endless
 recursion with RuntimeException in void ck(double x, double y) [v3]
In-Reply-To: <GkxbMy2Qw-zKDCZCsv759XPa6iluwVBQVGssKijyPi4=.10562a25-43af-412c-8489-43249076ff8d@github.com>
References: <GkxbMy2Qw-zKDCZCsv759XPa6iluwVBQVGssKijyPi4=.10562a25-43af-412c-8489-43249076ff8d@github.com>
Message-ID: <gAVYoc7ZwK2-c_kQZE0O_-xZ1F5Lg9ULq5DjlQCDuJw=.333281e8-45ea-482e-9b89-eb2a59ae55ac@github.com>

> Until now, ck for doubles ignored the case when either x or y was NaN, it for example would let pass x=NaN and y=2.0.
> Further, instead of throwing an exception, it went into infinite recursion, with an eventual StackOverflowError.
> Now, we throw an exception that prints the values. I fixed the logic, and added an explanation.
> 
> All tests are passing.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  simplify

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7723/files
  - new: https://git.openjdk.java.net/jdk/pull/7723/files/a96fbb5d..7aea6882

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7723&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7723&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7723.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7723/head:pull/7723

PR: https://git.openjdk.java.net/jdk/pull/7723

From duke at openjdk.java.net  Tue Mar  8 09:25:52 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Tue, 8 Mar 2022 09:25:52 GMT
Subject: RFR: 8282665: [REDO] ByteBufferTest.java: replace endless
 recursion with RuntimeException in void ck(double x, double y) [v2]
In-Reply-To: <-U9x_GWkbm1YJd5O7OVMW81kGf4cxV7oh7OxHH0KFpU=.10dfbdc5-2821-48de-8eec-864d4fe5c66b@github.com>
References: <GkxbMy2Qw-zKDCZCsv759XPa6iluwVBQVGssKijyPi4=.10562a25-43af-412c-8489-43249076ff8d@github.com>
 <-34q5-7FfYMtgEgjaQabZtD0Bt4Hvnvk2bRJLeq_YU8=.1c90c5fb-87b7-4cd1-9079-b8e711e4b3ce@github.com>
 <-U9x_GWkbm1YJd5O7OVMW81kGf4cxV7oh7OxHH0KFpU=.10dfbdc5-2821-48de-8eec-864d4fe5c66b@github.com>
Message-ID: <ACNW5T0vkVYW9mZrgR2TptnrHMhXN46sWiE7EE4aRF0=.458c66eb-e159-4a94-8c9b-d21a1a653a4f@github.com>

On Mon, 7 Mar 2022 23:24:16 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   state reason for failure in Exception
>
> I wonder if we can simplify and replace the test with `Double.compare(x, y) != 0`? Can you test that?
> 
> That introduces a new condition since `-0.0 == 0.0` is `true` (yes, another odd difference!) where as `Double.compare(-0.0, 0.0) != 0`

Thanks @PaulSandoz , I changed it and ran the tests again.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7723

From sgehwolf at openjdk.java.net  Tue Mar  8 09:41:03 2022
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 8 Mar 2022 09:41:03 GMT
Subject: RFR: 8281266: [JVMCI] MetaUtil.toInternalName() doesn't handle
 hidden classes correctly [v2]
In-Reply-To: <zvuUjFEhlvHRTEIbKyAMD3fI5U6-ThQfj6sVZMPHUY4=.dac39c33-0cf8-433f-ae87-43af77e2b25c@github.com>
References: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>
 <zvuUjFEhlvHRTEIbKyAMD3fI5U6-ThQfj6sVZMPHUY4=.dac39c33-0cf8-433f-ae87-43af77e2b25c@github.com>
Message-ID: <S29U2WXvuhU8GqDM1jhW_zF00Q5470gq1rbnmP84wA0=.3b583432-f3ab-4a3e-b44e-6d4b37a28eb1@github.com>

On Tue, 8 Mar 2022 08:43:41 GMT, Foivos <duke at openjdk.java.net> wrote:

>> https://github.com/openjdk/jdk/commit/7cc137105928ec109a29d9315565f7f49af3cf2b introduced hidden classes with internal names like `com/example/Foo.1234` that get changed to `com.example.Foo/1234` by `Class.getName()` which are not properly handled by `MetaUtil`'s `toInternalName` and `internalNameToJava`
>> 
>> This PR fixes this along with the corresponding test that used to work on the assumption that the internal class names didn't contain the `.` character and that java class names didn't contain the `/` character except for lambdas (which are now treated as hidden classes as well), an assumption that no longer holds.
>
> Foivos has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Fix handling of hidden classes in MetaUtil
>   
>   7cc137105928ec109a29d9315565f7f49af3cf2b introduced hidden classes with
>   internal names like com/example/Foo.1234 that get changed to
>   com.example.Foo/1234 by Class.getName() which are not properly handled
>   by MetaUtil's toInternalName and internalNameToJava

Still good.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7346

From xliu at openjdk.java.net  Tue Mar  8 09:44:01 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 8 Mar 2022 09:44:01 GMT
Subject: RFR: 8282715: typo compileony in test Test8005033.java [v2]
In-Reply-To: <K0OFL6gvmrmRmJzXMtHUruOzEUX2HmsWSyX72eUwKJg=.e096266c-1ee6-4552-9cd7-3a4dd0e95e1d@github.com>
References: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
 <xuREW6RIavBwvPl0le68boZcltygsdDYPVaMVQKpWzg=.a667db74-8506-4675-bbdc-bc75e2f856d7@github.com>
 <XUettF3tEMXg72IMYqmS_BHgHeez7O3iCzVmkZlXfik=.f650b493-dc8a-499f-8d6e-ebe6a24758a9@github.com>
 <K0OFL6gvmrmRmJzXMtHUruOzEUX2HmsWSyX72eUwKJg=.e096266c-1ee6-4552-9cd7-3a4dd0e95e1d@github.com>
Message-ID: <3DYPbAeN_vaMOTpxFOJD1YaVUkrfLu9MG4rP16s2L9E=.8044bfe2-4b49-46d0-8b4c-d935767b907b@github.com>

On Tue, 8 Mar 2022 04:45:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/codegen/Test8005033.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
>> 
>> Since this file was first created by SAP, I would suggest adding yours after SAP's copyright line.
>> Thanks.
>
> IANAL But a simple typo fix doesn't seem worthy of a copyright claim.

> The fix is good but I still don't understands why we don't see the test fail with:
> 
> CompileCommand: An error occurred during parsing Error: Unrecognized option 'compileony' Line: 'compileony,compiler.codegen.Test8005033::testBitCount'
> 
> ??

yes, it's a warning not an error.  It doesn't change this test, the only difference is that it was slower. 
`-Xcomp` still takes effect and compiled all methods HotSpot encounters.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7718

From thartmann at openjdk.java.net  Tue Mar  8 12:54:05 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 8 Mar 2022 12:54:05 GMT
Subject: RFR: 8282715: typo compileony in test Test8005033.java [v3]
In-Reply-To: <GaNu_h3CfBH0i7xbR8b4EFwanwNg1Y4UkIsMD-eOGKk=.6987f5bc-51a5-4260-ab01-704b7ef23c58@github.com>
References: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
 <GaNu_h3CfBH0i7xbR8b4EFwanwNg1Y4UkIsMD-eOGKk=.6987f5bc-51a5-4260-ab01-704b7ef23c58@github.com>
Message-ID: <xzxf1miT9EhYFmE0UVQ2AjDZxgJAvJ_ww2-dTrjE9KM=.6d1c043d-922f-4156-97e6-8e1016ebc9d9@github.com>

On Tue, 8 Mar 2022 00:24:50 GMT, Xin Liu <xliu at openjdk.org> wrote:

>> This patch doesn't change the testing functionality. It was compiled before. HotSpot failed to handle compiler directive 'compileony'. As a result, it has to compile all methods.  
>> 
>> Here is the warning message
>> 
>> CompileCommand: An error occurred during parsing
>> Error: Unrecognized option 'compileony'
>> Line: 'compileony,compiler.codegen.Test8005033::testBitCount'
>> 
>> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
>> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
>> Use: '-XX:CompileCommand=help' for more information and to list all option.
>> 
>> After correcting the typo, hotspot only compiles the method it is supposed to test. Test time of fastdebug build reduces from 16.778s to 0.226s.
>
> Xin Liu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   put our copyright header behind the original author's.

Marked as reviewed by thartmann (Reviewer).

I filed [JDK-8282797](https://bugs.openjdk.java.net/browse/JDK-8282797) for this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7718

From thartmann at openjdk.java.net  Tue Mar  8 12:59:10 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 8 Mar 2022 12:59:10 GMT
Subject: RFR: 8282665: [REDO] ByteBufferTest.java: replace endless
 recursion with RuntimeException in void ck(double x, double y) [v3]
In-Reply-To: <gAVYoc7ZwK2-c_kQZE0O_-xZ1F5Lg9ULq5DjlQCDuJw=.333281e8-45ea-482e-9b89-eb2a59ae55ac@github.com>
References: <GkxbMy2Qw-zKDCZCsv759XPa6iluwVBQVGssKijyPi4=.10562a25-43af-412c-8489-43249076ff8d@github.com>
 <gAVYoc7ZwK2-c_kQZE0O_-xZ1F5Lg9ULq5DjlQCDuJw=.333281e8-45ea-482e-9b89-eb2a59ae55ac@github.com>
Message-ID: <Kdyznd9FdCL39KOmyMe9EXIqwk73hdAxMQeB7gDGLDY=.0ac48fbc-e7f4-417f-a9d0-6b87a73067f1@github.com>

On Tue, 8 Mar 2022 09:25:51 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> Until now, ck for doubles ignored the case when either x or y was NaN, it for example would let pass x=NaN and y=2.0.
>> Further, instead of throwing an exception, it went into infinite recursion, with an eventual StackOverflowError.
>> Now, we throw an exception that prints the values. I fixed the logic, and added an explanation.
>> 
>> All tests are passing.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7723

From jbhateja at openjdk.java.net  Tue Mar  8 13:15:47 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 8 Mar 2022 13:15:47 GMT
Subject: RFR: 8282711: Accelerate Math.signum function for AVX and AVX512
 target. [v2]
In-Reply-To: <Z9ImroHtcWzW27znXxQstZnQARD90_qajv8jg9N9cmM=.177a99c1-69e2-4e95-b09e-923cf5b8c046@github.com>
References: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
 <Z9ImroHtcWzW27znXxQstZnQARD90_qajv8jg9N9cmM=.177a99c1-69e2-4e95-b09e-923cf5b8c046@github.com>
Message-ID: <xV5Yl5WfuodZYiwT5A1F0YedLCrggPLxhWFBAA0NKFs=.6f47da22-8d0e-4d32-9b63-1c68a6d8b3bc@github.com>

On Tue, 8 Mar 2022 06:31:01 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> I believe you could achieve better register management using the following sequence.
> 
> ```
> evfpclasspd(ktmp1, src, 0x7, vec_enc);
> evblendmpd(dst, ktmp1, dst, zero, true, vec_enc);

0x7 encodes QNaN, +/- 0.0 values. Thus blending dst with zero will not work for NaN. I guess you wanted to mention src as in original sequence.

> evfpclasspd(ktmp1, src, 0x40, vec_enc);

0x40 checks does not check for NEGATIVE_INFINITE, Math.signum should return -1 for it.  0x40 should be 0x50

> evsubpd(dst, ktmp1, zero, one, true, vec_enc);
> ```

But I agree we can do away with some temporaries.

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4334:
> 
>> 4332:     vsubpd(xtmp3, zero, one, vec_enc);
>> 4333:     vblendvpd(dst, xtmp3, one, xtmp2, vec_enc);
>> 4334:     vblendvpd(dst, dst, src, xtmp1, vec_enc);
> 
> The same applies here, suggestion:
> 
>     vsubpd(dst, zero, one, vec_enc);
>     vblendvpd(dst, src, one, dst, vec_enc);
>     vcmppd(xtmp1, src, zero, Assembler::EQ_UQ, vec_enc);
>     vblendvpd(dst, xtmp1, dst, zero, vec_enc);
> 
> Thanks.

Same responses as above.

> src/hotspot/cpu/x86/x86.ad line 1868:
> 
>> 1866:       if (UseAVX < 1 ||
>> 1867:           (size_in_bits == 512 && !VM_Version::supports_avx512dq()) ||
>> 1868:           (size_in_bits == 256 && !VM_Version::supports_avx2())) {
> 
> May I ask why do we need avx2 for 256-bit, thanks.

Current instruction uses VPOR operations which works over 256 bit integral vectors only for targets supporting AVX2. 
VPOR is needed to compute a combined mask for NaN , -0.0 or 0.0. In all these case original source lanes should be returned back.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7717

From jbhateja at openjdk.java.net  Tue Mar  8 13:15:44 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 8 Mar 2022 13:15:44 GMT
Subject: RFR: 8282711: Accelerate Math.signum function for AVX and AVX512
 target. [v2]
In-Reply-To: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
References: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
Message-ID: <n1fJUXzJC3oRj35BAI7hXPAGsS_qg6nHX2_JQCa2QnA=.a91f76be-fb36-43c9-a65a-3012ccb5f0e4@github.com>

> - Patch auto-vectorizes Math.signum operation for floating point types.
> - Efficient JIT sequence is being generated for AVX512 and legacy X86 targets.
> - Following is the performance data for include JMH micro.
> 
> System : Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz  (40C 2S Icelake Server) 
> 
> Benchmark | (SIZE) | Baseline AVX (ns/op) | Withopt AVX (ns/op) | Gain Ratio | Basline AVX512 (ns/op) | Withopt AVX512 (ns/op) | Gain Ratio
> -- | -- | -- | -- | -- | -- | -- | --
> VectorSignum.doubleSignum | 256 | 174.357 | 68.374 | 2.550048264 | 173.679 | 31.013 | 5.600199916
> VectorSignum.doubleSignum | 512 | 334.231 | 128.762 | 2.595727 | 334.625 | 59.377 | 5.635599643
> VectorSignum.doubleSignum | 1024 | 655.679 | 251.566 | 2.606389576 | 655.267 | 116.736 | 5.613238418
> VectorSignum.doubleSignum | 2048 | 1292.165 | 499.924 | 2.584722878 | 1301.7 | 228.064 | 5.707608391
> VectorSignum.floatSignum | 256 | 176.064 | 39.864 | 4.416616496 | 174.639 | 25.372 | 6.883138893
> VectorSignum.floatSignum | 512 | 337.565 | 71.027 | 4.752629282 | 331.506 | 36.64 | 9.047652838
> VectorSignum.floatSignum | 1024 | 661.488 | 131.074 | 5.046675924 | 644.621 | 63.88 | 10.09112398
> VectorSignum.floatSignum | 2048 | 1299.685 | 253.271 | 5.13159817 | 1279.658 | 118.995 | 10.75388042
> 
> 
> Kindly review and share feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8282711: Review comments resolved.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7717/files
  - new: https://git.openjdk.java.net/jdk/pull/7717/files/b6d3feeb..d8c186b9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7717&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7717&range=00-01

  Stats: 87 lines in 5 files changed: 39 ins; 34 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7717.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7717/head:pull/7717

PR: https://git.openjdk.java.net/jdk/pull/7717

From duke at openjdk.java.net  Tue Mar  8 14:09:05 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 8 Mar 2022 14:09:05 GMT
Subject: RFR: 8282711: Accelerate Math.signum function for AVX and AVX512
 target. [v2]
In-Reply-To: <xV5Yl5WfuodZYiwT5A1F0YedLCrggPLxhWFBAA0NKFs=.6f47da22-8d0e-4d32-9b63-1c68a6d8b3bc@github.com>
References: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
 <Z9ImroHtcWzW27znXxQstZnQARD90_qajv8jg9N9cmM=.177a99c1-69e2-4e95-b09e-923cf5b8c046@github.com>
 <xV5Yl5WfuodZYiwT5A1F0YedLCrggPLxhWFBAA0NKFs=.6f47da22-8d0e-4d32-9b63-1c68a6d8b3bc@github.com>
Message-ID: <zBVsJVTMKljwtqXBdEgFBysK_HGCkvX0lchUCIRya1Q=.ea20e0d4-d7c5-47c2-92e6-0a7c44b541ba@github.com>

On Tue, 8 Mar 2022 13:11:26 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4313:
>> 
>>> 4311:     evmovdquq(dst, k0, one, true, vec_enc);
>>> 4312:     evmovdquq(dst, ktmp2, xtmp1, true, vec_enc);
>>> 4313:     evblendmpd(dst, ktmp1, dst, src, true, vec_enc);
>> 
>> I believe you could achieve better register management using the following sequence.
>> 
>>     evfpclasspd(ktmp1, src, 0x7, vec_enc);
>>     evblendmpd(dst, ktmp1, dst, zero, true, vec_enc);
>>     evfpclasspd(ktmp1, src, 0x40, vec_enc);
>>     evsubpd(dst, ktmp1, zero, one, true, vec_enc);
>
>> I believe you could achieve better register management using the following sequence.
>> 
>> ```
>> evfpclasspd(ktmp1, src, 0x7, vec_enc);
>> evblendmpd(dst, ktmp1, dst, zero, true, vec_enc);
> 
> 0x7 encodes QNaN, +/- 0.0 values. Thus blending dst with zero will not work for NaN. I guess you wanted to mention src as in original sequence.
> 
>> evfpclasspd(ktmp1, src, 0x40, vec_enc);
> 
> 0x40 checks does not check for NEGATIVE_INFINITE, Math.signum should return -1 for it.  0x40 should be 0x50
> 
>> evsubpd(dst, ktmp1, zero, one, true, vec_enc);
>> ```
> 
> But I agree we can do away with some temporaries.

Ah my bad, the second instruction should be `evblendmpd(dst, ktmp1, one, zero, true, vec_enc);`
And the third one should be 0x50 as you mentioned.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7717

From duke at openjdk.java.net  Tue Mar  8 14:13:01 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 8 Mar 2022 14:13:01 GMT
Subject: RFR: 8282711: Accelerate Math.signum function for AVX and AVX512
 target. [v2]
In-Reply-To: <xV5Yl5WfuodZYiwT5A1F0YedLCrggPLxhWFBAA0NKFs=.6f47da22-8d0e-4d32-9b63-1c68a6d8b3bc@github.com>
References: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
 <Z9ImroHtcWzW27znXxQstZnQARD90_qajv8jg9N9cmM=.177a99c1-69e2-4e95-b09e-923cf5b8c046@github.com>
 <xV5Yl5WfuodZYiwT5A1F0YedLCrggPLxhWFBAA0NKFs=.6f47da22-8d0e-4d32-9b63-1c68a6d8b3bc@github.com>
Message-ID: <myrDGB1VCYQs9BlvVrp6xoSPvWMaQZvGD3ln4urDpBg=.515c2807-5d05-4a05-ab3c-69cdd3420e36@github.com>

On Tue, 8 Mar 2022 13:11:24 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4334:
>> 
>>> 4332:     vsubpd(xtmp3, zero, one, vec_enc);
>>> 4333:     vblendvpd(dst, xtmp3, one, xtmp2, vec_enc);
>>> 4334:     vblendvpd(dst, dst, src, xtmp1, vec_enc);
>> 
>> The same applies here, suggestion:
>> 
>>     vsubpd(dst, zero, one, vec_enc);
>>     vblendvpd(dst, src, one, dst, vec_enc);
>>     vcmppd(xtmp1, src, zero, Assembler::EQ_UQ, vec_enc);
>>     vblendvpd(dst, xtmp1, dst, zero, vec_enc);
>> 
>> Thanks.
>
> Same responses as above.

I don't fully understand what you mean by "same as above". The logic here is using `src` to blend `one` and `minus_one` so that every positive will get `one` and every negative will get `minus_one`, the others are `zero` and `Nan` will make the unordered comparison with zero return true, thus the final blend will result in the correct output.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7717

From duke at openjdk.java.net  Tue Mar  8 15:40:07 2022
From: duke at openjdk.java.net (Foivos)
Date: Tue, 8 Mar 2022 15:40:07 GMT
Subject: Integrated: 8281266: [JVMCI] MetaUtil.toInternalName() doesn't handle
 hidden classes correctly
In-Reply-To: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>
References: <5bpNNPzCowt72DToZFDsb5EX86c4OraopxAVJ-XgN3A=.1acfdc30-a87b-42c4-86fb-4374d58684a2@github.com>
Message-ID: <3uC0S_uiBH8SA_fmWXJu1TZk9lYAML0ykqRgXhtyyeQ=.f47043c5-dbf2-4090-b396-a943cea14e17@github.com>

On Fri, 4 Feb 2022 12:01:46 GMT, Foivos <duke at openjdk.java.net> wrote:

> https://github.com/openjdk/jdk/commit/7cc137105928ec109a29d9315565f7f49af3cf2b introduced hidden classes with internal names like `com/example/Foo.1234` that get changed to `com.example.Foo/1234` by `Class.getName()` which are not properly handled by `MetaUtil`'s `toInternalName` and `internalNameToJava`
> 
> This PR fixes this along with the corresponding test that used to work on the assumption that the internal class names didn't contain the `.` character and that java class names didn't contain the `/` character except for lambdas (which are now treated as hidden classes as well), an assumption that no longer holds.

This pull request has now been integrated.

Changeset: 0cbc4b85
Author:    Foivos Zakkak <fzakkak at redhat.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0cbc4b85bf8ab2ccfb8762322098c4cc7996df7d
Stats:     46 lines in 2 files changed: 20 ins; 5 del; 21 mod

8281266: [JVMCI] MetaUtil.toInternalName() doesn't handle hidden classes correctly

Reviewed-by: sgehwolf, dnsimon

-------------

PR: https://git.openjdk.java.net/jdk/pull/7346

From psandoz at openjdk.java.net  Tue Mar  8 16:15:08 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 8 Mar 2022 16:15:08 GMT
Subject: RFR: 8282665: [REDO] ByteBufferTest.java: replace endless
 recursion with RuntimeException in void ck(double x, double y) [v3]
In-Reply-To: <gAVYoc7ZwK2-c_kQZE0O_-xZ1F5Lg9ULq5DjlQCDuJw=.333281e8-45ea-482e-9b89-eb2a59ae55ac@github.com>
References: <GkxbMy2Qw-zKDCZCsv759XPa6iluwVBQVGssKijyPi4=.10562a25-43af-412c-8489-43249076ff8d@github.com>
 <gAVYoc7ZwK2-c_kQZE0O_-xZ1F5Lg9ULq5DjlQCDuJw=.333281e8-45ea-482e-9b89-eb2a59ae55ac@github.com>
Message-ID: <T5fYC3khsJ6TFeWCZxhd3Hqsoa-8R5cHaAxHJH1NDYI=.632272f6-f47c-4448-9b95-39069312836c@github.com>

On Tue, 8 Mar 2022 09:25:51 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> Until now, ck for doubles ignored the case when either x or y was NaN, it for example would let pass x=NaN and y=2.0.
>> Further, instead of throwing an exception, it went into infinite recursion, with an eventual StackOverflowError.
>> Now, we throw an exception that prints the values. I fixed the logic, and added an explanation.
>> 
>> All tests are passing.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7723

From lucy at openjdk.java.net  Tue Mar  8 16:18:10 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 8 Mar 2022 16:18:10 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters [v3]
In-Reply-To: <LEWK5zYTVWrwc4wE1r95lAXtrt20Ebujj4lS2ols3C8=.e1f127b0-8801-4a92-9f77-a0ec6bbf9a4d@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
 <nesf35P-utm5j-xosWGl1mnu1XPvBvfcCTyOALC-CCo=.e27238c3-0a48-4d2b-a788-f6ec2bdb96ca@github.com>
 <kOvHTLs8n3635oLdZCUDwnXyq_l8zZT5yEeRga_8DaE=.4b2eaeaa-8602-48f9-917a-2ba9d812b441@github.com>
 <LEWK5zYTVWrwc4wE1r95lAXtrt20Ebujj4lS2ols3C8=.e1f127b0-8801-4a92-9f77-a0ec6bbf9a4d@github.com>
Message-ID: <IfiCoeq30M-O9KOYSJi1qrYTVksYhPUBli6Ei5krCKk=.1b3cb377-1b94-44bd-8464-e20064696d08@github.com>

On Mon, 28 Feb 2022 22:37:14 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> I see a failure in compiler/c2/irTests/TestAutoVectorization2DArray.java. The output is attached. [TestAutoVectorization2DArray.txt](https://github.com/openjdk/jdk/files/8157927/TestAutoVectorization2DArray.txt)

@backwaterred I'm very sure the failure you are seeing is unrelated to my changes. Please note that JEP 338 (Vector API) is not supported on s390. I can reproduce the failure with a plain OpenJDK/jdk build of today.

Could you please verify that you see the failure with a plain build as well? Thank you!

Btw: sorry for reacting with such a long delay. Other duties were keeping me busy.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7324

From lucy at openjdk.java.net  Tue Mar  8 16:23:06 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 8 Mar 2022 16:23:06 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters [v3]
In-Reply-To: <nesf35P-utm5j-xosWGl1mnu1XPvBvfcCTyOALC-CCo=.e27238c3-0a48-4d2b-a788-f6ec2bdb96ca@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
 <nesf35P-utm5j-xosWGl1mnu1XPvBvfcCTyOALC-CCo=.e27238c3-0a48-4d2b-a788-f6ec2bdb96ca@github.com>
Message-ID: <1dvCz9GTRJbyYMnIec1kKY_OmaS9GgtltGH9CIr1NUA=.c368d8c4-d095-49e4-9896-f49737633d5b@github.com>

On Mon, 28 Feb 2022 17:10:26 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> May I please request reviews for this cleanup and unification change. It streamlines the address operand emitters for all instructions. As such, the modifications are widespread and may be cumbersome to review. Please ask questions if anything is unclear.
>> 
>> SAP does not maintain a full s390x build and test environment any longer. I would therefore very much appreciate if somebody would run a build and test cycle on s390x. 
>> 
>> As this is a s390x-only change, other platforms are not impacted.
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor comment adaptations and code formatting

Meanwhile, there exists a SAP-internal port of the change to HotSpot 11. This port passes all SAP-internal testing which is a good indication that the change has no obvious shortcomings.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7324

From psandoz at openjdk.java.net  Tue Mar  8 16:42:12 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 8 Mar 2022 16:42:12 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v8]
In-Reply-To: <NyhSShcx0Uytr1Hx2_EfzcYOiASC0l93ingNDna9zjg=.cc955b10-7d45-41f3-a03c-5057930a9441@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <vxDwpCRmu3HvXKL8NegsH_wBHLEkJzAFosN5WMyCx0g=.0a147a58-ebe3-42e7-b15e-22b7d6e45e4d@github.com>
 <Yc5XzgyEwgOdyG3X_cMXwbJUCaq4XvhqZaxhXOU_5JI=.99896e8c-f398-4bf9-9893-77eaefa0c374@github.com>
 <NyhSShcx0Uytr1Hx2_EfzcYOiASC0l93ingNDna9zjg=.cc955b10-7d45-41f3-a03c-5057930a9441@github.com>
Message-ID: <oLe5-jdBe2dPE0x7psQs37JyFrsq09XpJsiQfEi_Q0o=.d96d416d-5e1a-43fd-8bb4-72cdf69fec99@github.com>

On Tue, 8 Mar 2022 01:33:17 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Tests pass.
>
>> Tests pass.
> 
> Thanks @PaulSandoz. X86 backend changes have been reviewed by @sviswa7, do we need second approval on this.

@jatin-bhateja yes, need another HS reviewer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From jbhateja at openjdk.java.net  Tue Mar  8 16:43:05 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 8 Mar 2022 16:43:05 GMT
Subject: RFR: 8282711: Accelerate Math.signum function for AVX and AVX512
 target. [v2]
In-Reply-To: <myrDGB1VCYQs9BlvVrp6xoSPvWMaQZvGD3ln4urDpBg=.515c2807-5d05-4a05-ab3c-69cdd3420e36@github.com>
References: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
 <Z9ImroHtcWzW27znXxQstZnQARD90_qajv8jg9N9cmM=.177a99c1-69e2-4e95-b09e-923cf5b8c046@github.com>
 <xV5Yl5WfuodZYiwT5A1F0YedLCrggPLxhWFBAA0NKFs=.6f47da22-8d0e-4d32-9b63-1c68a6d8b3bc@github.com>
 <myrDGB1VCYQs9BlvVrp6xoSPvWMaQZvGD3ln4urDpBg=.515c2807-5d05-4a05-ab3c-69cdd3420e36@github.com>
Message-ID: <NzZBDBUhy2xGtxuskJCiMp9OYskcyVVb1XkDCfH6ocQ=.bfdeae2d-2181-486b-a012-ab0a3a0ed9fb@github.com>

On Tue, 8 Mar 2022 14:09:54 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Same responses as above.
>
> I don't fully understand what you mean by "same as above". The logic here is using `src` to blend `one` and `minus_one` so that every positive will get `one` and every negative will get `minus_one`, the others are `zero` and `Nan` will make the unordered comparison with zero return true, thus the final blend will result in the correct output.
> Thanks.

Good, I recall using this in one of my previous patch 
http://hg.openjdk.java.net/jdk/jdk/rev/ff399127078a#l5.245

-------------

PR: https://git.openjdk.java.net/jdk/pull/7717

From xliu at openjdk.java.net  Tue Mar  8 17:37:11 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Tue, 8 Mar 2022 17:37:11 GMT
Subject: Integrated: 8282715: typo compileony in test Test8005033.java
In-Reply-To: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
References: <BcrYILbsMfAzKUA4yzDEMNlgoFwP0dJRpfpYHdvv0G4=.5eb36d80-935b-472f-b608-0988b73a4fa1@github.com>
Message-ID: <wQpDtyb0vBmg9SOiFzRaKFxQF-R-vDVCK73Iz6SODi8=.9e0e43d4-bdd0-480c-8c0e-610037af609e@github.com>

On Mon, 7 Mar 2022 05:33:26 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This patch doesn't change the testing functionality. It was compiled before. HotSpot failed to handle compiler directive 'compileony'. As a result, it has to compile all methods.  
> 
> Here is the warning message
> 
> CompileCommand: An error occurred during parsing
> Error: Unrecognized option 'compileony'
> Line: 'compileony,compiler.codegen.Test8005033::testBitCount'
> 
> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
> Use: '-XX:CompileCommand=help' for more information and to list all option.
> 
> After correcting the typo, hotspot only compiles the method it is supposed to test. Test time of fastdebug build reduces from 16.778s to 0.226s.

This pull request has now been integrated.

Changeset: 288d1afc
Author:    Xin Liu <xliu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/288d1afc5a2d5ac128b1b427bc877b7815925917
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8282715: typo compileony in test Test8005033.java

Reviewed-by: jiefu, dholmes, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7718

From sviswanathan at openjdk.java.net  Tue Mar  8 18:05:07 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 8 Mar 2022 18:05:07 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v8]
In-Reply-To: <T7_MCvcT2FaCfUeYUFN8mR_1p1wB8TxB6VH2UFf010U=.1f560b53-b400-4b42-b6a8-e9211061adc2@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <T7_MCvcT2FaCfUeYUFN8mR_1p1wB8TxB6VH2UFf010U=.1f560b53-b400-4b42-b6a8-e9211061adc2@github.com>
Message-ID: <0wqHvsy7TwJ-BXHN3i9VqMzw2IKGbqXtV98VyxCr-7k=.90cfc47a-deca-4ecd-a611-c99036437360@github.com>

On Tue, 8 Feb 2022 09:01:30 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8281375: Review comments resolved.
>
> Hi Jatin, nice work!
> 
> One quick comment - the _vector_popcount_lut it's generated unconditionally - could you guard it so that it's only generated when it can be used? My preferred choice would to be have it be generated lazily, but that's an enhancement all of it's own.
> 
> Best regards,
> Nils

@neliasso Could you please review and approve the patch if it looks ok to you? Jatin has incorporated changes suggested by you earlier. Paul Sandoz has tested the patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From duke at openjdk.java.net  Tue Mar  8 18:22:04 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 8 Mar 2022 18:22:04 GMT
Subject: RFR: 8282711: Accelerate Math.signum function for AVX and AVX512
 target. [v2]
In-Reply-To: <n1fJUXzJC3oRj35BAI7hXPAGsS_qg6nHX2_JQCa2QnA=.a91f76be-fb36-43c9-a65a-3012ccb5f0e4@github.com>
References: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
 <n1fJUXzJC3oRj35BAI7hXPAGsS_qg6nHX2_JQCa2QnA=.a91f76be-fb36-43c9-a65a-3012ccb5f0e4@github.com>
Message-ID: <Gz6xrQs7sX23azt26S5jD5EpHVUOsjAr3DDgJW9g6m4=.03c8fae3-178e-4fb9-bf88-f89bd0d79e25@github.com>

On Tue, 8 Mar 2022 13:15:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> - Patch auto-vectorizes Math.signum operation for floating point types.
>> - Efficient JIT sequence is being generated for AVX512 and legacy X86 targets.
>> - Following is the performance data for include JMH micro.
>> 
>> System : Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz  (40C 2S Icelake Server) 
>> 
>> Benchmark | (SIZE) | Baseline AVX (ns/op) | Withopt AVX (ns/op) | Gain Ratio | Basline AVX512 (ns/op) | Withopt AVX512 (ns/op) | Gain Ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> VectorSignum.doubleSignum | 256 | 174.357 | 68.374 | 2.550048264 | 173.679 | 31.013 | 5.600199916
>> VectorSignum.doubleSignum | 512 | 334.231 | 128.762 | 2.595727 | 334.625 | 59.377 | 5.635599643
>> VectorSignum.doubleSignum | 1024 | 655.679 | 251.566 | 2.606389576 | 655.267 | 116.736 | 5.613238418
>> VectorSignum.doubleSignum | 2048 | 1292.165 | 499.924 | 2.584722878 | 1301.7 | 228.064 | 5.707608391
>> VectorSignum.floatSignum | 256 | 176.064 | 39.864 | 4.416616496 | 174.639 | 25.372 | 6.883138893
>> VectorSignum.floatSignum | 512 | 337.565 | 71.027 | 4.752629282 | 331.506 | 36.64 | 9.047652838
>> VectorSignum.floatSignum | 1024 | 661.488 | 131.074 | 5.046675924 | 644.621 | 63.88 | 10.09112398
>> VectorSignum.floatSignum | 2048 | 1299.685 | 253.271 | 5.13159817 | 1279.658 | 118.995 | 10.75388042
>> 
>> 
>> Kindly review and share feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282711: Review comments resolved.

It turns out I misremembered the results of the function with `0` and `Nan`, fixed the suggestions to be more correct. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7717

From psandoz at openjdk.java.net  Tue Mar  8 18:47:06 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 8 Mar 2022 18:47:06 GMT
Subject: RFR: 8282431: AArch64: Add optimized rules for masked vector
 multiply-add/sub for SVE
In-Reply-To: <bRRrWEoEmJk24aLM-eRglGGIttZ2eAIBexmskoh4tdw=.34cca7f0-92b5-4e02-9019-036a29dfc066@github.com>
References: <bRRrWEoEmJk24aLM-eRglGGIttZ2eAIBexmskoh4tdw=.34cca7f0-92b5-4e02-9019-036a29dfc066@github.com>
Message-ID: <aeEQAjfbo-79P5Ap8MTsl8adxdeaKNNhJaafWgaDPzo=.dc7b68f3-4532-4c5a-a3b1-f4d5060e8db4@github.com>

On Tue, 8 Mar 2022 07:46:42 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> We have the optimized match rules for vector `"fmls,fnmla,fnmls,mla,mls"` for ARM SVE. Similarly we can also add the rules for the relative masked operations to generate the optimized predicated instructions.
> 
> With this patch the following masked vector multiply-add for a byte vector:
> 
>   mul z18.b, p7/m, z18.b, z17.b
>   add z17.b, p0/m, z17.b, z18.b
> 
> could be optimized to: 
> 
>    mla z19.b, p0/m, z18.b, z17.b
> 
>  And so does the multiply-sub operations. Also the following masked fused multiply-substract for a float vector:
> 
>   fneg    z18.s, p7/m, z18.s
>   fmad    z17.s, p0/m, z18.s, z16.s
> 
> could be optimized to: 
> 
>   fmsb z17.s, p0/m, z18.s, z16.s"
> 
>  And the same to the relative negated fused operations.
> 
> This patch also fixes the potential issues for the usage of `NegVF/D` in match rules. The explicit check of non-predicated vector for `NegVF/D` must be added to the match rule predicate if the `NegVF/D` is assumed to be non-masked. Otherwise, the jvm might crash if a masked` NegVF/D` with two operands is matched into a rule which assumes the `NegVF/D` in subtree has one operand.
> 
> Also add the jtreg tests for all the touched vector operations.

Did you consider writing a test using the IR test framework?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7737

From duke at openjdk.java.net  Tue Mar  8 19:05:06 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Tue, 8 Mar 2022 19:05:06 GMT
Subject: RFR: 8282509: [AIX] ResolvedTestClass fails on AIX with similar
 output [v3]
In-Reply-To: <fr5IVsWDcO4aRHv_V7p_D3LZR3IFMvK3GfwrO0iVN3o=.4ef5feb9-0849-4b44-9e8e-314ecaee9449@github.com>
References: <5eb3C_3MU09ZBJSPs9ER4fM8u89e7T814CDtRDIdqAY=.04acec75-b1ca-44be-8bb2-140a51ca0a2b@github.com>
 <fr5IVsWDcO4aRHv_V7p_D3LZR3IFMvK3GfwrO0iVN3o=.4ef5feb9-0849-4b44-9e8e-314ecaee9449@github.com>
Message-ID: <BBtHn3nzYCWQ0nJCE2cY7OdbarTcPZtMLJPXk7UMD5A=.1925b107-6ca2-45e4-81e4-81621d30ba3d@github.com>

On Mon, 7 Mar 2022 16:25:25 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> This is a tentative solution to a failure observed on AIX. The solution is tentative because I require help to ensure that something deeper and more problematic is not happening.
>> 
>> The test fails because the output produced by PrintCompilation produces `LambdaForm$MH/0x00000007c0002400` instead of `Invokers$Holder` as it does on other platforms. There is one other place the output is different, when `DirectMethodHandle$Holder` is replaced with `LambdaForm$DMH/0x00000007c0001c00`. Ignoring these name changes, the output of PrintCompilation is identical. I observe the same compilations (including the OSR/non-OSR, and same level) in the same order.
>> 
>> I would be grateful for help understanding the root of the difference behind the change. I have a few ideas, but I will let you build your own interpretations free from my potentially incorrect understanding (i.e. no spoilers). Thanks in advance.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Remove leading chars not present in original test
>  - Trial Solution: Replaces shouldContain with shouldMatch + Regex in ResolvedClassTest

I believe I have a better handle on this now. In a lucky break, some logging output I added ended up in `build/.../images/jdk/lib/classlist` and caused a build failure on x86. The same failure (with the same logging code) did not occur on AIX. I now believe the difference in test output is due to CDS, which I am surprised to learn is not implemented on [AIX](https://wiki.openjdk.java.net/display/PPCAIXPort).

My working understanding is as follows. For systems which support CDS, PrintCompilation sees the code as coming from Invokers$Holder in Invokers.java where is is shared among JVM instances. On AIX, CDS is not (fully?) implemented, and the code is not stored in Invokers$Holder. Instead, the code is referred to by a LambdaForm at the displayed memory address.

With this piece of the puzzle in place (and hopefully confirmed by others), I believe the check proposed here to be a sane choice to resolve this failure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7701

From haosun at openjdk.java.net  Wed Mar  9 00:57:07 2022
From: haosun at openjdk.java.net (Hao Sun)
Date: Wed, 9 Mar 2022 00:57:07 GMT
Subject: Integrated: 8265263: AArch64: Combine vneg with right shift count
In-Reply-To: <6APGll3m5cYjHelXsVqrfzEmzUaiTBHQHZOlsB2C1OM=.0d34fc7f-4b0a-430d-b519-336a34969efc@github.com>
References: <6APGll3m5cYjHelXsVqrfzEmzUaiTBHQHZOlsB2C1OM=.0d34fc7f-4b0a-430d-b519-336a34969efc@github.com>
Message-ID: <4Hao37-cgwB2sMgiflOqzERQa7kZLzZ0_sHdDLaKwVM=.b877e2fb-e831-4886-92cd-d7f0d5f2db36@github.com>

On Mon, 7 Mar 2022 08:46:12 GMT, Hao Sun <haosun at openjdk.org> wrote:

> ### Implementation
> 
> In AArch64 NEON, vector shift right is implemented by vector shift left
> instructions (SSHL[1] and USHL[2]) with negative shift count value. In
> C2 backend, we generate a `neg` to given shift value followed by `sshl`
> or `ushl` instruction.
> 
> For vector shift right, the vector shift count has two origins:
> 1) it can be duplicated from scalar variable/immediate(case-1),
> 2) it can be loaded directly from one vector(case-2).
> 
> This patch aims to optimize case-1. Specifically, we move the negate
> from RShiftV* rules to RShiftCntV rule. As a result, the negate can be
> hoisted outside of the loop if it's a loop invariant.
> 
> In this patch,
> 1) we split vshiftcnt* rules into vslcnt* and vsrcnt* rules to handle
> shift left and shift right respectively. Compared to vslcnt* rules, the
> negate is conducted in vsrcnt*.
> 2) for each vsra* and vsrl* rules, we create one variant, i.e. vsra*_var
> and vsrl*_var. We use vsra* and vsrl* rules to handle case-1, and use
> vsra*_var and vsrl*_var rules to handle case-2. Note that
> ShiftVNode::is_var_shift() can be used to distinguish case-1 from
> case-2.
> 3) we add one assertion for the vs*_imm rules as we have done on
> ARM32[3].
> 4) several style issues are resolved.
> 
> ### Example
> 
> Take function `rShiftInt()` in the newly added micro benchmark
> VectorShiftRight.java as an example.
> 
> 
> public void rShiftInt() {
>     for (int i = 0; i < SIZE; i++) {
>         intsB[i] = intsA[i] >> count;
>     }
> }
> 
> 
> Arithmetic shift right is conducted inside a big loop. The following
> code snippet shows the disassembly code generated by auto-vectorization
> before we apply current patch. We can see that `neg` is conducted in the
> loop body.
> 
> 
> 0x0000ffff89057a64:   dup     v16.16b, w13              <-- dup
> 0x0000ffff89057a68:   mov     w12, #0x7d00                    // #32000
> 0x0000ffff89057a6c:   sub     w13, w2, w10
> 0x0000ffff89057a70:   cmp     w2, w10
> 0x0000ffff89057a74:   csel    w13, wzr, w13, lt
> 0x0000ffff89057a78:   mov     w8, #0x7d00                     // #32000
> 0x0000ffff89057a7c:   cmp     w13, w8
> 0x0000ffff89057a80:   csel    w13, w12, w13, hi
> 0x0000ffff89057a84:   add     w14, w13, w10
> 0x0000ffff89057a88:   nop
> 0x0000ffff89057a8c:   nop
> 0x0000ffff89057a90:   sbfiz   x13, x10, #2, #32         <-- loop entry
> 0x0000ffff89057a94:   add     x15, x17, x13
> 0x0000ffff89057a98:   ldr     q17, [x15,#16]
> 0x0000ffff89057a9c:   add     x13, x0, x13
> 0x0000ffff89057aa0:   neg     v18.16b, v16.16b          <-- neg
> 0x0000ffff89057aa4:   sshl    v17.4s, v17.4s, v18.4s    <-- shift right
> 0x0000ffff89057aa8:   str     q17, [x13,#16]
> 0x0000ffff89057aac:   ...
> 0x0000ffff89057b1c:   add     w10, w10, #0x20
> 0x0000ffff89057b20:   cmp     w10, w14
> 0x0000ffff89057b24:   b.lt    0x0000ffff89057a90        <-- loop end
> 
> 
> Here is the disassembly code after we apply current patch. We can see
> that the negate is no longer conducted inside the loop, and it is
> hoisted to the outside.
> 
> 
> 0x0000ffff8d053a68:   neg     w14, w13                  <---- neg
> 0x0000ffff8d053a6c:   dup     v16.16b, w14              <---- dup
> 0x0000ffff8d053a70:   sub     w14, w2, w10
> 0x0000ffff8d053a74:   cmp     w2, w10
> 0x0000ffff8d053a78:   csel    w14, wzr, w14, lt
> 0x0000ffff8d053a7c:   mov     w8, #0x7d00                     // #32000
> 0x0000ffff8d053a80:   cmp     w14, w8
> 0x0000ffff8d053a84:   csel    w14, w12, w14, hi
> 0x0000ffff8d053a88:   add     w13, w14, w10
> 0x0000ffff8d053a8c:   nop
> 0x0000ffff8d053a90:   sbfiz   x14, x10, #2, #32         <-- loop entry
> 0x0000ffff8d053a94:   add     x15, x17, x14
> 0x0000ffff8d053a98:   ldr     q17, [x15,#16]
> 0x0000ffff8d053a9c:   sshl    v17.4s, v17.4s, v16.4s    <-- shift right
> 0x0000ffff8d053aa0:   add     x14, x0, x14
> 0x0000ffff8d053aa4:   str     q17, [x14,#16]
> 0x0000ffff8d053aa8:   ...
> 0x0000ffff8d053afc:   add     w10, w10, #0x20
> 0x0000ffff8d053b00:   cmp     w10, w13
> 0x0000ffff8d053b04:   b.lt    0x0000ffff8d053a90        <-- loop end
> 
> 
> ### Testing
> 
> Tier1~3 tests passed on Linux/AArch64 platform.
> 
> ### Performance Evaluation
> 
> - Auto-vectorization
> 
> One micro benchmark, i.e. VectorShiftRight.java, is added by this patch
> in order to evaluate the optimization on vector shift right.
> 
> The following table shows the result. Column `Score-1` shows the score
> before we apply current patch, and column `Score-2` shows the score when
> we apply current patch.
> 
> We witness about 30% ~ 53% improvement on microbenchmarks.
> 
> 
> Benchmark                      Units    Score-1    Score-2
> VectorShiftRight.rShiftByte   ops/ms  10601.980  13816.353
> VectorShiftRight.rShiftInt    ops/ms   3592.831   5502.941
> VectorShiftRight.rShiftLong   ops/ms   1584.012   2425.247
> VectorShiftRight.rShiftShort  ops/ms   6643.414   9728.762
> VectorShiftRight.urShiftByte  ops/ms   2066.965   2048.336 (*)
> VectorShiftRight.urShiftChar  ops/ms   6660.805   9728.478
> VectorShiftRight.urShiftInt   ops/ms   3592.909   5514.928
> VectorShiftRight.urShiftLong  ops/ms   1583.995   2422.991
> 
> *: Logical shift right for Byte type(urShiftByte) is not vectorized, as
> disscussed in [4].
> 
> 
> - VectorAPI
> 
> Furthermore, we also evaluate the impact of this patch on VectorAPI
> benchmarks, e.g., [5]. Details can be found in the table below. Columns
> `Score-1` and `Score-2` show the scores before and after applying
> current patch.
> 
> 
> Benchmark                  Units    Score-1    Score-2
> Byte128Vector.LSHL        ops/ms  10867.666  10873.993
> Byte128Vector.LSHLShift   ops/ms  10945.729  10945.741
> Byte128Vector.LSHR        ops/ms   8629.305   8629.343
> Byte128Vector.LSHRShift   ops/ms   8245.864  10303.521   <--
> Byte128Vector.ASHR        ops/ms   8619.691   8629.438
> Byte128Vector.ASHRShift   ops/ms   8245.860  10305.027   <--
> Int128Vector.LSHL         ops/ms   3104.213   3103.702
> Int128Vector.LSHLShift    ops/ms   3114.354   3114.371
> Int128Vector.LSHR         ops/ms   2380.717   2380.693
> Int128Vector.LSHRShift    ops/ms   2312.871   2992.377   <--
> Int128Vector.ASHR         ops/ms   2380.668   2380.647
> Int128Vector.ASHRShift    ops/ms   2312.894   2992.332   <--
> Long128Vector.LSHL        ops/ms   1586.907   1587.591
> Long128Vector.LSHLShift   ops/ms   1589.469   1589.540
> Long128Vector.LSHR        ops/ms   1209.754   1209.687
> Long128Vector.LSHRShift   ops/ms   1174.718   1527.502   <--
> Long128Vector.ASHR        ops/ms   1209.713   1209.669
> Long128Vector.ASHRShift   ops/ms   1174.712   1527.174   <--
> Short128Vector.LSHL       ops/ms   5945.542   5943.770
> Short128Vector.LSHLShift  ops/ms   5984.743   5984.640
> Short128Vector.LSHR       ops/ms   4613.378   4613.577
> Short128Vector.LSHRShift  ops/ms   4486.023   5746.466   <--
> Short128Vector.ASHR       ops/ms   4613.389   4613.478
> Short128Vector.ASHRShift  ops/ms   4486.019   5746.368   <--
> 
> 
> 1) For logical shift left(LSHL and LSHLShift), and shift right with
> variable vector shift count(LSHR and ASHR) cases, we didn't find much
> changes, which is expected.
> 
> 2) For shift right with scalar shift count(LSHRShift and ASHRShift)
> case, about 25% ~ 30% improvement can be observed, and this benefit is
> introduced by current patch.
> 
> [1] https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/SSHL--Signed-Shift-Left--register--
> [2] https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/USHL--Unsigned-Shift-Left--register--
> [3] https://github.com/openjdk/jdk18/pull/41
> [4] https://github.com/openjdk/jdk/pull/1087
> [5] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L509

This pull request has now been integrated.

Changeset: 49245131
Author:    Hao Sun <haosun at openjdk.org>
Committer: Pengfei Li <pli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/49245131e98c1c72c447536e5527acecb3311add
Stats:     856 lines in 4 files changed: 479 ins; 44 del; 333 mod

8265263: AArch64: Combine vneg with right shift count

Reviewed-by: adinn, dlong

-------------

PR: https://git.openjdk.java.net/jdk/pull/7724

From xgong at openjdk.java.net  Wed Mar  9 01:06:04 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 9 Mar 2022 01:06:04 GMT
Subject: Integrated: 8282432: Optimize masked "test" Vector API with predicate
 feature
In-Reply-To: <RlORBnCyrfaaTry0T08GvIcNFPFptQcFuMLRp7_xa6M=.4872305b-525d-4bee-9ec6-354950b87605@github.com>
References: <RlORBnCyrfaaTry0T08GvIcNFPFptQcFuMLRp7_xa6M=.4872305b-525d-4bee-9ec6-354950b87605@github.com>
Message-ID: <ABPGN26IFEZwWR_Jfy0fywQz75EzL0lNpAU-GHI14LM=.76816378-d6bf-41a5-81ae-7042727aee41@github.com>

On Wed, 2 Mar 2022 02:50:27 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The vector `"test"` api is implemented with vector `"compare"`. And the masked `"test" `is implemented with `"test(op).and(m)"` which means `"compare().and(m)"` finally. Since the masked vector `"compare"` has been optimized with predicated instruction for archituctures that support the feature, the masked `"test"` can also be optimized by implementing it with the predicated compare. This could save the additional ` "and"` for architectures that support the predicate feature.
> 
> This patch optimized the masked `"test"` by implementing it with masked `"compare"`. With this patch, the following codes for the` "IS_NEGATIVE"` op for a DoubleVector with SVE:
> 
>   mov z19.d, #0
>   cmpgt   p1.d, p7/z, z19.d, z17.d
>   and p0.b, p7/z, p1.b, p0.b
> 
> are optimized to:
> 
>   mov z19.d, #0
>   cmpgt   p0.d, p0/z, z19.d, z17.d
> 
> Also update the jtreg tests for masked` "test" ` to make sure they are hot enough to be compiled by c2.

This pull request has now been integrated.

Changeset: 12693a6c
Author:    Xiaohong Gong <xgong at openjdk.org>
Committer: Ningsheng Jian <njian at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/12693a6cf3e00c38a635d888419406f689657813
Stats:     1325 lines in 70 files changed: 574 ins; 11 del; 740 mod

8282432: Optimize masked "test" Vector API with predicate feature

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.java.net/jdk/pull/7654

From duke at openjdk.java.net  Wed Mar  9 02:20:01 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 9 Mar 2022 02:20:01 GMT
Subject: RFR: 8282711: Accelerate Math.signum function for AVX and AVX512
 target. [v2]
In-Reply-To: <zBVsJVTMKljwtqXBdEgFBysK_HGCkvX0lchUCIRya1Q=.ea20e0d4-d7c5-47c2-92e6-0a7c44b541ba@github.com>
References: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
 <Z9ImroHtcWzW27znXxQstZnQARD90_qajv8jg9N9cmM=.177a99c1-69e2-4e95-b09e-923cf5b8c046@github.com>
 <xV5Yl5WfuodZYiwT5A1F0YedLCrggPLxhWFBAA0NKFs=.6f47da22-8d0e-4d32-9b63-1c68a6d8b3bc@github.com>
 <zBVsJVTMKljwtqXBdEgFBysK_HGCkvX0lchUCIRya1Q=.ea20e0d4-d7c5-47c2-92e6-0a7c44b541ba@github.com>
Message-ID: <N5k2zmAskvslSqMBBU3SO0c_B2EnouoOnQPSAkoJK58=.8aea7eaa-e06a-4ea2-9901-692a15306f1f@github.com>

On Tue, 8 Mar 2022 14:05:36 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>>> I believe you could achieve better register management using the following sequence.
>>> 
>>> ```
>>> evfpclasspd(ktmp1, src, 0x7, vec_enc);
>>> evblendmpd(dst, ktmp1, dst, zero, true, vec_enc);
>> 
>> 0x7 encodes QNaN, +/- 0.0 values. Thus blending dst with zero will not work for NaN. I guess you wanted to mention src as in original sequence.
>> 
>>> evfpclasspd(ktmp1, src, 0x40, vec_enc);
>> 
>> 0x40 checks does not check for NEGATIVE_INFINITE, Math.signum should return -1 for it.  0x40 should be 0x50
>> 
>>> evsubpd(dst, ktmp1, zero, one, true, vec_enc);
>>> ```
>> 
>> But I agree we can do away with some temporaries.
>
> Ah my bad, the second instruction should be `evblendmpd(dst, ktmp1, one, src, true, vec_enc);`
> And the third one should be 0x50 as you mentioned.

Fixed the suggestion because I was mistaken, the first blend put all `NaN` and nonnegative values and the masked `vsubpd` put the remaining negative values, completing the operation. You need to spot `SNaN` also because it can be produced using `Double.longBitsToDouble` and in the future using vector reinterpretation.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7717

From jbhateja at openjdk.java.net  Wed Mar  9 05:39:49 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 9 Mar 2022 05:39:49 GMT
Subject: RFR: 8282711: Accelerate Math.signum function for AVX and AVX512
 target. [v3]
In-Reply-To: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
References: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
Message-ID: <SBoHuuwe-QgINo7y6rUJadunfIiYtYbto-w1MV8A5oQ=.e26a3203-4755-4f03-a56d-4f44a6fe6a5e@github.com>

> - Patch auto-vectorizes Math.signum operation for floating point types.
> - Efficient JIT sequence is being generated for AVX512 and legacy X86 targets.
> - Following is the performance data for include JMH micro.
> 
> System : Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz  (40C 2S Icelake Server) 
> 
> Benchmark | (SIZE) | Baseline AVX (ns/op) | Withopt AVX (ns/op) | Gain Ratio | Basline AVX512 (ns/op) | Withopt AVX512 (ns/op) | Gain Ratio
> -- | -- | -- | -- | -- | -- | -- | --
> VectorSignum.doubleSignum | 256 | 174.357 | 68.374 | 2.550048264 | 173.679 | 31.013 | 5.600199916
> VectorSignum.doubleSignum | 512 | 334.231 | 128.762 | 2.595727 | 334.625 | 59.377 | 5.635599643
> VectorSignum.doubleSignum | 1024 | 655.679 | 251.566 | 2.606389576 | 655.267 | 116.736 | 5.613238418
> VectorSignum.doubleSignum | 2048 | 1292.165 | 499.924 | 2.584722878 | 1301.7 | 228.064 | 5.707608391
> VectorSignum.floatSignum | 256 | 176.064 | 39.864 | 4.416616496 | 174.639 | 25.372 | 6.883138893
> VectorSignum.floatSignum | 512 | 337.565 | 71.027 | 4.752629282 | 331.506 | 36.64 | 9.047652838
> VectorSignum.floatSignum | 1024 | 661.488 | 131.074 | 5.046675924 | 644.621 | 63.88 | 10.09112398
> VectorSignum.floatSignum | 2048 | 1299.685 | 253.271 | 5.13159817 | 1279.658 | 118.995 | 10.75388042
> 
> 
> Kindly review and share feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8282711: Making the changes more generic (removing AVX512DQ restriction), adding new IR level test.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7717/files
  - new: https://git.openjdk.java.net/jdk/pull/7717/files/d8c186b9..8089c9cc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7717&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7717&range=01-02

  Stats: 141 lines in 6 files changed: 93 ins; 30 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7717.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7717/head:pull/7717

PR: https://git.openjdk.java.net/jdk/pull/7717

From jbhateja at openjdk.java.net  Wed Mar  9 06:26:40 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 9 Mar 2022 06:26:40 GMT
Subject: RFR: 8282711: Accelerate Math.signum function for AVX and AVX512
 target. [v4]
In-Reply-To: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
References: <SaqB988dzBOTGOBOmVAQo4d7pI4j4smGL-hfqCgPZBc=.04e0a2e2-a602-4087-880a-535b4042cd36@github.com>
Message-ID: <TiiOBKT25qfIxOzTaFn9x3DnE55Gzrh7KoFoCJ6II58=.98e50fb8-ff39-4406-a942-14c4bc8ad431@github.com>

> - Patch auto-vectorizes Math.signum operation for floating point types.
> - Efficient JIT sequence is being generated for AVX512 and legacy X86 targets.
> - Following is the performance data for include JMH micro.
> 
> System : Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz  (40C 2S Icelake Server) 
> 
> Benchmark | (SIZE) | Baseline AVX (ns/op) | Withopt AVX (ns/op) | Gain Ratio | Basline AVX512 (ns/op) | Withopt AVX512 (ns/op) | Gain Ratio
> -- | -- | -- | -- | -- | -- | -- | --
> VectorSignum.doubleSignum | 256 | 174.357 | 68.374 | 2.550048264 | 173.679 | 31.013 | 5.600199916
> VectorSignum.doubleSignum | 512 | 334.231 | 128.762 | 2.595727 | 334.625 | 59.377 | 5.635599643
> VectorSignum.doubleSignum | 1024 | 655.679 | 251.566 | 2.606389576 | 655.267 | 116.736 | 5.613238418
> VectorSignum.doubleSignum | 2048 | 1292.165 | 499.924 | 2.584722878 | 1301.7 | 228.064 | 5.707608391
> VectorSignum.floatSignum | 256 | 176.064 | 39.864 | 4.416616496 | 174.639 | 25.372 | 6.883138893
> VectorSignum.floatSignum | 512 | 337.565 | 71.027 | 4.752629282 | 331.506 | 36.64 | 9.047652838
> VectorSignum.floatSignum | 1024 | 661.488 | 131.074 | 5.046675924 | 644.621 | 63.88 | 10.09112398
> VectorSignum.floatSignum | 2048 | 1299.685 | 253.271 | 5.13159817 | 1279.658 | 118.995 | 10.75388042
> 
> 
> Kindly review and share feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8282711: Replacing vector length based predicate.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7717/files
  - new: https://git.openjdk.java.net/jdk/pull/7717/files/8089c9cc..aaf3cc1b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7717&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7717&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7717.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7717/head:pull/7717

PR: https://git.openjdk.java.net/jdk/pull/7717

From jbhateja at openjdk.java.net  Wed Mar  9 07:51:00 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 9 Mar 2022 07:51:00 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v8]
In-Reply-To: <T7_MCvcT2FaCfUeYUFN8mR_1p1wB8TxB6VH2UFf010U=.1f560b53-b400-4b42-b6a8-e9211061adc2@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <T7_MCvcT2FaCfUeYUFN8mR_1p1wB8TxB6VH2UFf010U=.1f560b53-b400-4b42-b6a8-e9211061adc2@github.com>
Message-ID: <gBmFeFYAM1gw67wBfeVJSykGIGWIJBYnMmc1FTJFnOM=.1e2be153-33fa-4783-aabe-fd3323d50941@github.com>

On Tue, 8 Feb 2022 09:01:30 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8281375: Review comments resolved.
>
> Hi Jatin, nice work!
> 
> One quick comment - the _vector_popcount_lut it's generated unconditionally - could you guard it so that it's only generated when it can be used? My preferred choice would to be have it be generated lazily, but that's an enhancement all of it's own.
> 
> Best regards,
> Nils

> @neliasso Could you please review and approve the patch if it looks ok to you? Jatin has incorporated changes suggested by you earlier. Paul Sandoz has tested the patch.

@sviswa7 , it seem @neliasso is on vacation.  @PaulSandoz  can anyone else review the patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From duke at openjdk.java.net  Wed Mar  9 08:16:58 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Wed, 9 Mar 2022 08:16:58 GMT
Subject: RFR: 8282665: [REDO] ByteBufferTest.java: replace endless
 recursion with RuntimeException in void ck(double x, double y) [v3]
In-Reply-To: <T5fYC3khsJ6TFeWCZxhd3Hqsoa-8R5cHaAxHJH1NDYI=.632272f6-f47c-4448-9b95-39069312836c@github.com>
References: <GkxbMy2Qw-zKDCZCsv759XPa6iluwVBQVGssKijyPi4=.10562a25-43af-412c-8489-43249076ff8d@github.com>
 <gAVYoc7ZwK2-c_kQZE0O_-xZ1F5Lg9ULq5DjlQCDuJw=.333281e8-45ea-482e-9b89-eb2a59ae55ac@github.com>
 <T5fYC3khsJ6TFeWCZxhd3Hqsoa-8R5cHaAxHJH1NDYI=.632272f6-f47c-4448-9b95-39069312836c@github.com>
Message-ID: <dVjzyC8b9cSwF2wduV6ey42ssw0Xis0X1DWUIf5dcLM=.f8de988f-2246-4b84-b43e-fbde83fe094b@github.com>

On Tue, 8 Mar 2022 16:12:01 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   simplify
>
> Marked as reviewed by psandoz (Reviewer).

Thanks @PaulSandoz and @TobiHartmann for the help and reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7723

From duke at openjdk.java.net  Wed Mar  9 09:03:07 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Wed, 9 Mar 2022 09:03:07 GMT
Subject: Integrated: 8282665: [REDO] ByteBufferTest.java: replace endless
 recursion with RuntimeException in void ck(double x, double y)
In-Reply-To: <GkxbMy2Qw-zKDCZCsv759XPa6iluwVBQVGssKijyPi4=.10562a25-43af-412c-8489-43249076ff8d@github.com>
References: <GkxbMy2Qw-zKDCZCsv759XPa6iluwVBQVGssKijyPi4=.10562a25-43af-412c-8489-43249076ff8d@github.com>
Message-ID: <kDJy_z1c_4r3lbtLTugoGaH4ZAiyQ04ipi4Yn33nOT4=.cd1e4b09-f178-4e74-8e79-c94335fbacdf@github.com>

On Mon, 7 Mar 2022 08:41:18 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> Until now, ck for doubles ignored the case when either x or y was NaN, it for example would let pass x=NaN and y=2.0.
> Further, instead of throwing an exception, it went into infinite recursion, with an eventual StackOverflowError.
> Now, we throw an exception that prints the values. I fixed the logic, and added an explanation.
> 
> All tests are passing.

This pull request has now been integrated.

Changeset: d07f7c76
Author:    Emanuel Peter <emanuel.peter at oracle.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d07f7c76c5df1473bffa41f10a89ca1e21e001ef
Stats:     12 lines in 1 file changed: 9 ins; 0 del; 3 mod

8282665: [REDO] ByteBufferTest.java: replace endless recursion with RuntimeException in void ck(double x, double y)

Reviewed-by: psandoz, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7723

From xgong at openjdk.java.net  Wed Mar  9 09:25:04 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 9 Mar 2022 09:25:04 GMT
Subject: RFR: 8282431: AArch64: Add optimized rules for masked vector
 multiply-add/sub for SVE
In-Reply-To: <aeEQAjfbo-79P5Ap8MTsl8adxdeaKNNhJaafWgaDPzo=.dc7b68f3-4532-4c5a-a3b1-f4d5060e8db4@github.com>
References: <bRRrWEoEmJk24aLM-eRglGGIttZ2eAIBexmskoh4tdw=.34cca7f0-92b5-4e02-9019-036a29dfc066@github.com>
 <aeEQAjfbo-79P5Ap8MTsl8adxdeaKNNhJaafWgaDPzo=.dc7b68f3-4532-4c5a-a3b1-f4d5060e8db4@github.com>
Message-ID: <qbrxScXbOnZOL3OE_2w7A7_Mgv1HrAuorN_3NUG72ZM=.3629070e-2535-44f2-bcd2-b23a299c7252@github.com>

On Tue, 8 Mar 2022 18:43:25 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Did you consider writing a test using the IR test framework?

Thanks for looking at this patch @PaulSandoz ! Yeah, I considered using the IR test framework. The main reason that I didn't use it finally is that this patch only changes the generated codes by adding match rules with out no IR changes.  And I misunderstood that the ir framework can only check the C2 IR nodes. Seems it can also check the assembly codes. I will change the tests to use it. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7737

From jbhateja at openjdk.java.net  Wed Mar  9 11:38:34 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 9 Mar 2022 11:38:34 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v12]
In-Reply-To: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
Message-ID: <z2cFnDhoRCyWcg8_EVPXNrIWho49Q9guONfeRXdJ1qA=.b6b0baea-f802-4d28-a453-ab14705c339c@github.com>

> Summary of changes:
> - Intrinsify Math.round(float) and Math.round(double) APIs.
> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
> - Test creation using new IR testing framework.
> 
> Following are the performance number of a JMH micro included with the patch 
> 
> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
> 
> 
> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
> -- | -- | -- | -- | -- | -- | -- | --
> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - 8279508: Preventing domain switch-over penalty for Math.round(float) and constraining unrolling to prevent code bloating.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
 - 8279508: Removing +LogCompilation flag.
 - 8279508: Review comments resolved.`
 - 8279508: Adding descriptive comments.
 - 8279508: Review comments resolved.
 - 8279508: Review comments resolved.
 - 8279508: Fixing for windows failure.
 - 8279508: Adding few descriptive comments.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d07f7c76...547f4e31

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7094/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=11
  Stats: 752 lines in 24 files changed: 660 ins; 30 del; 62 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094

PR: https://git.openjdk.java.net/jdk/pull/7094

From mdoerr at openjdk.java.net  Wed Mar  9 13:34:03 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 9 Mar 2022 13:34:03 GMT
Subject: RFR: 8282509: [AIX] ResolvedTestClass fails on AIX with similar
 output [v3]
In-Reply-To: <fr5IVsWDcO4aRHv_V7p_D3LZR3IFMvK3GfwrO0iVN3o=.4ef5feb9-0849-4b44-9e8e-314ecaee9449@github.com>
References: <5eb3C_3MU09ZBJSPs9ER4fM8u89e7T814CDtRDIdqAY=.04acec75-b1ca-44be-8bb2-140a51ca0a2b@github.com>
 <fr5IVsWDcO4aRHv_V7p_D3LZR3IFMvK3GfwrO0iVN3o=.4ef5feb9-0849-4b44-9e8e-314ecaee9449@github.com>
Message-ID: <hpS07D_1AxNvl_myFR9zMsKnNEfwaWkC4WLjYAO0Sv8=.fd4e803d-b8fb-4321-9b0f-88c02aeed7d7@github.com>

On Mon, 7 Mar 2022 16:25:25 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> This is a tentative solution to a failure observed on AIX. The solution is tentative because I require help to ensure that something deeper and more problematic is not happening.
>> 
>> The test fails because the output produced by PrintCompilation produces `LambdaForm$MH/0x00000007c0002400` instead of `Invokers$Holder` as it does on other platforms. There is one other place the output is different, when `DirectMethodHandle$Holder` is replaced with `LambdaForm$DMH/0x00000007c0001c00`. Ignoring these name changes, the output of PrintCompilation is identical. I observe the same compilations (including the OSR/non-OSR, and same level) in the same order.
>> 
>> I would be grateful for help understanding the root of the difference behind the change. I have a few ideas, but I will let you build your own interpretations free from my potentially incorrect understanding (i.e. no spoilers). Thanks in advance.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Remove leading chars not present in original test
>  - Trial Solution: Replaces shouldContain with shouldMatch + Regex in ResolvedClassTest

Looks reasonable. Please update the PR title: "[exploded image] ResolvedTestClass fails with similar output"

-------------

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7701

From duke at openjdk.java.net  Wed Mar  9 13:47:36 2022
From: duke at openjdk.java.net (Alex Blewitt)
Date: Wed, 9 Mar 2022 13:47:36 GMT
Subject: RFR: 8282878: Removed _JavaThread from PhaseTraceTime
Message-ID: <H3YLf2wDCNMHa1J8iwONv-s060TXZAH9MxJWFUHlGSE=.3de03bde-1a0c-4947-a4b0-a3bb0173d8ca@github.com>

The `PhaseTraceTime` class has a private `JavaThread _thread` field which doesn't appear to be referenced anywhere, and builds fine without it. It's not clear if this can be removed but it builds cleanly when not present.

-------------

Commit messages:
 - 8282878: Removed _JavaThread from PhaseTraceTime

Changes: https://git.openjdk.java.net/jdk/pull/7756/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7756&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282878
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7756.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7756/head:pull/7756

PR: https://git.openjdk.java.net/jdk/pull/7756

From roland at openjdk.java.net  Wed Mar  9 13:48:26 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 9 Mar 2022 13:48:26 GMT
Subject: RFR: 8282592: C2: assert(false) failed: graph should be schedulable
Message-ID: <-oXZLZYrKlxysFQgwKntZUr7dqC6G_WBEzi-ngqwqws=.c1ab815a-9065-4aba-9948-b3df225d0d3e@github.com>

This is another case of overunrolling that causes the type of the main
loop's iv to conflict with a ConvI2L of an array access. Skeleton
predicates were added to solve this family of issues. A predicate that
should catch that the main loop is unreachable is indeed added but the
predicate's condition doesn't constant fold.

What happens is that the main loop's iv phi initial value is a CastII
(added by PhaseIdealLoop::cast_incr_before_loop()). That CastII is
input to the predicates above the main loop and of the main loop's iv
phi. Once loop opts are over, the type of the CastII is updated by
CastIINode::Value() (the logic that looks at the test that guards the
CastII). The type update causes the main loop iv phi's type to be
updated and a ConvI2L to be become top. The predicate that should
catch the overunrolling has the shape:

(CmpU (AddI#1 (CastII (AddI#2 (Phi ..) ConI#1)) ConI#2) ConI#3)

In the case of the test case:

ConI#3 = 10
ConI#2 = 7
ConI#1 = 1

CastII has type = int:<=max-8
Phi has type = int:>=8

As a result:
AddI#2 has type int
AddI#1 has type int:min+7..max-1

The Phi is the pre loop Phi.

The fix I propose is that predicates when they are updated should skip
over the CastII, that is in this case:

(CmpU (AddI#1 (AddI#2 (Phi ..) ConI#1) ConI#2) ConI#3)

which is reshaped to:

(CmpU (AddI#1' (Phi ..) ConI#1') ConI#3)

In this case:

ConI#1 = 4 (because the predicate constant fold in earlier passes of
unrolling)

As a result AddI#1' still has type int But CmpUNode has special logic
to deal with the (CmpU (AddI ...)) shape and it can determine that
this one always fails.

The role of the CastII is to enforce the dependency between nodes in
the loop and the the loop entry test so it's not required for
predicates.

With that change, compiler/loopopts/TestOverunrolling.java fails
because a predicate doesn't constant fold anymore. The reason in that
case, is that PhaseIdealLoop::reorg_offsets() adds an Opaque2 between
the pre loop iv phi and the predicate that hides the type of the iv
phi. Without the change, the CastII captures the type of the iv phi
and the Opaque2 node is added between the CastII and the pre loop iv
phi. To solve that problem, I propose that
PhaseIdealLoop::reorg_offsets() always add a CastII after the Opaque2
so the type of the iv phi is not lost.

-------------

Commit messages:
 - test & fix

Changes: https://git.openjdk.java.net/jdk/pull/7758/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7758&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282592
  Stats: 85 lines in 3 files changed: 85 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7758.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7758/head:pull/7758

PR: https://git.openjdk.java.net/jdk/pull/7758

From thartmann at openjdk.java.net  Wed Mar  9 14:55:08 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 9 Mar 2022 14:55:08 GMT
Subject: RFR: 8272735: Add missing SubL node transformations
In-Reply-To: <eFzwVPibLwh_XoXsOlIJQ3qjARbwXJaIVQUOcVGrznA=.7cc15e6e-3c6a-4dba-9e90-6e216874e600@github.com>
References: <eFzwVPibLwh_XoXsOlIJQ3qjARbwXJaIVQUOcVGrznA=.7cc15e6e-3c6a-4dba-9e90-6e216874e600@github.com>
Message-ID: <xi6QrJ1OZoMqxeZ1nqKilxohbByoO1uaA01KF_SR5nc=.3a4a9e25-0d58-451d-a6a6-2ad49d0a2f26@github.com>

On Wed, 2 Mar 2022 21:28:13 GMT, Ahmed Muhsin <duke at openjdk.java.net> wrote:

> This change adds/enables missing subnode transformations for operations of type `long`.
> A few comments in the test file `SubINodeIdealizationTests.java` were modified to add clarity and to fix a typo.
> Hotspot:tier1 tests were run, this change does not introduce any new failures.

Did you sync up with @JohnTortugo on this (because the JBS issue is assigned to him)? It's not clear to me if you addressed all the issues that Cesar listed in the description.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7669

From duke at openjdk.java.net  Wed Mar  9 15:11:04 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 9 Mar 2022 15:11:04 GMT
Subject: RFR: 8282509: [exploded image] ResolvedTestClass fails on AIX with
 similar output [v3]
In-Reply-To: <hpS07D_1AxNvl_myFR9zMsKnNEfwaWkC4WLjYAO0Sv8=.fd4e803d-b8fb-4321-9b0f-88c02aeed7d7@github.com>
References: <5eb3C_3MU09ZBJSPs9ER4fM8u89e7T814CDtRDIdqAY=.04acec75-b1ca-44be-8bb2-140a51ca0a2b@github.com>
 <fr5IVsWDcO4aRHv_V7p_D3LZR3IFMvK3GfwrO0iVN3o=.4ef5feb9-0849-4b44-9e8e-314ecaee9449@github.com>
 <hpS07D_1AxNvl_myFR9zMsKnNEfwaWkC4WLjYAO0Sv8=.fd4e803d-b8fb-4321-9b0f-88c02aeed7d7@github.com>
Message-ID: <04eqCGME8A83Q9A64KkB8vc3cM43lq6tGqhUgAG6lqc=.e1ba3d0e-572a-413f-aecd-cb312a5f0536@github.com>

On Wed, 9 Mar 2022 13:30:29 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Remove leading chars not present in original test
>>  - Trial Solution: Replaces shouldContain with shouldMatch + Regex in ResolvedClassTest
>
> Looks reasonable. Please update the PR title: "[exploded image] ResolvedClassTest fails with similar output"

Thanks for the review @TheRealMDoerr. Should I wait for another review, or is one sufficient in this case?

---

For future reference, it looks to me that this failure is related to missing [pre-generated invokers](https://bugs.openjdk.java.net/browse/JDK-8247536). As I understand it, these are either not created, or just not linked in the exploded image, and are never created on AIX.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7701

From mdoerr at openjdk.java.net  Wed Mar  9 15:28:11 2022
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 9 Mar 2022 15:28:11 GMT
Subject: RFR: 8282509: [exploded image] ResolvedClassTest fails with
 similar output [v3]
In-Reply-To: <fr5IVsWDcO4aRHv_V7p_D3LZR3IFMvK3GfwrO0iVN3o=.4ef5feb9-0849-4b44-9e8e-314ecaee9449@github.com>
References: <5eb3C_3MU09ZBJSPs9ER4fM8u89e7T814CDtRDIdqAY=.04acec75-b1ca-44be-8bb2-140a51ca0a2b@github.com>
 <fr5IVsWDcO4aRHv_V7p_D3LZR3IFMvK3GfwrO0iVN3o=.4ef5feb9-0849-4b44-9e8e-314ecaee9449@github.com>
Message-ID: <zzozRwtibyRCtlscpF2JMSiakl11c5aERL1-zGL_u-U=.f588b508-7b8e-43f9-bf1f-1da3cbac3d3e@github.com>

On Mon, 7 Mar 2022 16:25:25 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> This is a tentative solution to a failure observed on AIX. The solution is tentative because I require help to ensure that something deeper and more problematic is not happening.
>> 
>> The test fails because the output produced by PrintCompilation produces `LambdaForm$MH/0x00000007c0002400` instead of `Invokers$Holder` as it does on other platforms. There is one other place the output is different, when `DirectMethodHandle$Holder` is replaced with `LambdaForm$DMH/0x00000007c0001c00`. Ignoring these name changes, the output of PrintCompilation is identical. I observe the same compilations (including the OSR/non-OSR, and same level) in the same order.
>> 
>> I would be grateful for help understanding the root of the difference behind the change. I have a few ideas, but I will let you build your own interpretations free from my potentially incorrect understanding (i.e. no spoilers). Thanks in advance.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Remove leading chars not present in original test
>  - Trial Solution: Replaces shouldContain with shouldMatch + Regex in ResolvedClassTest

I've added your additional hint to the issue and linked both issues. Thanks for your investigation.
Your fix could be considered as trivial, but the underlying issue is not. So, please wait for a 2nd review!
The test name in title is not yet correct: Please use "ResolvedClassTest"

-------------

PR: https://git.openjdk.java.net/jdk/pull/7701

From duke at openjdk.java.net  Wed Mar  9 15:29:09 2022
From: duke at openjdk.java.net (duke)
Date: Wed, 9 Mar 2022 15:29:09 GMT
Subject: Withdrawn: 8279057: Consolidate InstructionPrinter::do_BlockBegin and
 remove extra lines in logs of blocks with phi functions
In-Reply-To: <T2QVtmgb9uUkQOQw6XTmWNXquKOzENRHlPZyk4Ru5vc=.c6eff24a-271b-41aa-8e60-df5e554610f0@github.com>
References: <T2QVtmgb9uUkQOQw6XTmWNXquKOzENRHlPZyk4Ru5vc=.c6eff24a-271b-41aa-8e60-df5e554610f0@github.com>
Message-ID: <xsdvK9CeeCTEEKw9_TvJWu4geblXPkWitFP-TWbIQ1Y=.2b9d9d57-7eaa-472a-8a3e-06293c19afd7@github.com>

On Thu, 23 Dec 2021 01:11:08 GMT, Hamlin Li <mli at openjdk.org> wrote:

> This pr does following things:
>  - First, the code related to printing phi in InstructionPrinter::do_BlockBegin is bit redudant, it could be consolidated;
>  - Second, only locals and stack values related to phi functions are printed out now.
>  - Third, there are extra blank lines in printed log of blocks with phi functions, these blank lines are better to be removed.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6921

From psandoz at openjdk.java.net  Wed Mar  9 16:25:04 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 9 Mar 2022 16:25:04 GMT
Subject: RFR: 8282431: AArch64: Add optimized rules for masked vector
 multiply-add/sub for SVE
In-Reply-To: <qbrxScXbOnZOL3OE_2w7A7_Mgv1HrAuorN_3NUG72ZM=.3629070e-2535-44f2-bcd2-b23a299c7252@github.com>
References: <bRRrWEoEmJk24aLM-eRglGGIttZ2eAIBexmskoh4tdw=.34cca7f0-92b5-4e02-9019-036a29dfc066@github.com>
 <aeEQAjfbo-79P5Ap8MTsl8adxdeaKNNhJaafWgaDPzo=.dc7b68f3-4532-4c5a-a3b1-f4d5060e8db4@github.com>
 <qbrxScXbOnZOL3OE_2w7A7_Mgv1HrAuorN_3NUG72ZM=.3629070e-2535-44f2-bcd2-b23a299c7252@github.com>
Message-ID: <s-9cMmnrl7kt-aBurUycFF4mLXeeENqK4oZJ8S5Lo0Y=.8eeab3f4-8769-49b0-a3ce-c22c8842be66@github.com>

On Wed, 9 Mar 2022 09:21:54 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> And I misunderstood that the ir framework can only check the C2 IR nodes. Seems it can also check the assembly codes.

To be honest I was uncertain if the ir framework could do this. Worth investigating.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7737

From jbhateja at openjdk.java.net  Wed Mar  9 17:38:01 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 9 Mar 2022 17:38:01 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v8]
In-Reply-To: <T7_MCvcT2FaCfUeYUFN8mR_1p1wB8TxB6VH2UFf010U=.1f560b53-b400-4b42-b6a8-e9211061adc2@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <T7_MCvcT2FaCfUeYUFN8mR_1p1wB8TxB6VH2UFf010U=.1f560b53-b400-4b42-b6a8-e9211061adc2@github.com>
Message-ID: <9gTqZbzmPu7Ku91fOBSHhnx0jQzqXo-sP3klbj-7XH0=.a1ad8764-07f9-4626-9511-9127b71bc7bd@github.com>

On Tue, 8 Feb 2022 09:01:30 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8281375: Review comments resolved.
>
> Hi Jatin, nice work!
> 
> One quick comment - the _vector_popcount_lut it's generated unconditionally - could you guard it so that it's only generated when it can be used? My preferred choice would to be have it be generated lazily, but that's an enhancement all of it's own.
> 
> Best regards,
> Nils

> > @neliasso Could you please review and approve the patch if it looks ok to you? Jatin has incorporated changes suggested by you earlier. Paul Sandoz has tested the patch.
> 
> @sviswa7 , it seem @neliasso is on vacation. @PaulSandoz can anyone else review the patch.

Hi @vnkozlov , can you kindly review this patch. Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From Divino.Cesar at microsoft.com  Wed Mar  9 17:58:58 2022
From: Divino.Cesar at microsoft.com (Cesar Soares Lucas)
Date: Wed, 9 Mar 2022 17:58:58 +0000
Subject: Questions about C2 IR verification
Message-ID: <BY5PR21MB147332CD770CEE03DE3C4BF49A0A9@BY5PR21MB1473.namprd21.prod.outlook.com>

Hi there,

I?m working on a transformation on top of C2 IR and I?m getting an error message that's defying my C2 IR skills. This verification in PhaseIdealLoop (https://github.com/openjdk/jdk/blob/master/src%2Fhotspot%2Fshare%2Fopto%2Floopnode.cpp#L5344) is failing and I don?t understand why ? AFAIU the IR graph looks correct! Would you mind taking a quick look at the graph? I placed the IR printout, IR graphs and error message here: http://cr.openjdk.java.net/~cslucas/question0/.

I think the problem might be due to incorrect setting of the control input of some nodes. When *should* a node have a *direct* control input and when can I leave it NULL and therefore have a ?transitive? control?


TIA,
Cesar


From duke at openjdk.java.net  Wed Mar  9 18:13:35 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Wed, 9 Mar 2022 18:13:35 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters [v3]
In-Reply-To: <IfiCoeq30M-O9KOYSJi1qrYTVksYhPUBli6Ei5krCKk=.1b3cb377-1b94-44bd-8464-e20064696d08@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
 <nesf35P-utm5j-xosWGl1mnu1XPvBvfcCTyOALC-CCo=.e27238c3-0a48-4d2b-a788-f6ec2bdb96ca@github.com>
 <kOvHTLs8n3635oLdZCUDwnXyq_l8zZT5yEeRga_8DaE=.4b2eaeaa-8602-48f9-917a-2ba9d812b441@github.com>
 <LEWK5zYTVWrwc4wE1r95lAXtrt20Ebujj4lS2ols3C8=.e1f127b0-8801-4a92-9f77-a0ec6bbf9a4d@github.com>
 <IfiCoeq30M-O9KOYSJi1qrYTVksYhPUBli6Ei5krCKk=.1b3cb377-1b94-44bd-8464-e20064696d08@github.com>
Message-ID: <InXtOPsTmlrJqtHqbwjTxpdhdW23NopsMoE5kkn70PU=.2dae40ad-deb1-4a2d-b6df-aabcb7f5ac1b@github.com>

On Tue, 8 Mar 2022 16:15:10 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> I'm very sure the failure you are seeing is unrelated to my changes. Please note that JEP 338 (Vector API) is not supported on s390. I can reproduce the failure with a plain OpenJDK/jdk build of today.
> 
> Could you please verify that you see the failure with a plain build as well? Thank you!

@RealLucy, I believe you are correct. TestAutoVectorization2DArray.java is failing in the current master branch as well.


> Btw: sorry for reacting with such a long delay. Other duties were keeping me busy.

No problem at all!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7324

From duke at openjdk.java.net  Wed Mar  9 20:10:49 2022
From: duke at openjdk.java.net (Ahmed Muhsin)
Date: Wed, 9 Mar 2022 20:10:49 GMT
Subject: RFR: 8272735: Add missing SubL node transformations
In-Reply-To: <xi6QrJ1OZoMqxeZ1nqKilxohbByoO1uaA01KF_SR5nc=.3a4a9e25-0d58-451d-a6a6-2ad49d0a2f26@github.com>
References: <eFzwVPibLwh_XoXsOlIJQ3qjARbwXJaIVQUOcVGrznA=.7cc15e6e-3c6a-4dba-9e90-6e216874e600@github.com>
 <xi6QrJ1OZoMqxeZ1nqKilxohbByoO1uaA01KF_SR5nc=.3a4a9e25-0d58-451d-a6a6-2ad49d0a2f26@github.com>
Message-ID: <mQ8543xTpIFD_c7dED65ruiuzl2lIW6TjWnJ_KBNcjw=.2621887b-6b5c-44b2-9b7b-c4d5cdb4333a@github.com>

On Wed, 9 Mar 2022 14:51:43 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> This change adds/enables missing subnode transformations for operations of type `long`.
>> A few comments in the test file `SubINodeIdealizationTests.java` were modified to add clarity and to fix a typo.
>> Hotspot:tier1 tests were run, this change does not introduce any new failures.
>
> Did you sync up with @JohnTortugo on this (because the JBS issue is assigned to him)? It's not clear to me if you addressed all the issues that Cesar listed in the description.

Hey @TobiHartmann. Yep, @JohnTortugo and I reviewed this change together offline. The `AddINode` and `AddLNode` items that Cesar listed in his JBS issue were taken care of in [JDK-8278471: Remove unreached rules in AddNode::IdealIL](https://bugs.openjdk.java.net/browse/JDK-8278471#). This PR resolves the items that are left.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7669

From dlong at openjdk.java.net  Wed Mar  9 23:25:45 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 9 Mar 2022 23:25:45 GMT
Subject: RFR: 8282509: [exploded image] ResolvedClassTest fails with
 similar output [v3]
In-Reply-To: <fr5IVsWDcO4aRHv_V7p_D3LZR3IFMvK3GfwrO0iVN3o=.4ef5feb9-0849-4b44-9e8e-314ecaee9449@github.com>
References: <5eb3C_3MU09ZBJSPs9ER4fM8u89e7T814CDtRDIdqAY=.04acec75-b1ca-44be-8bb2-140a51ca0a2b@github.com>
 <fr5IVsWDcO4aRHv_V7p_D3LZR3IFMvK3GfwrO0iVN3o=.4ef5feb9-0849-4b44-9e8e-314ecaee9449@github.com>
Message-ID: <WccCMGCoh16ho3omWKBIn5-98fF_DD5lMBquW-AGC_E=.be453927-1d44-41a6-a93a-9320a93b5d99@github.com>

On Mon, 7 Mar 2022 16:25:25 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> This is a tentative solution to a failure observed on AIX. The solution is tentative because I require help to ensure that something deeper and more problematic is not happening.
>> 
>> The test fails because the output produced by PrintCompilation produces `LambdaForm$MH/0x00000007c0002400` instead of `Invokers$Holder` as it does on other platforms. There is one other place the output is different, when `DirectMethodHandle$Holder` is replaced with `LambdaForm$DMH/0x00000007c0001c00`. Ignoring these name changes, the output of PrintCompilation is identical. I observe the same compilations (including the OSR/non-OSR, and same level) in the same order.
>> 
>> I would be grateful for help understanding the root of the difference behind the change. I have a few ideas, but I will let you build your own interpretations free from my potentially incorrect understanding (i.e. no spoilers). Thanks in advance.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Remove leading chars not present in original test
>  - Trial Solution: Replaces shouldContain with shouldMatch + Regex in ResolvedClassTest

This does seem like the best fix.

-------------

Marked as reviewed by dlong (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7701

From pli at openjdk.java.net  Thu Mar 10 01:22:43 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Thu, 10 Mar 2022 01:22:43 GMT
Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v4]
In-Reply-To: <DPPICoKR2tIZ8nbOaBDV2vFi7dp-lCjSnPbOc4ExeJc=.861804f6-b8fa-4d0d-9504-238ea0a89ccc@github.com>
References: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
 <DPPICoKR2tIZ8nbOaBDV2vFi7dp-lCjSnPbOc4ExeJc=.861804f6-b8fa-4d0d-9504-238ea0a89ccc@github.com>
Message-ID: <s_Ex3nvg4Tk1uDcPMP3WgJhm_XidzQjV7_m9ve5jE84=.e029d820-069e-4e38-8332-9dc61144b500@github.com>

On Mon, 21 Feb 2022 06:19:26 GMT, Pengfei Li <pli at openjdk.org> wrote:

>> ### Background
>> 
>> Post loop vectorization is a C2 compiler optimization in an experimental
>> VM feature called PostLoopMultiversioning. It transforms the range-check
>> eliminated post loop to a 1-iteration vectorized loop with vector mask.
>> This optimization was contributed by Intel in 2016 to support x86 AVX512
>> masked vector instructions. However, it was disabled soon after an issue
>> was found. Due to insufficient maintenance in these years, multiple bugs
>> have been accumulated inside. But we (Arm) still think this is a useful
>> framework for vector mask support in C2 auto-vectorized loops, for both
>> x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
>> post loop vectorization.
>> 
>> ### Changes in this patch
>> 
>> This patch reworks post loop vectorization. The most significant change
>> is removing vector mask support in C2 x86 backend and re-implementing
>> it in the mid-end. With this, we can re-enable post loop vectorization
>> for platforms other than x86.
>> 
>> Previous implementation hard-codes x86 k1 register as a reserved AVX512
>> opmask register and defines two routines (setvectmask/restorevectmask)
>> to set and restore the value of k1. But after [JDK-8211251](https://bugs.openjdk.java.net/browse/JDK-8211251) which encodes
>> AVX512 instructions as unmasked by default, generated vector masks are
>> no longer used in AVX512 vector instructions. To fix incorrect codegen
>> and add vector mask support for more platforms, we turn to add a vector
>> mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
>> to generate a mask and replace all Load/Store nodes in the post loop
>> into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
>> IR form is exactly the same to those which are used in VectorAPI mask
>> support. For now, we only add mask inputs for Load/Store nodes because
>> we don't have reduction operations supported in post loop vectorization.
>> After this change, the x86 k1 register is no longer reserved and can be
>> allocated when PostLoopMultiversioning is enabled.
>> 
>> Besides this change, we have fixed a compiler crash and five incorrect
>> result issues with post loop vectorization.
>> 
>> **I) C2 crashes with segmentation fault in strip-mined loops**
>> 
>> Previous implementation was done before C2 loop strip-mining was merged
>> into JDK master so it didn't take strip-mined loops into consideration.
>> In C2's strip mined loops, post loop is not the sibling of the main loop
>> in ideal loop tree. Instead, it's the sibling of the main loop's parent.
>> This patch fixed a SIGSEGV issue caused by NULL pointer when locating
>> post loop from strip-mined main loop.
>> 
>> **II) Incorrect result issues with post loop vectorization**
>> 
>> We have also fixed five incorrect vectorization issues. Some of them are
>> hidden deep and can only be reproduced with corner cases. These issues
>> have a common cause that it assumes the post loop can be vectorized if
>> the vectorization in corresponding main loop is successful. But in many
>> cases this assumption is wrong. Below are details.
>> 
>> - **[Issue-1] Incorrect vectorization for partial vectorizable loops**
>> 
>> This issue can be reproduced by below loop where only some operations in
>> the loop body are vectorizable.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     res[i] = a[i] * b[i];
>>     k = 3 * k + 1;
>>   }
>> 
>> In the main loop, superword can work well if parts of the operations in
>> loop body are not vectorizable since those parts can be unrolled only.
>> But for post loops, we don't create vectors through combining scalar IRs
>> generated from loop unrolling. Instead, we are doing scalars to vectors
>> replacement for all operations in the loop body. Hence, all operations
>> should be either vectorized together or not vectorized at all. To fix
>> this kind of cases, we add an extra field "_slp_vector_pack_count" in
>> CountedLoopNode to record the eventual count of vector packs in the main
>> loop. This value is then passed to post loop and compared with post loop
>> pack count. Vectorization will be bailed out in post loop if it creates
>> more vector packs than in the main loop.
>> 
>> - **[Issue-2] Incorrect result in loops with growing-down vectors**
>> 
>> This issue appears with growing-down vectors, that is, vectors that grow
>> to smaller memory address as the loop iterates. It can be reproduced by
>> below counting-up loop with negative scale value in array index.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     a[MAX - i] = b[MAX - i];
>>   }
>> 
>> Cause of this issue is that for a growing-down vector, generated vector
>> mask value has reversed vector-lane order so it masks incorrect vector
>> lanes. Note that if negative scale value appears in counting-down loops,
>> the vector will be growing up. With this rule, we fix the issue by only
>> allowing positive array index scales in counting-up loops and negative
>> array index scales in counting-down loops. This check is done with the
>> help of SWPointer by comparing scale values in each memory access in the
>> loop with loop stride value.
>> 
>> - **[Issue-3] Incorrect result in manually unrolled loops**
>> 
>> This issue can be reproduced by below manually unrolled loop.
>> 
>>   for (int i = 0; i < 10000; i += 2) {
>>     c[i] = a[i] + b[i];
>>     c[i + 1] = a[i + 1] * b[i + 1];
>>   }
>> 
>> In this loop, operations in the 2nd statement duplicate those in the 1st
>> statement with a small memory address offset. Vectorization in the main
>> loop works well in this case because C2 does further unrolling and pack
>> combination. But we cannot vectorize the post loop through replacement
>> from scalars to vectors because it creates duplicated vector operations.
>> To fix this, we restrict post loop vectorization to loops with stride
>> values of 1 or -1.
>> 
>> - **[Issue-4] Incorrect result in loops with mixed vector element sizes**
>> 
>> This issue is found after we enable post loop vectorization for AArch64.
>> It's reproducible by multiple array operations with different element
>> sizes inside a loop. On x86, there is no issue because the values of x86
>> AVX512 opmasks only depend on which vector lanes are active. But AArch64
>> is different - the values of SVE predicates also depend on lane size of
>> the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
>> sizes, we should use different vector masks. For now, we just support
>> loops with only one vector element size, i.e., "int + float" vectors in
>> a single loop is ok but "int + double" vectors in a single loop is not
>> vectorizable. This fix also enables subword vectors support to make all
>> primitive type array operations vectorizable.
>> 
>> - **[Issue-5] Incorrect result in loops with potential data dependence**
>> 
>> This issue can be reproduced by below corner case on AArch64 only.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     a[i] = x;
>>     a[i + OFFSET] = y;
>>   }
>> 
>> In this case, two stores in the loop have data dependence if the OFFSET
>> value is smaller than the vector length. So we cannot do vectorization
>> through replacing scalars to vectors. But the main loop vectorization
>> in this case is successful on AArch64 because AArch64 has partial vector
>> load/store support. It splits vector fill with different values in lanes
>> to several smaller-sized fills. In this patch, we add additional data
>> dependence check for this kind of cases. The check is also done with the
>> help of SWPointer class. In this check, we require that every two memory
>> accesses (with at least one store) of the same element type (or subword
>> size) in the loop has the same array index expression.
>> 
>> ### Tests
>> 
>> So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
>> experimental VM option "PostLoopMultiversioning" turned on. We found no
>> issue in all tests. We notice that those existing cases are not enough
>> because some of above issues are not spotted by them. We would like to
>> add some new cases but we found existing vectorization tests are a bit
>> cumbersome - golden results must be pre-calculated and hard-coded in the
>> test code for correctness verification. Thus, in this patch, we propose
>> a new vectorization testing framework.
>> 
>> Our new framework brings a simpler way to add new cases. For a new test
>> case, we only need to create a new method annotated with "@Test". The
>> test runner will invoke each annotated method twice automatically. First
>> time it runs in the interpreter and second time it's forced compiled by
>> C2. Then the two return results are compared. So in this framework each
>> test method should return a primitive value or an array of primitives.
>> In this way, no extra verification code for vectorization correctness is
>> required. This test runner is still jtreg-based and takes advantages of
>> the jtreg WhiteBox API, which enables test methods running at specific
>> compilation levels. Each test class inside is also jtreg-based. It just
>> need to inherit from the test runner class and run with two additional
>> options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
>> 
>> ### Summary & Future work
>> 
>> In this patch, we reworked post loop vectorization. We made it platform
>> independent and fixed several issues inside. We also implemented a new
>> vectorization testing framework with many test cases inside. Meanwhile,
>> we did some code cleanups.
>> 
>> This patch only touches C2 code guarded with PostLoopMultiversioning,
>> except a few data structure changes. So, there's no behavior change when
>> experimental VM option PostLoopMultiversioning is off. Also, to reduce
>> risks, we still propose to keep post loop vectorization experimental for
>> now. But if it receives positive feedback, we would like to change it to
>> non-experimental in the future.
>
> Pengfei Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into postloop
>    
>    Change-Id: I503edb75f0f626569c776416bfef09651935979c
>  - Update copyright year and rename a function
>    
>    Change-Id: I15845ebd3982edebd4c151284cc6f2ff727630bb
>  - Merge branch 'master' into postloop
>    
>    Change-Id: Ie639c79c9cf016dc68ebf2c0031b60453b45e9a4
>  - Fix issues in newly added test framework
>    
>    Change-Id: I6e61abf05e9665325cb3abaf407360b18355c6b1
>  - Merge branch 'master' into postloop
>    
>    Change-Id: I9bb5a808d7540426dedb141fd198d25eb1f569e6
>  - 8183390: Fix and re-enable post loop vectorization
>    
>    ** Background
>    
>    Post loop vectorization is a C2 compiler optimization in an experimental
>    VM feature called PostLoopMultiversioning. It transforms the range-check
>    eliminated post loop to a 1-iteration vectorized loop with vector mask.
>    This optimization was contributed by Intel in 2016 to support x86 AVX512
>    masked vector instructions. However, it was disabled soon after an issue
>    was found. Due to insufficient maintenance in these years, multiple bugs
>    have been accumulated inside. But we (Arm) still think this is a useful
>    framework for vector mask support in C2 auto-vectorized loops, for both
>    x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
>    post loop vectorization.
>    
>    ** Changes in this patch
>    
>    This patch reworks post loop vectorization. The most significant change
>    is removing vector mask support in C2 x86 backend and re-implementing
>    it in the mid-end. With this, we can re-enable post loop vectorization
>    for platforms other than x86.
>    
>    Previous implementation hard-codes x86 k1 register as a reserved AVX512
>    opmask register and defines two routines (setvectmask/restorevectmask)
>    to set and restore the value of k1. But after JDK-8211251 which encodes
>    AVX512 instructions as unmasked by default, generated vector masks are
>    no longer used in AVX512 vector instructions. To fix incorrect codegen
>    and add vector mask support for more platforms, we turn to add a vector
>    mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
>    to generate a mask and replace all Load/Store nodes in the post loop
>    into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
>    IR form is exactly the same to those which are used in VectorAPI mask
>    support. For now, we only add mask inputs for Load/Store nodes because
>    we don't have reduction operations supported in post loop vectorization.
>    After this change, the x86 k1 register is no longer reserved and can be
>    allocated when PostLoopMultiversioning is enabled.
>    
>    Besides this change, we have fixed a compiler crash and five incorrect
>    result issues with post loop vectorization.
>    
>    - 1) C2 crashes with segmentation fault in strip-mined loops
>    
>    Previous implementation was done before C2 loop strip-mining was merged
>    into JDK master so it didn't take strip-mined loops into consideration.
>    In C2's strip mined loops, post loop is not the sibling of the main loop
>    in ideal loop tree. Instead, it's the sibling of the main loop's parent.
>    This patch fixed a SIGSEGV issue caused by NULL pointer when locating
>    post loop from strip-mined main loop.
>    
>    - 2) Incorrect result issues with post loop vectorization
>    
>    We have also fixed five incorrect vectorization issues. Some of them are
>    hidden deep and can only be reproduced with corner cases. These issues
>    have a common cause that it assumes the post loop can be vectorized if
>    the vectorization in corresponding main loop is successful. But in many
>    cases this assumption is wrong. Below are details.
>    
>    [Issue-1] Incorrect vectorization for partial vectorizable loops
>    
>    This issue can be reproduced by below loop where only some operations in
>    the loop body are vectorizable.
>    
>      for (int i = 0; i < 10000; i++) {
>        res[i] = a[i] * b[i];
>        k = 3 * k + 1;
>      }
>    
>    In the main loop, superword can work well if parts of the operations in
>    loop body are not vectorizable since those parts can be unrolled only.
>    But for post loops, we don't create vectors through combining scalar IRs
>    generated from loop unrolling. Instead, we are doing scalars to vectors
>    replacement for all operations in the loop body. Hence, all operations
>    should be either vectorized together or not vectorized at all. To fix
>    this kind of cases, we add an extra field "_slp_vector_pack_count" in
>    CountedLoopNode to record the eventual count of vector packs in the main
>    loop. This value is then passed to post loop and compared with post loop
>    pack count. Vectorization will be bailed out in post loop if it creates
>    more vector packs than in the main loop.
>    
>    [Issue-2] Incorrect result in loops with growing-down vectors
>    
>    This issue appears with growing-down vectors, that is, vectors that grow
>    to smaller memory address as the loop iterates. It can be reproduced by
>    below counting-up loop with negative scale value in array index.
>    
>      for (int i = 0; i < 10000; i++) {
>        a[MAX - i] = b[MAX - i];
>      }
>    
>    Cause of this issue is that for a growing-down vector, generated vector
>    mask value has reversed vector-lane order so it masks incorrect vector
>    lanes. Note that if negative scale value appears in counting-down loops,
>    the vector will be growing up. With this rule, we fix the issue by only
>    allowing positive array index scales in counting-up loops and negative
>    array index scales in counting-down loops. This check is done with the
>    help of SWPointer by comparing scale values in each memory access in the
>    loop with loop stride value.
>    
>    [Issue-3] Incorrect result in manually unrolled loops
>    
>    This issue can be reproduced by below manually unrolled loop.
>    
>      for (int i = 0; i < 10000; i += 2) {
>        c[i] = a[i] + b[i];
>        c[i + 1] = a[i + 1] * b[i + 1];
>      }
>    
>    In this loop, operations in the 2nd statement duplicate those in the 1st
>    statement with a small memory address offset. Vectorization in the main
>    loop works well in this case because C2 does further unrolling and pack
>    combination. But we cannot vectorize the post loop through replacement
>    from scalars to vectors because it creates duplicated vector operations.
>    To fix this, we restrict post loop vectorization to loops with stride
>    values of 1 or -1.
>    
>    [Issue-4] Incorrect result in loops with mixed vector element sizes
>    
>    This issue is found after we enable post loop vectorization for AArch64.
>    It's reproducible by multiple array operations with different element
>    sizes inside a loop. On x86, there is no issue because the values of x86
>    AVX512 opmasks only depend on which vector lanes are active. But AArch64
>    is different - the values of SVE predicates also depend on lane size of
>    the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
>    sizes, we should use different vector masks. For now, we just support
>    loops with only one vector element size, i.e., "int + float" vectors in
>    a single loop is ok but "int + double" vectors in a single loop is not
>    vectorizable. This fix also enables subword vectors support to make all
>    primitive type array operations vectorizable.
>    
>    [Issue-5] Incorrect result in loops with potential data dependence
>    
>    This issue can be reproduced by below corner case on AArch64 only.
>    
>      for (int i = 0; i < 10000; i++) {
>        a[i] = x;
>        a[i + OFFSET] = y;
>      }
>    
>    In this case, two stores in the loop have data dependence if the OFFSET
>    value is smaller than the vector length. So we cannot do vectorization
>    through replacing scalars to vectors. But the main loop vectorization
>    in this case is successful on AArch64 because AArch64 has partial vector
>    load/store support. It splits vector fill with different values in lanes
>    to several smaller-sized fills. In this patch, we add additional data
>    dependence check for this kind of cases. The check is also done with the
>    help of SWPointer class. In this check, we require that every two memory
>    accesses (with at least one store) of the same element type (or subword
>    size) in the loop has the same array index expression.
>    
>    ** Tests
>    
>    So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
>    experimental VM option "PostLoopMultiversioning" turned on. We found no
>    issue in all tests. We notice that those existing cases are not enough
>    because some of above issues are not spotted by them. We would like to
>    add some new cases but we found existing vectorization tests are a bit
>    cumbersome - golden results must be pre-calculated and hard-coded in the
>    test code for correctness verification. Thus, in this patch, we propose
>    a new vectorization testing framework.
>    
>    Our new framework brings a simpler way to add new cases. For a new test
>    case, we only need to create a new method annotated with "@Test". The
>    test runner will invoke each annotated method twice automatically. First
>    time it runs in the interpreter and second time it's forced compiled by
>    C2. Then the two return results are compared. So in this framework each
>    test method should return a primitive value or an array of primitives.
>    In this way, no extra verification code for vectorization correctness is
>    required. This test runner is still jtreg-based and takes advantages of
>    the jtreg WhiteBox API, which enables test methods running at specific
>    compilation levels. Each test class inside is also jtreg-based. It just
>    need to inherit from the test runner class and run with two additional
>    options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
>    
>    ** Summary & Future work
>    
>    In this patch, we reworked post loop vectorization. We made it platform
>    independent and fixed several issues inside. We also implemented a new
>    vectorization testing framework with many test cases inside. Meanwhile,
>    we did some code cleanups.
>    
>    This patch only touches C2 code guarded with PostLoopMultiversioning,
>    except a few data structure changes. So, there's no behavior change when
>    experimental VM option PostLoopMultiversioning is off. Also, to reduce
>    risks, we still propose to keep post loop vectorization experimental for
>    now. But if it receives positive feedback, we would like to change it to
>    non-experimental in the future.

Since reviewers don't know much about the background of this patch, I have created some slides explaining current problem, the motivation and our plans. You could find my slides at http://cr.openjdk.java.net/~pli/slides/JDK-8183390.pdf

-------------

PR: https://git.openjdk.java.net/jdk/pull/6828

From manc at openjdk.java.net  Thu Mar 10 05:38:38 2022
From: manc at openjdk.java.net (Man Cao)
Date: Thu, 10 Mar 2022 05:38:38 GMT
Subject: RFR: 8282507: Add LICENSE file for hsdis
In-Reply-To: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
References: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
Message-ID: <4pRhIx480labowUn7Kz-ahxqHbSF3DslHDT_HU-ewY4=.fc7bf07d-9ea7-4a02-9df7-b58aaa16f1c0@github.com>

On Tue, 1 Mar 2022 20:18:11 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone help review the addition of LICENSE file to hsdis directory?
> 
> -Man

Any updates on whether this is acceptable?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7649

From roberto.castaneda.lozano at oracle.com  Thu Mar 10 07:00:30 2022
From: roberto.castaneda.lozano at oracle.com (=?UTF-8?Q?Roberto_Casta=c3=b1eda_Lozano?=)
Date: Thu, 10 Mar 2022 08:00:30 +0100
Subject: Questions about C2 IR verification
In-Reply-To: <BY5PR21MB147332CD770CEE03DE3C4BF49A0A9@BY5PR21MB1473.namprd21.prod.outlook.com>
References: <BY5PR21MB147332CD770CEE03DE3C4BF49A0A9@BY5PR21MB1473.namprd21.prod.outlook.com>
Message-ID: <c859ae5a-8e02-774b-602a-45e603103df8@oracle.com>

Hi Cesar,

On 2022-03-09 18:58, Cesar Soares Lucas wrote:
> Would you mind taking a quick look at the graph? I placed the IR printout, IR graphs and error message here: http://cr.openjdk.java.net/~cslucas/question0/.

Could you perhaps also upload the corresponding XML graph file as 
emitted by -XX:PrintIdealGraphLevel=N -XX:PrintIdealGraphFile=FILE?

Thanks,

Roberto

From xgong at openjdk.java.net  Thu Mar 10 07:55:15 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 10 Mar 2022 07:55:15 GMT
Subject: RFR: 8282431: AArch64: Add optimized rules for masked vector
 multiply-add/sub for SVE [v2]
In-Reply-To: <bRRrWEoEmJk24aLM-eRglGGIttZ2eAIBexmskoh4tdw=.34cca7f0-92b5-4e02-9019-036a29dfc066@github.com>
References: <bRRrWEoEmJk24aLM-eRglGGIttZ2eAIBexmskoh4tdw=.34cca7f0-92b5-4e02-9019-036a29dfc066@github.com>
Message-ID: <SW3zLs9MPHtWkj6c9SdEFOUaCjAIQ6wpAoTF6gaY80I=.89ff44d1-db70-4c82-ad88-02e1e49bff63@github.com>

> We have the optimized match rules for vector `"fmls,fnmla,fnmls,mla,mls"` for ARM SVE. Similarly we can also add the rules for the relative masked operations to generate the optimized predicated instructions.
> 
> With this patch the following masked vector multiply-add for a byte vector:
> 
>   mul z18.b, p7/m, z18.b, z17.b
>   add z17.b, p0/m, z17.b, z18.b
> 
> could be optimized to: 
> 
>    mla z19.b, p0/m, z18.b, z17.b
> 
>  And so does the multiply-sub operations. Also the following masked fused multiply-substract for a float vector:
> 
>   fneg    z18.s, p7/m, z18.s
>   fmad    z17.s, p0/m, z18.s, z16.s
> 
> could be optimized to: 
> 
>   fmsb z17.s, p0/m, z18.s, z16.s"
> 
>  And the same to the relative negated fused operations.
> 
> This patch also fixes the potential issues for the usage of `NegVF/D` in match rules. The explicit check of non-predicated vector for `NegVF/D` must be added to the match rule predicate if the `NegVF/D` is assumed to be non-masked. Otherwise, the jvm might crash if a masked` NegVF/D` with two operands is matched into a rule which assumes the `NegVF/D` in subtree has one operand.
> 
> Also add the jtreg tests for all the touched vector operations.

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Use the ir framework for the test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7737/files
  - new: https://git.openjdk.java.net/jdk/pull/7737/files/e69e1b0a..20f1e106

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7737&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7737&range=00-01

  Stats: 93 lines in 1 file changed: 30 ins; 30 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7737.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7737/head:pull/7737

PR: https://git.openjdk.java.net/jdk/pull/7737

From xgong at openjdk.java.net  Thu Mar 10 07:58:37 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 10 Mar 2022 07:58:37 GMT
Subject: RFR: 8282431: AArch64: Add optimized rules for masked vector
 multiply-add/sub for SVE
In-Reply-To: <s-9cMmnrl7kt-aBurUycFF4mLXeeENqK4oZJ8S5Lo0Y=.8eeab3f4-8769-49b0-a3ce-c22c8842be66@github.com>
References: <bRRrWEoEmJk24aLM-eRglGGIttZ2eAIBexmskoh4tdw=.34cca7f0-92b5-4e02-9019-036a29dfc066@github.com>
 <aeEQAjfbo-79P5Ap8MTsl8adxdeaKNNhJaafWgaDPzo=.dc7b68f3-4532-4c5a-a3b1-f4d5060e8db4@github.com>
 <qbrxScXbOnZOL3OE_2w7A7_Mgv1HrAuorN_3NUG72ZM=.3629070e-2535-44f2-bcd2-b23a299c7252@github.com>
 <s-9cMmnrl7kt-aBurUycFF4mLXeeENqK4oZJ8S5Lo0Y=.8eeab3f4-8769-49b0-a3ce-c22c8842be66@github.com>
Message-ID: <gwkuurA8AMbBMAj8A-dvKWNOQzTKNtYQkW2JkQfYL2U=.c0c608f0-3951-46e3-a67a-eb38ac57e4ed@github.com>

On Wed, 9 Mar 2022 16:21:36 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > And I misunderstood that the ir framework can only check the C2 IR nodes. Seems it can also check the assembly codes.
> 
> To be honest I was uncertain if the ir framework could do this. Worth investigating.

Yeah, since it checks the output of `-XX:+PrintOptoAssembly`, it can got the information from the "format" in a rule. I'v updated the test to check the SVE assembler codes. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7737

From yyang at openjdk.java.net  Thu Mar 10 08:01:56 2022
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 10 Mar 2022 08:01:56 GMT
Subject: RFR: 8272493: Suboptimal code generation around
 Preconditions.checkIndex intrinsic with AVX2
Message-ID: <d6vxMPlAG4HLL0Z-D25Rh4ZAu-Eo2Sm_quO-a8QZ6ao=.e22e7e56-6f94-422e-a5ae-8ffeb6cc954a@github.com>

8272493 reports a minor regression when using Preconditions.checkIndex in String.checkIndex. The reason is some unnecessary vzeroupper instructions were emitted. The vzerouppers are introduced in [JDK-8190934](https://bugs.openjdk.java.net/browse/JDK-8190934), which are emitted by clear_upper_avx within inline_preconditions_checkIndex. I did some digging into the history of this code. Please correct me if I misunderstand something

[JDK-8178811](https://bugs.openjdk.java.net/browse/JDK-8178811) emits vzeroupper on every MachEpilogueNode to avoid AVX <-> SSE transition penalty during the call.

[JDK-8190934](https://bugs.openjdk.java.net/browse/JDK-8190934) emits vzeroupper on some MachEpilogueNode by setting clear_upper_avx flag, because vzeroupper itself is a high-cost instruction, we don't want to emit it everywhere a function is finished.

[JDK-8272493](https://bugs.openjdk.java.net/browse/JDK-8272493) emits vzeroupper because inline_preconditions_checkIndex sets clear_upper_avx flag.

Micro benchmark are as follows

-------Preconditions.checkIndex without clear_upper_avx
Benchmark Mode Cnt Score Error Units
StringBuilders.charAtLatin1 avgt 15 6.257 ? 0.011 ns/op

Benchmark Mode Cnt Score Error Units
StringBuilders.charAtLatin1 avgt 15 6.251 ? 0.008 ns/op

Benchmark Mode Cnt Score Error Units
StringBuilders.charAtLatin1 avgt 15 6.254 ? 0.003 ns/op

-------Preconditions.checkIndex with clear_upper_avx(Current Implementation)
Benchmark Mode Cnt Score Error Units
StringBuilders.charAtLatin1 avgt 15 6.421 ? 0.003 ns/op

Benchmark Mode Cnt Score Error Units
StringBuilders.charAtLatin1 avgt 15 6.419 ? 0.002 ns/op

Benchmark Mode Cnt Score Error Units
StringBuilders.charAtLatin1 avgt 15 6.433 ? 0.044 ns/op

------- -XX:DisableIntrinsic=_Preconditions_checkIndex
Benchmark Mode Cnt Score Error Units
StringBuilders.charAtLatin1 avgt 15 6.229 ? 0.018 ns/op

Benchmark Mode Cnt Score Error Units
StringBuilders.charAtLatin1 avgt 15 6.224 ? 0.006 ns/op

Benchmark Mode Cnt Score Error Units
StringBuilders.charAtLatin1 avgt 15 6.218 ? 0.011 ns/op

------- -XX:UseAVX=1
Benchmark Mode Cnt Score Error Units
StringBuilders.charAtLatin1 avgt 15 6.247 ? 0.022 ns/op

Benchmark Mode Cnt Score Error Units
StringBuilders.charAtLatin1 avgt 15 6.234 ? 0.018 ns/op

Benchmark Mode Cnt Score Error Units
StringBuilders.charAtLatin1 avgt 15 6.261 ? 0.042 ns/op

As I understand, inline_Preconditions_checkIndex only do some simple range check, there is no xmm(sse)/ymm(avx) 
 registers involved, so I propose to remove clear_upper_avx flag to avoid emitting vzeroupper for this intrinsic.

-------------

Commit messages:
 - 8272493: Suboptimal code generation around Preconditions.checkIndex intrinsic with AVX2

Changes: https://git.openjdk.java.net/jdk/pull/7770/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7770&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272493
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7770.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7770/head:pull/7770

PR: https://git.openjdk.java.net/jdk/pull/7770

From duke at openjdk.java.net  Thu Mar 10 08:22:41 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 10 Mar 2022 08:22:41 GMT
Subject: RFR: 8272493: Suboptimal code generation around
 Preconditions.checkIndex intrinsic with AVX2
In-Reply-To: <d6vxMPlAG4HLL0Z-D25Rh4ZAu-Eo2Sm_quO-a8QZ6ao=.e22e7e56-6f94-422e-a5ae-8ffeb6cc954a@github.com>
References: <d6vxMPlAG4HLL0Z-D25Rh4ZAu-Eo2Sm_quO-a8QZ6ao=.e22e7e56-6f94-422e-a5ae-8ffeb6cc954a@github.com>
Message-ID: <KR-oBJa1aVjlrXj3ozDorT6UHzLh4CZY3UgUucOibQY=.27417b01-5c7a-4b04-bb78-a76a5871d620@github.com>

On Thu, 10 Mar 2022 07:55:16 GMT, Yi Yang <yyang at openjdk.org> wrote:

> 8272493 reports a minor regression when using Preconditions.checkIndex in String.checkIndex. The reason is some unnecessary vzeroupper instructions were emitted. The vzerouppers are introduced in [JDK-8190934](https://bugs.openjdk.java.net/browse/JDK-8190934), which are emitted by clear_upper_avx within inline_preconditions_checkIndex. I did some digging into the history of this code. Please correct me if I misunderstand something
> 
> [JDK-8178811](https://bugs.openjdk.java.net/browse/JDK-8178811) emits vzeroupper on every MachEpilogueNode to avoid AVX <-> SSE transition penalty during the call.
> 
> [JDK-8190934](https://bugs.openjdk.java.net/browse/JDK-8190934) emits vzeroupper on some MachEpilogueNode by setting clear_upper_avx flag, because vzeroupper itself is a high-cost instruction, we don't want to emit it everywhere a function is finished.
> 
> [JDK-8272493](https://bugs.openjdk.java.net/browse/JDK-8272493) emits vzeroupper because inline_preconditions_checkIndex sets clear_upper_avx flag.
> 
> Micro benchmark are as follows
> 
> -------Preconditions.checkIndex without clear_upper_avx
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.257 ? 0.011 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.251 ? 0.008 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.254 ? 0.003 ns/op
> 
> -------Preconditions.checkIndex with clear_upper_avx(Current Implementation)
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.421 ? 0.003 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.419 ? 0.002 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.433 ? 0.044 ns/op
> 
> ------- -XX:DisableIntrinsic=_Preconditions_checkIndex
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.229 ? 0.018 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.224 ? 0.006 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.218 ? 0.011 ns/op
> 
> ------- -XX:UseAVX=1
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.247 ? 0.022 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.234 ? 0.018 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.261 ? 0.042 ns/op
> 
> As I understand, inline_Preconditions_checkIndex only do some simple range check, there is no xmm(sse)/ymm(avx) 
>  registers involved, so I propose to remove clear_upper_avx flag to avoid emitting vzeroupper for this intrinsic.

IMO the hotspot seems to be too conservative and yet not cover all the cases regarding the generation of `vzeroupper`. Given the assembler itself doesn't emit SSE legacy code on AVX machines, this instruction coud be emitted only on transition to native/VM code (and maybe the interpreter?). The current state generates `vzeroupper` on every function return and function call if 256-bit vector is involved, which is less than optimal. On the other hand, `clear_upper_avx` only emits `vzeroupper` on AVX2, when we clearly have 256-bit vectors on AVX1?

Please correct me if I miss something important here, thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7770

From yyang at openjdk.java.net  Thu Mar 10 09:02:40 2022
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 10 Mar 2022 09:02:40 GMT
Subject: RFR: 8272493: Suboptimal code generation around
 Preconditions.checkIndex intrinsic with AVX2
In-Reply-To: <KR-oBJa1aVjlrXj3ozDorT6UHzLh4CZY3UgUucOibQY=.27417b01-5c7a-4b04-bb78-a76a5871d620@github.com>
References: <d6vxMPlAG4HLL0Z-D25Rh4ZAu-Eo2Sm_quO-a8QZ6ao=.e22e7e56-6f94-422e-a5ae-8ffeb6cc954a@github.com>
 <KR-oBJa1aVjlrXj3ozDorT6UHzLh4CZY3UgUucOibQY=.27417b01-5c7a-4b04-bb78-a76a5871d620@github.com>
Message-ID: <TO8u8oTSl9Iizqa465WhQilxHDsJH2vqUsbWu9qwbpM=.6f8f31b6-65e4-47ae-a86c-e08ff5936086@github.com>

On Thu, 10 Mar 2022 08:19:50 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> IMO the hotspot seems to be too conservative and yet not cover all the cases regarding the generation of `vzeroupper`. Given the assembler itself doesn't emit SSE legacy code on AVX machines, this instruction coud be emitted only on transition to native/VM code (and maybe the interpreter?). The current state generates `vzeroupper` on every function return and function call if 256-bit vector is involved, which is less than optimal. On the other hand, `clear_upper_avx` only emits `vzeroupper` on AVX2, when we clearly have 256-bit vectors on AVX1?
> 
> Please correct me if I miss something important here, thanks.

Hi @merykitty, sorry I didn't fully understand what you meant, do you mean the JVM is missing vzeroupper somewhere? Can you elaborate more on where we are able to emit them while we don't do that now?

> The current state generates vzeroupper on every function return and function call if 256-bit vector is involved, which is less than optimal.

It seems that currently we only emit vzeroupper on some function return or function call when they set clear_upper_avx flag or max_vector_size >16:

// Call
  enc_class clear_avx %{
    if (generate_vzeroupper(Compile::current())) {
      MacroAssembler _masm(&cbuf);
      __ vzeroupper();
    }
  %}

instruct CallDynamicJavaDirect(method meth)
%{
  match(CallDynamicJava);
  effect(USE meth);

  ins_cost(300);
  format %{ "movq    rax, #Universe::non_oop_word()\n\t"
            "call,dynamic " %}
  ins_encode(clear_avx, Java_Dynamic_Call(meth), call_epilog);
  ins_pipe(pipe_slow);
  ins_alignment(4);
%}

instruct CallRuntimeDirect(method meth)
%{
  match(CallRuntime);
  effect(USE meth);

  ins_cost(300);
  format %{ "call,runtime " %}
  ins_encode(clear_avx, Java_To_Runtime(meth));
  ins_pipe(pipe_slow);
%}

instruct CallLeafDirect(method meth)
%{
  match(CallLeaf);
  effect(USE meth);

  ins_cost(300);
  format %{ "call_leaf,runtime " %}
  ins_encode(clear_avx, Java_To_Runtime(meth));
  ins_pipe(pipe_slow);
%}
// Return
void MachEpilogNode::emit(CodeBuffer& cbuf, PhaseRegAlloc* ra_) const
{
  Compile* C = ra_->C;
  MacroAssembler _masm(&cbuf);
  if (generate_vzeroupper(C)) {
    __ vzeroupper();
  }
...
}

They are all guared by generate_vzeroupper:

static bool generate_vzeroupper(Compile* C) {
  return (VM_Version::supports_vzeroupper() && (C->max_vector_size() > 16 || C->clear_upper_avx() == true)) ? true: false;
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/7770

From duke at openjdk.java.net  Thu Mar 10 09:08:41 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 10 Mar 2022 09:08:41 GMT
Subject: RFR: 8272493: Suboptimal code generation around
 Preconditions.checkIndex intrinsic with AVX2
In-Reply-To: <TO8u8oTSl9Iizqa465WhQilxHDsJH2vqUsbWu9qwbpM=.6f8f31b6-65e4-47ae-a86c-e08ff5936086@github.com>
References: <d6vxMPlAG4HLL0Z-D25Rh4ZAu-Eo2Sm_quO-a8QZ6ao=.e22e7e56-6f94-422e-a5ae-8ffeb6cc954a@github.com>
 <KR-oBJa1aVjlrXj3ozDorT6UHzLh4CZY3UgUucOibQY=.27417b01-5c7a-4b04-bb78-a76a5871d620@github.com>
 <TO8u8oTSl9Iizqa465WhQilxHDsJH2vqUsbWu9qwbpM=.6f8f31b6-65e4-47ae-a86c-e08ff5936086@github.com>
Message-ID: <RtDw44FolAAycKmbrfeFbEHeqHJSwOSOPSm17Oyk324=.bbc0f27d-e5d9-4201-b8b2-3748e48f3feb@github.com>

On Thu, 10 Mar 2022 08:59:35 GMT, Yi Yang <yyang at openjdk.org> wrote:

> do you mean the JVM is missing vzeroupper somewhere?

It seems currently we don't miss anything because handwritten intrinsics don't use 256-bit vectors on AVX1. What I meant by the missing part is that `clear_upper_avx` do not emit `vzeroupper` on AVX1, so if we want to use the full width we may miss some.

> It seems that currently we only emit vzeroupper on some function return or function call when they set clear_upper_avx flag or max_vector_size >16

Yes what I mean here is that even if we touch the YMM registers we still don't need to emit `vzeroupper` everywhere but on transition to codes not emitted by the hotspot assembler.

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7770

From shade at openjdk.java.net  Thu Mar 10 09:24:42 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 10 Mar 2022 09:24:42 GMT
Subject: RFR: 8282878: Removed _JavaThread from PhaseTraceTime
In-Reply-To: <H3YLf2wDCNMHa1J8iwONv-s060TXZAH9MxJWFUHlGSE=.3de03bde-1a0c-4947-a4b0-a3bb0173d8ca@github.com>
References: <H3YLf2wDCNMHa1J8iwONv-s060TXZAH9MxJWFUHlGSE=.3de03bde-1a0c-4947-a4b0-a3bb0173d8ca@github.com>
Message-ID: <Zeg2h2Cc6iGYww1788jcoyuIeEqCrhR9SjrDR7OnJXU=.88337a27-6cbe-4a6e-838e-4c36b838a79a@github.com>

On Wed, 9 Mar 2022 11:49:42 GMT, Alex Blewitt <duke at openjdk.java.net> wrote:

> The `PhaseTraceTime` class has a private `JavaThread _thread` field which doesn't appear to be referenced anywhere, and builds fine without it. It's not clear if this can be removed but it builds cleanly when not present.

The history for this code predates OpenJDK, but I think this field is safe to remove.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7756

From yyang at openjdk.java.net  Thu Mar 10 09:32:39 2022
From: yyang at openjdk.java.net (Yi Yang)
Date: Thu, 10 Mar 2022 09:32:39 GMT
Subject: RFR: 8272493: Suboptimal code generation around
 Preconditions.checkIndex intrinsic with AVX2
In-Reply-To: <d6vxMPlAG4HLL0Z-D25Rh4ZAu-Eo2Sm_quO-a8QZ6ao=.e22e7e56-6f94-422e-a5ae-8ffeb6cc954a@github.com>
References: <d6vxMPlAG4HLL0Z-D25Rh4ZAu-Eo2Sm_quO-a8QZ6ao=.e22e7e56-6f94-422e-a5ae-8ffeb6cc954a@github.com>
Message-ID: <OKyfOj8tsjqihgr9jD4MTUvdP_tGIQungLymbqgZZCI=.b8b78ee6-c9d0-4391-b514-718ffff67627@github.com>

On Thu, 10 Mar 2022 07:55:16 GMT, Yi Yang <yyang at openjdk.org> wrote:

> 8272493 reports a minor regression when using Preconditions.checkIndex in String.checkIndex. The reason is some unnecessary vzeroupper instructions were emitted. The vzerouppers are introduced in [JDK-8190934](https://bugs.openjdk.java.net/browse/JDK-8190934), which are emitted by clear_upper_avx within inline_preconditions_checkIndex. I did some digging into the history of this code. Please correct me if I misunderstand something
> 
> [JDK-8178811](https://bugs.openjdk.java.net/browse/JDK-8178811) emits vzeroupper on every MachEpilogueNode to avoid AVX <-> SSE transition penalty during the call.
> 
> [JDK-8190934](https://bugs.openjdk.java.net/browse/JDK-8190934) emits vzeroupper on some MachEpilogueNode by setting clear_upper_avx flag, because vzeroupper itself is a high-cost instruction, we don't want to emit it everywhere a function is finished.
> 
> [JDK-8272493](https://bugs.openjdk.java.net/browse/JDK-8272493) emits vzeroupper because inline_preconditions_checkIndex sets clear_upper_avx flag.
> 
> Micro benchmark are as follows
> 
> -------Preconditions.checkIndex without clear_upper_avx
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.257 ? 0.011 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.251 ? 0.008 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.254 ? 0.003 ns/op
> 
> -------Preconditions.checkIndex with clear_upper_avx(Current Implementation)
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.421 ? 0.003 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.419 ? 0.002 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.433 ? 0.044 ns/op
> 
> ------- -XX:DisableIntrinsic=_Preconditions_checkIndex
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.229 ? 0.018 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.224 ? 0.006 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.218 ? 0.011 ns/op
> 
> ------- -XX:UseAVX=1
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.247 ? 0.022 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.234 ? 0.018 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.261 ? 0.042 ns/op
> 
> As I understand, inline_Preconditions_checkIndex only do some simple range check, there is no xmm(sse)/ymm(avx) 
>  registers involved, so I propose to remove clear_upper_avx flag to avoid emitting vzeroupper for this intrinsic.

Thanks for the clarifation!

> Yes what I mean here is that even if we touch the YMM registers we still don't need to emit vzeroupper everywhere but on transition to codes not emitted by the hotspot assembler.

Yes, until we see a real AVX <-> SSE transition like cases you mentioned, we don't need to emit it

-------------

PR: https://git.openjdk.java.net/jdk/pull/7770

From redestad at openjdk.java.net  Thu Mar 10 10:18:38 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 10 Mar 2022 10:18:38 GMT
Subject: RFR: 8272493: Suboptimal code generation around
 Preconditions.checkIndex intrinsic with AVX2
In-Reply-To: <d6vxMPlAG4HLL0Z-D25Rh4ZAu-Eo2Sm_quO-a8QZ6ao=.e22e7e56-6f94-422e-a5ae-8ffeb6cc954a@github.com>
References: <d6vxMPlAG4HLL0Z-D25Rh4ZAu-Eo2Sm_quO-a8QZ6ao=.e22e7e56-6f94-422e-a5ae-8ffeb6cc954a@github.com>
Message-ID: <1yJ2BOFdvy689bj3LBUp5MKT1eKfcIm2zKEazQ4afCU=.c3a61f2f-822d-42d3-8842-79cca2da1650@github.com>

On Thu, 10 Mar 2022 07:55:16 GMT, Yi Yang <yyang at openjdk.org> wrote:

> 8272493 reports a minor regression when using Preconditions.checkIndex in String.checkIndex. The reason is some unnecessary vzeroupper instructions were emitted. The vzerouppers are introduced in [JDK-8190934](https://bugs.openjdk.java.net/browse/JDK-8190934), which are emitted by clear_upper_avx within inline_preconditions_checkIndex. I did some digging into the history of this code. Please correct me if I misunderstand something
> 
> [JDK-8178811](https://bugs.openjdk.java.net/browse/JDK-8178811) emits vzeroupper on every MachEpilogueNode to avoid AVX <-> SSE transition penalty during the call.
> 
> [JDK-8190934](https://bugs.openjdk.java.net/browse/JDK-8190934) emits vzeroupper on some MachEpilogueNode by setting clear_upper_avx flag, because vzeroupper itself is a high-cost instruction, we don't want to emit it everywhere a function is finished.
> 
> [JDK-8272493](https://bugs.openjdk.java.net/browse/JDK-8272493) emits vzeroupper because inline_preconditions_checkIndex sets clear_upper_avx flag.
> 
> Micro benchmark are as follows
> 
> -------Preconditions.checkIndex without clear_upper_avx
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.257 ? 0.011 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.251 ? 0.008 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.254 ? 0.003 ns/op
> 
> -------Preconditions.checkIndex with clear_upper_avx(Current Implementation)
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.421 ? 0.003 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.419 ? 0.002 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.433 ? 0.044 ns/op
> 
> ------- -XX:DisableIntrinsic=_Preconditions_checkIndex
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.229 ? 0.018 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.224 ? 0.006 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.218 ? 0.011 ns/op
> 
> ------- -XX:UseAVX=1
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.247 ? 0.022 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.234 ? 0.018 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.261 ? 0.042 ns/op
> 
> As I understand, inline_Preconditions_checkIndex only do some simple range check, there is no xmm(sse)/ymm(avx) 
>  registers involved, so I propose to remove clear_upper_avx flag to avoid emitting vzeroupper for this intrinsic.

IIRC the intent of the patch for [JDK-8190934](https://bugs.openjdk.java.net/browse/JDK-8190934) was to reduce the number of unnecessary vzeroupper instructions generated by the JIT by marking the compilation and emitting it as late as possible and (hopefully) only once per path. There was a short time when we emitted vzerouppers all over the place, and JDK-8190934 fixed most of the adverse effects from that. It's likely still a bit too conservative, but the alternative cost is high and might be elusive.

To me it looks like this patch fixes one place where it's definitely not needed. While the win is small in absolute terms in isolation, there are a lot of places where we want to use `Preconditions.checkIndex` and friends.

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7770

From thartmann at openjdk.java.net  Thu Mar 10 10:49:45 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 10 Mar 2022 10:49:45 GMT
Subject: RFR: 8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0)
 failed: Don't process dead nodes [v4]
In-Reply-To: <u9JBcxv2KOlaZFcnU4K9LjiatClctH31ZnQ2D7Xznq8=.79df4f33-83f2-4fdf-a4d2-4236311c1598@github.com>
References: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
 <u9JBcxv2KOlaZFcnU4K9LjiatClctH31ZnQ2D7Xznq8=.79df4f33-83f2-4fdf-a4d2-4236311c1598@github.com>
Message-ID: <hwS3N_7x0zgzXvTkbVuLQb2McPxgr7IGPl_Ekm49pU4=.80bb9e58-37c4-4dcc-86fe-9a5415d78d42@github.com>

On Tue, 8 Mar 2022 09:02:03 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> Problem:
>> Sometimes nodes are generated, and then not properly added to any other node, nor added to the worklist, so that it could be deleted. In some cases, a node can thus survive after IGVN and enter into `ConnectionGraph::compute_escape`, where no dead nodes are expected (except constants).
>> 
>> In `ArrayCopyNode::prepare_array_copy`:
>> In one, I now add the new ConvI2LNode to the worklist if we are aborting.
>> In the other case, I could safely reorder the code, such new ConvI2LNode would only be generated once we know we are not going to abort.
>> 
>> In `SubTypeCheckNode::Ideal`:
>> Replaced `set_req` with `set_req_X`, such that the input-node that is replaced (which is now potentially a dead node) is put on the worklist.
>> 
>> In `ArrayCopyNode::Ideal`:
>> If we decide to `return NULL` we also need to add the potentially dead forward / backward memory nodes to the worklist, they may turn out to be dead.
>> 
>> Added a regression test: the test + flag combination that first reproduced this issue.
>> 
>> All Tests, including this new regression test are passing.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixing typo

src/hotspot/share/opto/arraycopynode.cpp line 300:

> 298:     if (src_offset->is_top() || dest_offset->is_top()) {
> 299:       // Offset is out of bounds (the ArrayCopyNode will be removed)
> 300:       // Below: make sure that we record the nodes, so that they can be deleted later (if they are dead)

What about this?

src_offset = Compile::conv_I2X_index(phase, src_offset, ary_src->size());
if (src_offset->is_top()) {
  return false;
}
dest_offset = Compile::conv_I2X_index(phase, dest_offset, ary_dest->size());
if (dest_offset->is_top()) {
  if (can_reshape) {
    phase->is_IterGVN()->_worklist.push(src_offset);
  }
  return false;
}

src/hotspot/share/opto/arraycopynode.cpp line 652:

> 650:         phase->is_IterGVN()->_worklist.push(backward_mem);
> 651:       }
> 652:     }

I don't think you need to check if the mem is really dead. Adding it to the worklist does not hurt. Would this work as well?


if (can_reshape) {
  phase->is_IterGVN()->_worklist.push(mem):
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/7728

From thartmann at openjdk.java.net  Thu Mar 10 11:13:45 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 10 Mar 2022 11:13:45 GMT
Subject: RFR: 8282878: Removed _JavaThread from PhaseTraceTime
In-Reply-To: <H3YLf2wDCNMHa1J8iwONv-s060TXZAH9MxJWFUHlGSE=.3de03bde-1a0c-4947-a4b0-a3bb0173d8ca@github.com>
References: <H3YLf2wDCNMHa1J8iwONv-s060TXZAH9MxJWFUHlGSE=.3de03bde-1a0c-4947-a4b0-a3bb0173d8ca@github.com>
Message-ID: <vs3AC5AJGnu88nw3Peiaaj3uyxieURrerOQAhM1X-1c=.9185aec4-faf1-44dc-8c81-ac3313c9c1a2@github.com>

On Wed, 9 Mar 2022 11:49:42 GMT, Alex Blewitt <duke at openjdk.java.net> wrote:

> The `PhaseTraceTime` class has a private `JavaThread _thread` field which doesn't appear to be referenced anywhere, and builds fine without it. It's not clear if this can be removed but it builds cleanly when not present.

Looks good.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7756

From thartmann at openjdk.java.net  Thu Mar 10 11:16:48 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 10 Mar 2022 11:16:48 GMT
Subject: RFR: 8272493: Suboptimal code generation around
 Preconditions.checkIndex intrinsic with AVX2
In-Reply-To: <d6vxMPlAG4HLL0Z-D25Rh4ZAu-Eo2Sm_quO-a8QZ6ao=.e22e7e56-6f94-422e-a5ae-8ffeb6cc954a@github.com>
References: <d6vxMPlAG4HLL0Z-D25Rh4ZAu-Eo2Sm_quO-a8QZ6ao=.e22e7e56-6f94-422e-a5ae-8ffeb6cc954a@github.com>
Message-ID: <WqMxFqyySildU5UlPqDMtaLfRadZCswGCKIrJODVDeU=.5e15b833-9784-49c8-8a71-ef7f0f255046@github.com>

On Thu, 10 Mar 2022 07:55:16 GMT, Yi Yang <yyang at openjdk.org> wrote:

> 8272493 reports a minor regression when using Preconditions.checkIndex in String.checkIndex. The reason is some unnecessary vzeroupper instructions were emitted. The vzerouppers are introduced in [JDK-8190934](https://bugs.openjdk.java.net/browse/JDK-8190934), which are emitted by clear_upper_avx within inline_preconditions_checkIndex. I did some digging into the history of this code. Please correct me if I misunderstand something
> 
> [JDK-8178811](https://bugs.openjdk.java.net/browse/JDK-8178811) emits vzeroupper on every MachEpilogueNode to avoid AVX <-> SSE transition penalty during the call.
> 
> [JDK-8190934](https://bugs.openjdk.java.net/browse/JDK-8190934) emits vzeroupper on some MachEpilogueNode by setting clear_upper_avx flag, because vzeroupper itself is a high-cost instruction, we don't want to emit it everywhere a function is finished.
> 
> [JDK-8272493](https://bugs.openjdk.java.net/browse/JDK-8272493) emits vzeroupper because inline_preconditions_checkIndex sets clear_upper_avx flag.
> 
> Micro benchmark are as follows
> 
> -------Preconditions.checkIndex without clear_upper_avx
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.257 ? 0.011 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.251 ? 0.008 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.254 ? 0.003 ns/op
> 
> -------Preconditions.checkIndex with clear_upper_avx(Current Implementation)
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.421 ? 0.003 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.419 ? 0.002 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.433 ? 0.044 ns/op
> 
> ------- -XX:DisableIntrinsic=_Preconditions_checkIndex
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.229 ? 0.018 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.224 ? 0.006 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.218 ? 0.011 ns/op
> 
> ------- -XX:UseAVX=1
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.247 ? 0.022 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.234 ? 0.018 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.261 ? 0.042 ns/op
> 
> As I understand, inline_Preconditions_checkIndex only do some simple range check, there is no xmm(sse)/ymm(avx) 
>  registers involved, so I propose to remove clear_upper_avx flag to avoid emitting vzeroupper for this intrinsic.

Looks good to me. I'm not sure why `clear_upper_avx()` was set there.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7770

From thartmann at openjdk.java.net  Thu Mar 10 11:20:44 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 10 Mar 2022 11:20:44 GMT
Subject: RFR: 8272735: Add missing SubL node transformations
In-Reply-To: <eFzwVPibLwh_XoXsOlIJQ3qjARbwXJaIVQUOcVGrznA=.7cc15e6e-3c6a-4dba-9e90-6e216874e600@github.com>
References: <eFzwVPibLwh_XoXsOlIJQ3qjARbwXJaIVQUOcVGrznA=.7cc15e6e-3c6a-4dba-9e90-6e216874e600@github.com>
Message-ID: <aKh-jPZ359n1hJfGXLZXz4n-kgInBskNRYhJeopNI14=.b523f127-39f4-445c-9ba9-c383ba0c680b@github.com>

On Wed, 2 Mar 2022 21:28:13 GMT, Ahmed Muhsin <duke at openjdk.java.net> wrote:

> This change adds/enables missing subnode transformations for operations of type `long`.
> A few comments in the test file `SubINodeIdealizationTests.java` were modified to add clarity and to fix a typo.
> Hotspot:tier1 tests were run, this change does not introduce any new failures.

Thanks for clarifying. The change looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7669

From tobias.hartmann at oracle.com  Thu Mar 10 11:24:19 2022
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 10 Mar 2022 12:24:19 +0100
Subject: On JDK-8281518
In-Reply-To: <CAP2b4GPLHFR_kRM_QXCM-bcccuD8PXkpxneOQHkRZNFVJbH16g@mail.gmail.com>
References: <CAP2b4GPLHFR_kRM_QXCM-bcccuD8PXkpxneOQHkRZNFVJbH16g@mail.gmail.com>
Message-ID: <d568cbc2-17c5-5dfb-db3c-8a36120668b2@oracle.com>

Hi Julian,

On 04.03.22 13:21, Julian Waters wrote:
> Out of curiosity, do we have an exhaustive list of related optimizations
> prior to this one already included in C2?

No, I'm afraid we don't have that. As so often, the code is the only documentation.

Best regards,
Tobias

From aph at openjdk.java.net  Thu Mar 10 11:25:41 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 10 Mar 2022 11:25:41 GMT
Subject: RFR: 8282507: Add LICENSE file for hsdis
In-Reply-To: <4pRhIx480labowUn7Kz-ahxqHbSF3DslHDT_HU-ewY4=.fc7bf07d-9ea7-4a02-9df7-b58aaa16f1c0@github.com>
References: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
 <4pRhIx480labowUn7Kz-ahxqHbSF3DslHDT_HU-ewY4=.fc7bf07d-9ea7-4a02-9df7-b58aaa16f1c0@github.com>
Message-ID: <jO-ujDi97ys8-qUmmNOSQcMNW_5eYomi_q4q7lJHdbE=.66ef12c8-41d5-4002-9505-5bb5b883ef7c@github.com>

On Thu, 10 Mar 2022 05:35:39 GMT, Man Cao <manc at openjdk.org> wrote:

> Any updates on whether this is acceptable?

What is the point of this change? It'd require legal inspection, and as far as I can tell there is no point.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7649

From ihse at openjdk.java.net  Thu Mar 10 11:55:40 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 10 Mar 2022 11:55:40 GMT
Subject: RFR: 8282507: Add LICENSE file for hsdis
In-Reply-To: <4pRhIx480labowUn7Kz-ahxqHbSF3DslHDT_HU-ewY4=.fc7bf07d-9ea7-4a02-9df7-b58aaa16f1c0@github.com>
References: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
 <4pRhIx480labowUn7Kz-ahxqHbSF3DslHDT_HU-ewY4=.fc7bf07d-9ea7-4a02-9df7-b58aaa16f1c0@github.com>
Message-ID: <DzHPElQ-Y5jiXju5N37Vhg4eFnEEisYjmUWJsf3K16E=.a63e94e4-17cf-4ca5-8c82-ee0f8b87ae53@github.com>

On Thu, 10 Mar 2022 05:35:39 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone help review the addition of LICENSE file to hsdis directory?
>> 
>> -Man
>
> Any updates on whether this is acceptable?

@caoman No, I have not gotten any replies. I also fully agree with @theRealAph, that this change seem like a huge waste of time chasing legal approval, for what gain? The license for these few special files are already clearly specified in them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7649

From roland at openjdk.java.net  Thu Mar 10 12:30:53 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 10 Mar 2022 12:30:53 GMT
Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v4]
In-Reply-To: <DPPICoKR2tIZ8nbOaBDV2vFi7dp-lCjSnPbOc4ExeJc=.861804f6-b8fa-4d0d-9504-238ea0a89ccc@github.com>
References: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
 <DPPICoKR2tIZ8nbOaBDV2vFi7dp-lCjSnPbOc4ExeJc=.861804f6-b8fa-4d0d-9504-238ea0a89ccc@github.com>
Message-ID: <kCO5D2ohpcWMORQCit2EMYFL9R_U7hhrFrUTAiFvcz8=.a84f707c-76e6-460d-975d-86fa7b3e42e0@github.com>

On Mon, 21 Feb 2022 06:19:26 GMT, Pengfei Li <pli at openjdk.org> wrote:

>> ### Background
>> 
>> Post loop vectorization is a C2 compiler optimization in an experimental
>> VM feature called PostLoopMultiversioning. It transforms the range-check
>> eliminated post loop to a 1-iteration vectorized loop with vector mask.
>> This optimization was contributed by Intel in 2016 to support x86 AVX512
>> masked vector instructions. However, it was disabled soon after an issue
>> was found. Due to insufficient maintenance in these years, multiple bugs
>> have been accumulated inside. But we (Arm) still think this is a useful
>> framework for vector mask support in C2 auto-vectorized loops, for both
>> x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
>> post loop vectorization.
>> 
>> ### Changes in this patch
>> 
>> This patch reworks post loop vectorization. The most significant change
>> is removing vector mask support in C2 x86 backend and re-implementing
>> it in the mid-end. With this, we can re-enable post loop vectorization
>> for platforms other than x86.
>> 
>> Previous implementation hard-codes x86 k1 register as a reserved AVX512
>> opmask register and defines two routines (setvectmask/restorevectmask)
>> to set and restore the value of k1. But after [JDK-8211251](https://bugs.openjdk.java.net/browse/JDK-8211251) which encodes
>> AVX512 instructions as unmasked by default, generated vector masks are
>> no longer used in AVX512 vector instructions. To fix incorrect codegen
>> and add vector mask support for more platforms, we turn to add a vector
>> mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
>> to generate a mask and replace all Load/Store nodes in the post loop
>> into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
>> IR form is exactly the same to those which are used in VectorAPI mask
>> support. For now, we only add mask inputs for Load/Store nodes because
>> we don't have reduction operations supported in post loop vectorization.
>> After this change, the x86 k1 register is no longer reserved and can be
>> allocated when PostLoopMultiversioning is enabled.
>> 
>> Besides this change, we have fixed a compiler crash and five incorrect
>> result issues with post loop vectorization.
>> 
>> **I) C2 crashes with segmentation fault in strip-mined loops**
>> 
>> Previous implementation was done before C2 loop strip-mining was merged
>> into JDK master so it didn't take strip-mined loops into consideration.
>> In C2's strip mined loops, post loop is not the sibling of the main loop
>> in ideal loop tree. Instead, it's the sibling of the main loop's parent.
>> This patch fixed a SIGSEGV issue caused by NULL pointer when locating
>> post loop from strip-mined main loop.
>> 
>> **II) Incorrect result issues with post loop vectorization**
>> 
>> We have also fixed five incorrect vectorization issues. Some of them are
>> hidden deep and can only be reproduced with corner cases. These issues
>> have a common cause that it assumes the post loop can be vectorized if
>> the vectorization in corresponding main loop is successful. But in many
>> cases this assumption is wrong. Below are details.
>> 
>> - **[Issue-1] Incorrect vectorization for partial vectorizable loops**
>> 
>> This issue can be reproduced by below loop where only some operations in
>> the loop body are vectorizable.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     res[i] = a[i] * b[i];
>>     k = 3 * k + 1;
>>   }
>> 
>> In the main loop, superword can work well if parts of the operations in
>> loop body are not vectorizable since those parts can be unrolled only.
>> But for post loops, we don't create vectors through combining scalar IRs
>> generated from loop unrolling. Instead, we are doing scalars to vectors
>> replacement for all operations in the loop body. Hence, all operations
>> should be either vectorized together or not vectorized at all. To fix
>> this kind of cases, we add an extra field "_slp_vector_pack_count" in
>> CountedLoopNode to record the eventual count of vector packs in the main
>> loop. This value is then passed to post loop and compared with post loop
>> pack count. Vectorization will be bailed out in post loop if it creates
>> more vector packs than in the main loop.
>> 
>> - **[Issue-2] Incorrect result in loops with growing-down vectors**
>> 
>> This issue appears with growing-down vectors, that is, vectors that grow
>> to smaller memory address as the loop iterates. It can be reproduced by
>> below counting-up loop with negative scale value in array index.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     a[MAX - i] = b[MAX - i];
>>   }
>> 
>> Cause of this issue is that for a growing-down vector, generated vector
>> mask value has reversed vector-lane order so it masks incorrect vector
>> lanes. Note that if negative scale value appears in counting-down loops,
>> the vector will be growing up. With this rule, we fix the issue by only
>> allowing positive array index scales in counting-up loops and negative
>> array index scales in counting-down loops. This check is done with the
>> help of SWPointer by comparing scale values in each memory access in the
>> loop with loop stride value.
>> 
>> - **[Issue-3] Incorrect result in manually unrolled loops**
>> 
>> This issue can be reproduced by below manually unrolled loop.
>> 
>>   for (int i = 0; i < 10000; i += 2) {
>>     c[i] = a[i] + b[i];
>>     c[i + 1] = a[i + 1] * b[i + 1];
>>   }
>> 
>> In this loop, operations in the 2nd statement duplicate those in the 1st
>> statement with a small memory address offset. Vectorization in the main
>> loop works well in this case because C2 does further unrolling and pack
>> combination. But we cannot vectorize the post loop through replacement
>> from scalars to vectors because it creates duplicated vector operations.
>> To fix this, we restrict post loop vectorization to loops with stride
>> values of 1 or -1.
>> 
>> - **[Issue-4] Incorrect result in loops with mixed vector element sizes**
>> 
>> This issue is found after we enable post loop vectorization for AArch64.
>> It's reproducible by multiple array operations with different element
>> sizes inside a loop. On x86, there is no issue because the values of x86
>> AVX512 opmasks only depend on which vector lanes are active. But AArch64
>> is different - the values of SVE predicates also depend on lane size of
>> the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
>> sizes, we should use different vector masks. For now, we just support
>> loops with only one vector element size, i.e., "int + float" vectors in
>> a single loop is ok but "int + double" vectors in a single loop is not
>> vectorizable. This fix also enables subword vectors support to make all
>> primitive type array operations vectorizable.
>> 
>> - **[Issue-5] Incorrect result in loops with potential data dependence**
>> 
>> This issue can be reproduced by below corner case on AArch64 only.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     a[i] = x;
>>     a[i + OFFSET] = y;
>>   }
>> 
>> In this case, two stores in the loop have data dependence if the OFFSET
>> value is smaller than the vector length. So we cannot do vectorization
>> through replacing scalars to vectors. But the main loop vectorization
>> in this case is successful on AArch64 because AArch64 has partial vector
>> load/store support. It splits vector fill with different values in lanes
>> to several smaller-sized fills. In this patch, we add additional data
>> dependence check for this kind of cases. The check is also done with the
>> help of SWPointer class. In this check, we require that every two memory
>> accesses (with at least one store) of the same element type (or subword
>> size) in the loop has the same array index expression.
>> 
>> ### Tests
>> 
>> So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
>> experimental VM option "PostLoopMultiversioning" turned on. We found no
>> issue in all tests. We notice that those existing cases are not enough
>> because some of above issues are not spotted by them. We would like to
>> add some new cases but we found existing vectorization tests are a bit
>> cumbersome - golden results must be pre-calculated and hard-coded in the
>> test code for correctness verification. Thus, in this patch, we propose
>> a new vectorization testing framework.
>> 
>> Our new framework brings a simpler way to add new cases. For a new test
>> case, we only need to create a new method annotated with "@Test". The
>> test runner will invoke each annotated method twice automatically. First
>> time it runs in the interpreter and second time it's forced compiled by
>> C2. Then the two return results are compared. So in this framework each
>> test method should return a primitive value or an array of primitives.
>> In this way, no extra verification code for vectorization correctness is
>> required. This test runner is still jtreg-based and takes advantages of
>> the jtreg WhiteBox API, which enables test methods running at specific
>> compilation levels. Each test class inside is also jtreg-based. It just
>> need to inherit from the test runner class and run with two additional
>> options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
>> 
>> ### Summary & Future work
>> 
>> In this patch, we reworked post loop vectorization. We made it platform
>> independent and fixed several issues inside. We also implemented a new
>> vectorization testing framework with many test cases inside. Meanwhile,
>> we did some code cleanups.
>> 
>> This patch only touches C2 code guarded with PostLoopMultiversioning,
>> except a few data structure changes. So, there's no behavior change when
>> experimental VM option PostLoopMultiversioning is off. Also, to reduce
>> risks, we still propose to keep post loop vectorization experimental for
>> now. But if it receives positive feedback, we would like to change it to
>> non-experimental in the future.
>
> Pengfei Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into postloop
>    
>    Change-Id: I503edb75f0f626569c776416bfef09651935979c
>  - Update copyright year and rename a function
>    
>    Change-Id: I15845ebd3982edebd4c151284cc6f2ff727630bb
>  - Merge branch 'master' into postloop
>    
>    Change-Id: Ie639c79c9cf016dc68ebf2c0031b60453b45e9a4
>  - Fix issues in newly added test framework
>    
>    Change-Id: I6e61abf05e9665325cb3abaf407360b18355c6b1
>  - Merge branch 'master' into postloop
>    
>    Change-Id: I9bb5a808d7540426dedb141fd198d25eb1f569e6
>  - 8183390: Fix and re-enable post loop vectorization
>    
>    ** Background
>    
>    Post loop vectorization is a C2 compiler optimization in an experimental
>    VM feature called PostLoopMultiversioning. It transforms the range-check
>    eliminated post loop to a 1-iteration vectorized loop with vector mask.
>    This optimization was contributed by Intel in 2016 to support x86 AVX512
>    masked vector instructions. However, it was disabled soon after an issue
>    was found. Due to insufficient maintenance in these years, multiple bugs
>    have been accumulated inside. But we (Arm) still think this is a useful
>    framework for vector mask support in C2 auto-vectorized loops, for both
>    x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
>    post loop vectorization.
>    
>    ** Changes in this patch
>    
>    This patch reworks post loop vectorization. The most significant change
>    is removing vector mask support in C2 x86 backend and re-implementing
>    it in the mid-end. With this, we can re-enable post loop vectorization
>    for platforms other than x86.
>    
>    Previous implementation hard-codes x86 k1 register as a reserved AVX512
>    opmask register and defines two routines (setvectmask/restorevectmask)
>    to set and restore the value of k1. But after JDK-8211251 which encodes
>    AVX512 instructions as unmasked by default, generated vector masks are
>    no longer used in AVX512 vector instructions. To fix incorrect codegen
>    and add vector mask support for more platforms, we turn to add a vector
>    mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
>    to generate a mask and replace all Load/Store nodes in the post loop
>    into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
>    IR form is exactly the same to those which are used in VectorAPI mask
>    support. For now, we only add mask inputs for Load/Store nodes because
>    we don't have reduction operations supported in post loop vectorization.
>    After this change, the x86 k1 register is no longer reserved and can be
>    allocated when PostLoopMultiversioning is enabled.
>    
>    Besides this change, we have fixed a compiler crash and five incorrect
>    result issues with post loop vectorization.
>    
>    - 1) C2 crashes with segmentation fault in strip-mined loops
>    
>    Previous implementation was done before C2 loop strip-mining was merged
>    into JDK master so it didn't take strip-mined loops into consideration.
>    In C2's strip mined loops, post loop is not the sibling of the main loop
>    in ideal loop tree. Instead, it's the sibling of the main loop's parent.
>    This patch fixed a SIGSEGV issue caused by NULL pointer when locating
>    post loop from strip-mined main loop.
>    
>    - 2) Incorrect result issues with post loop vectorization
>    
>    We have also fixed five incorrect vectorization issues. Some of them are
>    hidden deep and can only be reproduced with corner cases. These issues
>    have a common cause that it assumes the post loop can be vectorized if
>    the vectorization in corresponding main loop is successful. But in many
>    cases this assumption is wrong. Below are details.
>    
>    [Issue-1] Incorrect vectorization for partial vectorizable loops
>    
>    This issue can be reproduced by below loop where only some operations in
>    the loop body are vectorizable.
>    
>      for (int i = 0; i < 10000; i++) {
>        res[i] = a[i] * b[i];
>        k = 3 * k + 1;
>      }
>    
>    In the main loop, superword can work well if parts of the operations in
>    loop body are not vectorizable since those parts can be unrolled only.
>    But for post loops, we don't create vectors through combining scalar IRs
>    generated from loop unrolling. Instead, we are doing scalars to vectors
>    replacement for all operations in the loop body. Hence, all operations
>    should be either vectorized together or not vectorized at all. To fix
>    this kind of cases, we add an extra field "_slp_vector_pack_count" in
>    CountedLoopNode to record the eventual count of vector packs in the main
>    loop. This value is then passed to post loop and compared with post loop
>    pack count. Vectorization will be bailed out in post loop if it creates
>    more vector packs than in the main loop.
>    
>    [Issue-2] Incorrect result in loops with growing-down vectors
>    
>    This issue appears with growing-down vectors, that is, vectors that grow
>    to smaller memory address as the loop iterates. It can be reproduced by
>    below counting-up loop with negative scale value in array index.
>    
>      for (int i = 0; i < 10000; i++) {
>        a[MAX - i] = b[MAX - i];
>      }
>    
>    Cause of this issue is that for a growing-down vector, generated vector
>    mask value has reversed vector-lane order so it masks incorrect vector
>    lanes. Note that if negative scale value appears in counting-down loops,
>    the vector will be growing up. With this rule, we fix the issue by only
>    allowing positive array index scales in counting-up loops and negative
>    array index scales in counting-down loops. This check is done with the
>    help of SWPointer by comparing scale values in each memory access in the
>    loop with loop stride value.
>    
>    [Issue-3] Incorrect result in manually unrolled loops
>    
>    This issue can be reproduced by below manually unrolled loop.
>    
>      for (int i = 0; i < 10000; i += 2) {
>        c[i] = a[i] + b[i];
>        c[i + 1] = a[i + 1] * b[i + 1];
>      }
>    
>    In this loop, operations in the 2nd statement duplicate those in the 1st
>    statement with a small memory address offset. Vectorization in the main
>    loop works well in this case because C2 does further unrolling and pack
>    combination. But we cannot vectorize the post loop through replacement
>    from scalars to vectors because it creates duplicated vector operations.
>    To fix this, we restrict post loop vectorization to loops with stride
>    values of 1 or -1.
>    
>    [Issue-4] Incorrect result in loops with mixed vector element sizes
>    
>    This issue is found after we enable post loop vectorization for AArch64.
>    It's reproducible by multiple array operations with different element
>    sizes inside a loop. On x86, there is no issue because the values of x86
>    AVX512 opmasks only depend on which vector lanes are active. But AArch64
>    is different - the values of SVE predicates also depend on lane size of
>    the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
>    sizes, we should use different vector masks. For now, we just support
>    loops with only one vector element size, i.e., "int + float" vectors in
>    a single loop is ok but "int + double" vectors in a single loop is not
>    vectorizable. This fix also enables subword vectors support to make all
>    primitive type array operations vectorizable.
>    
>    [Issue-5] Incorrect result in loops with potential data dependence
>    
>    This issue can be reproduced by below corner case on AArch64 only.
>    
>      for (int i = 0; i < 10000; i++) {
>        a[i] = x;
>        a[i + OFFSET] = y;
>      }
>    
>    In this case, two stores in the loop have data dependence if the OFFSET
>    value is smaller than the vector length. So we cannot do vectorization
>    through replacing scalars to vectors. But the main loop vectorization
>    in this case is successful on AArch64 because AArch64 has partial vector
>    load/store support. It splits vector fill with different values in lanes
>    to several smaller-sized fills. In this patch, we add additional data
>    dependence check for this kind of cases. The check is also done with the
>    help of SWPointer class. In this check, we require that every two memory
>    accesses (with at least one store) of the same element type (or subword
>    size) in the loop has the same array index expression.
>    
>    ** Tests
>    
>    So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
>    experimental VM option "PostLoopMultiversioning" turned on. We found no
>    issue in all tests. We notice that those existing cases are not enough
>    because some of above issues are not spotted by them. We would like to
>    add some new cases but we found existing vectorization tests are a bit
>    cumbersome - golden results must be pre-calculated and hard-coded in the
>    test code for correctness verification. Thus, in this patch, we propose
>    a new vectorization testing framework.
>    
>    Our new framework brings a simpler way to add new cases. For a new test
>    case, we only need to create a new method annotated with "@Test". The
>    test runner will invoke each annotated method twice automatically. First
>    time it runs in the interpreter and second time it's forced compiled by
>    C2. Then the two return results are compared. So in this framework each
>    test method should return a primitive value or an array of primitives.
>    In this way, no extra verification code for vectorization correctness is
>    required. This test runner is still jtreg-based and takes advantages of
>    the jtreg WhiteBox API, which enables test methods running at specific
>    compilation levels. Each test class inside is also jtreg-based. It just
>    need to inherit from the test runner class and run with two additional
>    options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
>    
>    ** Summary & Future work
>    
>    In this patch, we reworked post loop vectorization. We made it platform
>    independent and fixed several issues inside. We also implemented a new
>    vectorization testing framework with many test cases inside. Meanwhile,
>    we did some code cleanups.
>    
>    This patch only touches C2 code guarded with PostLoopMultiversioning,
>    except a few data structure changes. So, there's no behavior change when
>    experimental VM option PostLoopMultiversioning is off. Also, to reduce
>    risks, we still propose to keep post loop vectorization experimental for
>    now. But if it receives positive feedback, we would like to change it to
>    non-experimental in the future.

Aren't those 2 issues:

>     * **[Issue-3] Incorrect result in manually unrolled loops**
> 
> 
> This issue can be reproduced by below manually unrolled loop.
> 
> ```
>   for (int i = 0; i < 10000; i += 2) {
>     c[i] = a[i] + b[i];
>     c[i + 1] = a[i + 1] * b[i + 1];
>   }
> ```

>     * **[Issue-5] Incorrect result in loops with potential data dependence**
> 
> 
> This issue can be reproduced by below corner case on AArch64 only.
> 
> ```
>   for (int i = 0; i < 10000; i++) {
>     a[i] = x;
>     a[i + OFFSET] = y;
>   }
> ```

fairly similar. Doesn't/couldn't the logic from issue 5 protect from issue 3?

I see no reason not to proceed with this change as it attempts to fix something that's broken and nobody uses, doesn't enable it by default and doesn't affect code other than post loop vectorization.

I haven't looked at tests closely but I don't think there are IR tests. Maybe you want to consider adding some as a follow up to this PR.

Another review (ideally by someone familiar with the superword code) is required.

src/hotspot/share/opto/loopnode.cpp line 4443:

> 4441:         CountedLoopNode *cl = lpt->_head->as_CountedLoop();
> 4442: 
> 4443:         if (cl->is_rce_post_loop() && !cl->is_vectorized_loop()) {

Maybe assert that PostLoopMultiversioning is true?

src/hotspot/share/opto/superword.cpp line 114:

> 112:   if (post_loop_allowed) {
> 113:     if (cl->is_reduction_loop()) return; // no predication mapping
> 114:     Node *limit = cl->limit();

Why was this required but no longer is?

src/hotspot/share/opto/superword.hpp line 616:

> 614: //------------------------------SWPointer---------------------------
> 615: // Information about an address for dependence checking and vector alignment
> 616: class SWPointer : public ResourceObj {

Why is this required?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6828

From thartmann at openjdk.java.net  Thu Mar 10 13:28:47 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 10 Mar 2022 13:28:47 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v10]
In-Reply-To: <cdQ7cLMPxxW0p-nK1DdHcQTrfouGC2kvXjSiDxHiMTw=.753e3892-e538-4890-a9f0-dd493d5fbf78@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <cdQ7cLMPxxW0p-nK1DdHcQTrfouGC2kvXjSiDxHiMTw=.753e3892-e538-4890-a9f0-dd493d5fbf78@github.com>
Message-ID: <St_Eey566HKUKt0_RKDIve5z3WKnAOwDbiBopp8_nSU=.8eb66e07-e117-4b11-8bd5-8c6d86ee5484@github.com>

On Fri, 4 Mar 2022 08:29:40 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unreached rules

It would be good if someone from Intel (@sviswa7, @jatin-bhateja) could look at this as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From aph at openjdk.java.net  Thu Mar 10 14:05:49 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 10 Mar 2022 14:05:49 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v12]
In-Reply-To: <z2cFnDhoRCyWcg8_EVPXNrIWho49Q9guONfeRXdJ1qA=.b6b0baea-f802-4d28-a453-ab14705c339c@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <z2cFnDhoRCyWcg8_EVPXNrIWho49Q9guONfeRXdJ1qA=.b6b0baea-f802-4d28-a453-ab14705c339c@github.com>
Message-ID: <dSZF4-wzTqp-h-iSoXJIEOH6bTMjXJKLU1k9zVq-qZQ=.3476ffb6-b9f9-401d-8951-20e131459a8e@github.com>

On Wed, 9 Mar 2022 11:38:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
>> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - 8279508: Preventing domain switch-over penalty for Math.round(float) and constraining unrolling to prevent code bloating.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
>  - 8279508: Removing +LogCompilation flag.
>  - 8279508: Review comments resolved.`
>  - 8279508: Adding descriptive comments.
>  - 8279508: Review comments resolved.
>  - 8279508: Review comments resolved.
>  - 8279508: Fixing for windows failure.
>  - 8279508: Adding few descriptive comments.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d07f7c76...547f4e31

test/micro/org/openjdk/bench/java/math/FpRoundingBenchmark.java line 114:

> 112:       for (int i = 0; i < TESTSIZE; i++) {
> 113:           ResF[i] = Math.round(FargV1[i]);
> 114:       }

I think that this is wrong: you should not be storing the result into a float array because it requires an extra integer->float conversion, which distorts the timings. You need `resI` and `resL` for the results of `Math.round`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From aph at openjdk.java.net  Thu Mar 10 14:10:52 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 10 Mar 2022 14:10:52 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v12]
In-Reply-To: <z2cFnDhoRCyWcg8_EVPXNrIWho49Q9guONfeRXdJ1qA=.b6b0baea-f802-4d28-a453-ab14705c339c@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <z2cFnDhoRCyWcg8_EVPXNrIWho49Q9guONfeRXdJ1qA=.b6b0baea-f802-4d28-a453-ab14705c339c@github.com>
Message-ID: <CIjEhVfdOeP0mE2fP9OHQrqYqOLup4H5kFTEPnJB8ak=.cd6d5a87-4d37-4bcf-b0b2-94cbe9b289c2@github.com>

On Wed, 9 Mar 2022 11:38:34 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
>> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - 8279508: Preventing domain switch-over penalty for Math.round(float) and constraining unrolling to prevent code bloating.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
>  - 8279508: Removing +LogCompilation flag.
>  - 8279508: Review comments resolved.`
>  - 8279508: Adding descriptive comments.
>  - 8279508: Review comments resolved.
>  - 8279508: Review comments resolved.
>  - 8279508: Fixing for windows failure.
>  - 8279508: Adding few descriptive comments.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d07f7c76...547f4e31

test/micro/org/openjdk/bench/java/math/FpRoundingBenchmark.java line 70:

> 68:       }
> 69: 
> 70:       FargV1 = new float[TESTSIZE];

`FargV1` is not initialized.
You need to set `i = 0;` here.

test/micro/org/openjdk/bench/java/math/FpRoundingBenchmark.java line 78:

> 76: 
> 77:       for (; i < TESTSIZE; i++) {
> 78:           FargV1[i] = r.nextFloat()*TESTSIZE;

This is an unrealistically narrow range of values. I'd use 
Suggestion:

          FargV1[i] = Float.intBitsToFloat(r.nextInt());

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From darcy at openjdk.java.net  Thu Mar 10 14:32:46 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Mar 2022 14:32:46 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v9]
In-Reply-To: <2jFjnftd7VluGsxgp8BK0vgHA68VrgGREj0fk7F6Dhk=.e40ddcaa-5a31-4115-976d-5f43e94b8ccf@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>
 <C8UrQ5i-1DBVeT7O3uFmyLkGTCmHLcRVkyupDPocqeg=.d7ecc45f-e9f2-4ab9-9d4f-8c084f0d1a6a@github.com>
 <HnLSn9vdNL5YBqaQXPS9QNzFF6CM37GzX1cF-HUVq7Y=.6e99b156-1b77-44e4-9b73-e7e389ab6ff8@github.com>
 <2jFjnftd7VluGsxgp8BK0vgHA68VrgGREj0fk7F6Dhk=.e40ddcaa-5a31-4115-976d-5f43e94b8ccf@github.com>
Message-ID: <7lwsCvdSjkvDYJNwuA7fVPrWFUbzchuwx0Z3IID5VZw=.0c00c3d7-2106-40df-88bc-38bf7e2655f9@github.com>

On Fri, 4 Mar 2022 19:04:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> IMO RoundTests should have a explicit @run tag without any VM options as well.
>> 
>> Do the added VM options run on all platforms in question? What is the approximate time to run the test run compared to before?
>
> Hi @jddarcy , 
> 
> Test has been modified on the same lines using generic options which manipulate compilation thresholds and agnostic to target platforms.
> 
>  * @run main/othervm -XX:Tier3CompileThreshold=100 -XX:CompileThresholdScaling=0.01 -XX:+TieredCompilation RoundTests
> 
> Verified that  RoundTests::test* methods gets compiled by c2.
> Test execution time with and without change is almost same ~7.80sec over Skylake-server.
> 
> Regards

To be more explicit, the existing RoundTests.java test runs in a fraction of a second.  The updated test runs many times slower, even if now under 10 second, at least on some platforms.

Can something closer to the original performance be restored?

As a tier 1 library test, these tests are run quite frequently.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From duke at openjdk.java.net  Thu Mar 10 14:46:41 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Thu, 10 Mar 2022 14:46:41 GMT
Subject: RFR: 8282509: [exploded image] ResolvedClassTest fails with
 similar output [v3]
In-Reply-To: <fr5IVsWDcO4aRHv_V7p_D3LZR3IFMvK3GfwrO0iVN3o=.4ef5feb9-0849-4b44-9e8e-314ecaee9449@github.com>
References: <5eb3C_3MU09ZBJSPs9ER4fM8u89e7T814CDtRDIdqAY=.04acec75-b1ca-44be-8bb2-140a51ca0a2b@github.com>
 <fr5IVsWDcO4aRHv_V7p_D3LZR3IFMvK3GfwrO0iVN3o=.4ef5feb9-0849-4b44-9e8e-314ecaee9449@github.com>
Message-ID: <rNSGzmwyyuEjq2AdwyJtPQpMqRPOXoaT20YA2sd0uBo=.b46cc20e-ac06-434a-bd5e-bffb7e841cdb@github.com>

On Mon, 7 Mar 2022 16:25:25 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> This is a tentative solution to a failure observed on AIX. The solution is tentative because I require help to ensure that something deeper and more problematic is not happening.
>> 
>> The test fails because the output produced by PrintCompilation produces `LambdaForm$MH/0x00000007c0002400` instead of `Invokers$Holder` as it does on other platforms. There is one other place the output is different, when `DirectMethodHandle$Holder` is replaced with `LambdaForm$DMH/0x00000007c0001c00`. Ignoring these name changes, the output of PrintCompilation is identical. I observe the same compilations (including the OSR/non-OSR, and same level) in the same order.
>> 
>> I would be grateful for help understanding the root of the difference behind the change. I have a few ideas, but I will let you build your own interpretations free from my potentially incorrect understanding (i.e. no spoilers). Thanks in advance.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Remove leading chars not present in original test
>  - Trial Solution: Replaces shouldContain with shouldMatch + Regex in ResolvedClassTest

Thanks for the reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7701

From duke at openjdk.java.net  Thu Mar 10 15:12:47 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Thu, 10 Mar 2022 15:12:47 GMT
Subject: Integrated: 8282509: [exploded image] ResolvedClassTest fails with
 similar output
In-Reply-To: <5eb3C_3MU09ZBJSPs9ER4fM8u89e7T814CDtRDIdqAY=.04acec75-b1ca-44be-8bb2-140a51ca0a2b@github.com>
References: <5eb3C_3MU09ZBJSPs9ER4fM8u89e7T814CDtRDIdqAY=.04acec75-b1ca-44be-8bb2-140a51ca0a2b@github.com>
Message-ID: <_jhoZYSfhWetRBDFmafAWstCHKt1XAvJhWR_pvkYCBo=.3eef9085-a9c0-4441-bda1-f3f39fe66933@github.com>

On Fri, 4 Mar 2022 16:22:47 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> This is a tentative solution to a failure observed on AIX. The solution is tentative because I require help to ensure that something deeper and more problematic is not happening.
> 
> The test fails because the output produced by PrintCompilation produces `LambdaForm$MH/0x00000007c0002400` instead of `Invokers$Holder` as it does on other platforms. There is one other place the output is different, when `DirectMethodHandle$Holder` is replaced with `LambdaForm$DMH/0x00000007c0001c00`. Ignoring these name changes, the output of PrintCompilation is identical. I observe the same compilations (including the OSR/non-OSR, and same level) in the same order.
> 
> I would be grateful for help understanding the root of the difference behind the change. I have a few ideas, but I will let you build your own interpretations free from my potentially incorrect understanding (i.e. no spoilers). Thanks in advance.

This pull request has now been integrated.

Changeset: 7c8ea9f0
Author:    Tyler Steele <tyler.steele at ibm.com>
Committer: Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7c8ea9f05b35069e2b5b43e1a0e46f7dbe374e4c
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8282509: [exploded image] ResolvedClassTest fails with similar output

Reviewed-by: mdoerr, dlong

-------------

PR: https://git.openjdk.java.net/jdk/pull/7701

From shade at openjdk.java.net  Thu Mar 10 15:30:47 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 10 Mar 2022 15:30:47 GMT
Subject: RFR: 8282878: Removed _JavaThread from PhaseTraceTime
In-Reply-To: <H3YLf2wDCNMHa1J8iwONv-s060TXZAH9MxJWFUHlGSE=.3de03bde-1a0c-4947-a4b0-a3bb0173d8ca@github.com>
References: <H3YLf2wDCNMHa1J8iwONv-s060TXZAH9MxJWFUHlGSE=.3de03bde-1a0c-4947-a4b0-a3bb0173d8ca@github.com>
Message-ID: <YGwjui2UFuDfYoXomjMhn5Xkf8cduF94OFQwXy_lT5E=.488637a7-686b-4966-901b-3a119e44bb90@github.com>

On Wed, 9 Mar 2022 11:49:42 GMT, Alex Blewitt <duke at openjdk.java.net> wrote:

> The `PhaseTraceTime` class has a private `JavaThread _thread` field which doesn't appear to be referenced anywhere, and builds fine without it. It's not clear if this can be removed but it builds cleanly when not present.

I believe this is trivial too.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7756

From duke at openjdk.java.net  Thu Mar 10 15:30:47 2022
From: duke at openjdk.java.net (Alex Blewitt)
Date: Thu, 10 Mar 2022 15:30:47 GMT
Subject: Integrated: 8282878: Removed _JavaThread from PhaseTraceTime
In-Reply-To: <H3YLf2wDCNMHa1J8iwONv-s060TXZAH9MxJWFUHlGSE=.3de03bde-1a0c-4947-a4b0-a3bb0173d8ca@github.com>
References: <H3YLf2wDCNMHa1J8iwONv-s060TXZAH9MxJWFUHlGSE=.3de03bde-1a0c-4947-a4b0-a3bb0173d8ca@github.com>
Message-ID: <2jK0I8kKsRqMXI8UIe9Z_KD2fMA108yRj6jWbMqLWBU=.4901eeae-ab10-4c0d-a144-5b1fdeded580@github.com>

On Wed, 9 Mar 2022 11:49:42 GMT, Alex Blewitt <duke at openjdk.java.net> wrote:

> The `PhaseTraceTime` class has a private `JavaThread _thread` field which doesn't appear to be referenced anywhere, and builds fine without it. It's not clear if this can be removed but it builds cleanly when not present.

This pull request has now been integrated.

Changeset: 26747990
Author:    Alex Blewitt <alex.blewitt at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/26747990053ab8f378d7f64cd7e565e530af88fc
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8282878: Removed _JavaThread from PhaseTraceTime

Reviewed-by: shade, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7756

From jbhateja at openjdk.java.net  Thu Mar 10 18:21:31 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 10 Mar 2022 18:21:31 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v13]
In-Reply-To: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
Message-ID: <4_HYBZmpNv3PRkPgYlo51m_YAyKeLB6m1hlg_jX9fMY=.69c82d73-0cd4-419c-96d0-99be51e58e15@github.com>

> Summary of changes:
> - Intrinsify Math.round(float) and Math.round(double) APIs.
> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
> - Test creation using new IR testing framework.
> 
> Following are the performance number of a JMH micro included with the patch 
> 
> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
> 
> 
> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
> -- | -- | -- | -- | -- | -- | -- | --
> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8279508: Review comments resolution.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7094/files
  - new: https://git.openjdk.java.net/jdk/pull/7094/files/547f4e31..fcb73212

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=11-12

  Stats: 13 lines in 3 files changed: 6 ins; 3 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094

PR: https://git.openjdk.java.net/jdk/pull/7094

From manc at openjdk.java.net  Thu Mar 10 22:04:43 2022
From: manc at openjdk.java.net (Man Cao)
Date: Thu, 10 Mar 2022 22:04:43 GMT
Subject: RFR: 8282507: Add LICENSE file for hsdis
In-Reply-To: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
References: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
Message-ID: <pcLBCXCPBvUFQKUq6vFBS0LkAifu1Oo-tbfQfgi4ho4=.b269d4cd-a7bc-4ba0-a6cc-26130bf1d828@github.com>

On Tue, 1 Mar 2022 20:18:11 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone help review the addition of LICENSE file to hsdis directory?
> 
> -Man

The context is that Google have an automated check for license compliance for all imported open-source software. We (Java platform team) have to maintain a script that finds and copies all licenses within OpenJDK codebase, in order to pass the license compliance check. All other licenses within the OpenJDK codebase are already in their own files that contain only the license information. We have two options:
- Add special-handling code to the script we maintain, so it can extract the license information from hsdis's README.md file and copy it.
- Provide a separate file for hsdis that contains only the license in OpenJDK.

The second approach is more appealing to us, as it reduces our script's complexity and maintenance burden, and makes hsdis's license structure consistent with other licenses in OpenJDK.

If getting the legal approval requires too much overhead, we could use the first approach to implement the logic in our script instead.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7649

From ihse at openjdk.java.net  Thu Mar 10 22:51:42 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 10 Mar 2022 22:51:42 GMT
Subject: RFR: 8282507: Add LICENSE file for hsdis
In-Reply-To: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
References: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
Message-ID: <pwiNGK4j05xgU_0QCAHMzal7Aevb3v2rugLpCET7lWM=.262ac750-a0ee-4adf-bdc8-152c21b6dc6c@github.com>

On Tue, 1 Mar 2022 20:18:11 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone help review the addition of LICENSE file to hsdis directory?
> 
> -Man

When you say your change "makes hsdis's license structure consistent with other licenses in OpenJDK", what do you mean by that? 

If we had random LICENSE files lying around I'd agree that we should do the same here, but that is clearly not the case. There's a top-level LICENSE file. And there are markdown files in share/legal for licenses of included 3rd party code. Can you clarify how this change would improve consistency?

>From my PoV, this is just another case of how parts of the code use GPL, and parts use GPL+classpath exception. There are no "LICENSE" file specific to Hotspot saying it has a different license in general to e.g. java.base.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7649

From manc at openjdk.java.net  Thu Mar 10 23:36:38 2022
From: manc at openjdk.java.net (Man Cao)
Date: Thu, 10 Mar 2022 23:36:38 GMT
Subject: RFR: 8282507: Add LICENSE file for hsdis
In-Reply-To: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
References: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
Message-ID: <xPj3byl2eFD76dhaWMmQq6Sk0RHrRxkAfoxnBPfiDF0=.1f3c74ed-7cd9-40dc-ae28-23c3d6c84d50@github.com>

On Tue, 1 Mar 2022 20:18:11 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone help review the addition of LICENSE file to hsdis directory?
> 
> -Man

The consistency is to have the license information in its own file, like other 3rd party code in OpenJDK. There two ways:
- Add a LICENSE file or a similar text file. There is src/java.desktop/share/native/libsplashscreen/libpng/LICENSE and make/data/cldr/unicode-license.txt.
- Add markdown files in share/legal subdirectory. Many examples exist such as src/java.xml/share/legal/. This approach seems mainly used for source code in Java.

Do you think it is better to follow the "share/legal" approach such as adding a file src/utils/hsdis/share/legal/hsdis.md ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7649

From ihse at openjdk.java.net  Fri Mar 11 00:19:44 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 11 Mar 2022 00:19:44 GMT
Subject: RFR: 8282507: Add LICENSE file for hsdis
In-Reply-To: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
References: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
Message-ID: <UTasX50cHnsUgFFnUglP35E2O8k1R_1Hs4lSJnD219I=.5f1579a1-b63e-4721-8f6e-a257dadacfc2@github.com>

On Tue, 1 Mar 2022 20:18:11 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone help review the addition of LICENSE file to hsdis directory?
> 
> -Man

But those are licenses for 3rd party code which we have incorporated.

hsdis is written by us. We have just chosen a different license to distribute it under. That makes comparisons with libpng and cldr irrelevant.

src/java.desktop/share/native/libsplashscreen/libpng/LICENSE seems like a mistake. There should be a libpng.md file in java.desktop/share/legal instead.

I think the comparison you need to do is how e.g. src/java.base and src/hotspot are licensed differently.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7649

From yyang at openjdk.java.net  Fri Mar 11 02:31:46 2022
From: yyang at openjdk.java.net (Yi Yang)
Date: Fri, 11 Mar 2022 02:31:46 GMT
Subject: Integrated: 8272493: Suboptimal code generation around
 Preconditions.checkIndex intrinsic with AVX2
In-Reply-To: <d6vxMPlAG4HLL0Z-D25Rh4ZAu-Eo2Sm_quO-a8QZ6ao=.e22e7e56-6f94-422e-a5ae-8ffeb6cc954a@github.com>
References: <d6vxMPlAG4HLL0Z-D25Rh4ZAu-Eo2Sm_quO-a8QZ6ao=.e22e7e56-6f94-422e-a5ae-8ffeb6cc954a@github.com>
Message-ID: <fBXl7E0rAWZVqttGy0-XfwCSIHYd7aHNC0ghtBcOe4Q=.f8cffef7-8d5d-477d-a2b3-e55190b63115@github.com>

On Thu, 10 Mar 2022 07:55:16 GMT, Yi Yang <yyang at openjdk.org> wrote:

> 8272493 reports a minor regression when using Preconditions.checkIndex in String.checkIndex. The reason is some unnecessary vzeroupper instructions were emitted. The vzerouppers are introduced in [JDK-8190934](https://bugs.openjdk.java.net/browse/JDK-8190934), which are emitted by clear_upper_avx within inline_preconditions_checkIndex. I did some digging into the history of this code. Please correct me if I misunderstand something
> 
> [JDK-8178811](https://bugs.openjdk.java.net/browse/JDK-8178811) emits vzeroupper on every MachEpilogueNode to avoid AVX <-> SSE transition penalty during the call.
> 
> [JDK-8190934](https://bugs.openjdk.java.net/browse/JDK-8190934) emits vzeroupper on some MachEpilogueNode by setting clear_upper_avx flag, because vzeroupper itself is a high-cost instruction, we don't want to emit it everywhere a function is finished.
> 
> [JDK-8272493](https://bugs.openjdk.java.net/browse/JDK-8272493) emits vzeroupper because inline_preconditions_checkIndex sets clear_upper_avx flag.
> 
> Micro benchmark are as follows
> 
> -------Preconditions.checkIndex without clear_upper_avx
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.257 ? 0.011 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.251 ? 0.008 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.254 ? 0.003 ns/op
> 
> -------Preconditions.checkIndex with clear_upper_avx(Current Implementation)
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.421 ? 0.003 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.419 ? 0.002 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.433 ? 0.044 ns/op
> 
> ------- -XX:DisableIntrinsic=_Preconditions_checkIndex
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.229 ? 0.018 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.224 ? 0.006 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.218 ? 0.011 ns/op
> 
> ------- -XX:UseAVX=1
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.247 ? 0.022 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.234 ? 0.018 ns/op
> 
> Benchmark Mode Cnt Score Error Units
> StringBuilders.charAtLatin1 avgt 15 6.261 ? 0.042 ns/op
> 
> As I understand, inline_Preconditions_checkIndex only do some simple range check, there is no xmm(sse)/ymm(avx) 
>  registers involved, so I propose to remove clear_upper_avx flag to avoid emitting vzeroupper for this intrinsic.

This pull request has now been integrated.

Changeset: 88f0938c
Author:    Yi Yang <yyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/88f0938c943bfacf748ddb0588a301c2cf7e941e
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8272493: Suboptimal code generation around Preconditions.checkIndex intrinsic with AVX2

Reviewed-by: redestad, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7770

From pli at openjdk.java.net  Fri Mar 11 02:34:50 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Fri, 11 Mar 2022 02:34:50 GMT
Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v4]
In-Reply-To: <DPPICoKR2tIZ8nbOaBDV2vFi7dp-lCjSnPbOc4ExeJc=.861804f6-b8fa-4d0d-9504-238ea0a89ccc@github.com>
References: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
 <DPPICoKR2tIZ8nbOaBDV2vFi7dp-lCjSnPbOc4ExeJc=.861804f6-b8fa-4d0d-9504-238ea0a89ccc@github.com>
Message-ID: <iTklGXAiiq93HancC9EZFPvrqf0hdc8dC5y686NlSCc=.1f4cef48-05a0-4951-8ea3-597bedc9c991@github.com>

On Mon, 21 Feb 2022 06:19:26 GMT, Pengfei Li <pli at openjdk.org> wrote:

>> ### Background
>> 
>> Post loop vectorization is a C2 compiler optimization in an experimental
>> VM feature called PostLoopMultiversioning. It transforms the range-check
>> eliminated post loop to a 1-iteration vectorized loop with vector mask.
>> This optimization was contributed by Intel in 2016 to support x86 AVX512
>> masked vector instructions. However, it was disabled soon after an issue
>> was found. Due to insufficient maintenance in these years, multiple bugs
>> have been accumulated inside. But we (Arm) still think this is a useful
>> framework for vector mask support in C2 auto-vectorized loops, for both
>> x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
>> post loop vectorization.
>> 
>> ### Changes in this patch
>> 
>> This patch reworks post loop vectorization. The most significant change
>> is removing vector mask support in C2 x86 backend and re-implementing
>> it in the mid-end. With this, we can re-enable post loop vectorization
>> for platforms other than x86.
>> 
>> Previous implementation hard-codes x86 k1 register as a reserved AVX512
>> opmask register and defines two routines (setvectmask/restorevectmask)
>> to set and restore the value of k1. But after [JDK-8211251](https://bugs.openjdk.java.net/browse/JDK-8211251) which encodes
>> AVX512 instructions as unmasked by default, generated vector masks are
>> no longer used in AVX512 vector instructions. To fix incorrect codegen
>> and add vector mask support for more platforms, we turn to add a vector
>> mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
>> to generate a mask and replace all Load/Store nodes in the post loop
>> into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
>> IR form is exactly the same to those which are used in VectorAPI mask
>> support. For now, we only add mask inputs for Load/Store nodes because
>> we don't have reduction operations supported in post loop vectorization.
>> After this change, the x86 k1 register is no longer reserved and can be
>> allocated when PostLoopMultiversioning is enabled.
>> 
>> Besides this change, we have fixed a compiler crash and five incorrect
>> result issues with post loop vectorization.
>> 
>> **I) C2 crashes with segmentation fault in strip-mined loops**
>> 
>> Previous implementation was done before C2 loop strip-mining was merged
>> into JDK master so it didn't take strip-mined loops into consideration.
>> In C2's strip mined loops, post loop is not the sibling of the main loop
>> in ideal loop tree. Instead, it's the sibling of the main loop's parent.
>> This patch fixed a SIGSEGV issue caused by NULL pointer when locating
>> post loop from strip-mined main loop.
>> 
>> **II) Incorrect result issues with post loop vectorization**
>> 
>> We have also fixed five incorrect vectorization issues. Some of them are
>> hidden deep and can only be reproduced with corner cases. These issues
>> have a common cause that it assumes the post loop can be vectorized if
>> the vectorization in corresponding main loop is successful. But in many
>> cases this assumption is wrong. Below are details.
>> 
>> - **[Issue-1] Incorrect vectorization for partial vectorizable loops**
>> 
>> This issue can be reproduced by below loop where only some operations in
>> the loop body are vectorizable.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     res[i] = a[i] * b[i];
>>     k = 3 * k + 1;
>>   }
>> 
>> In the main loop, superword can work well if parts of the operations in
>> loop body are not vectorizable since those parts can be unrolled only.
>> But for post loops, we don't create vectors through combining scalar IRs
>> generated from loop unrolling. Instead, we are doing scalars to vectors
>> replacement for all operations in the loop body. Hence, all operations
>> should be either vectorized together or not vectorized at all. To fix
>> this kind of cases, we add an extra field "_slp_vector_pack_count" in
>> CountedLoopNode to record the eventual count of vector packs in the main
>> loop. This value is then passed to post loop and compared with post loop
>> pack count. Vectorization will be bailed out in post loop if it creates
>> more vector packs than in the main loop.
>> 
>> - **[Issue-2] Incorrect result in loops with growing-down vectors**
>> 
>> This issue appears with growing-down vectors, that is, vectors that grow
>> to smaller memory address as the loop iterates. It can be reproduced by
>> below counting-up loop with negative scale value in array index.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     a[MAX - i] = b[MAX - i];
>>   }
>> 
>> Cause of this issue is that for a growing-down vector, generated vector
>> mask value has reversed vector-lane order so it masks incorrect vector
>> lanes. Note that if negative scale value appears in counting-down loops,
>> the vector will be growing up. With this rule, we fix the issue by only
>> allowing positive array index scales in counting-up loops and negative
>> array index scales in counting-down loops. This check is done with the
>> help of SWPointer by comparing scale values in each memory access in the
>> loop with loop stride value.
>> 
>> - **[Issue-3] Incorrect result in manually unrolled loops**
>> 
>> This issue can be reproduced by below manually unrolled loop.
>> 
>>   for (int i = 0; i < 10000; i += 2) {
>>     c[i] = a[i] + b[i];
>>     c[i + 1] = a[i + 1] * b[i + 1];
>>   }
>> 
>> In this loop, operations in the 2nd statement duplicate those in the 1st
>> statement with a small memory address offset. Vectorization in the main
>> loop works well in this case because C2 does further unrolling and pack
>> combination. But we cannot vectorize the post loop through replacement
>> from scalars to vectors because it creates duplicated vector operations.
>> To fix this, we restrict post loop vectorization to loops with stride
>> values of 1 or -1.
>> 
>> - **[Issue-4] Incorrect result in loops with mixed vector element sizes**
>> 
>> This issue is found after we enable post loop vectorization for AArch64.
>> It's reproducible by multiple array operations with different element
>> sizes inside a loop. On x86, there is no issue because the values of x86
>> AVX512 opmasks only depend on which vector lanes are active. But AArch64
>> is different - the values of SVE predicates also depend on lane size of
>> the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
>> sizes, we should use different vector masks. For now, we just support
>> loops with only one vector element size, i.e., "int + float" vectors in
>> a single loop is ok but "int + double" vectors in a single loop is not
>> vectorizable. This fix also enables subword vectors support to make all
>> primitive type array operations vectorizable.
>> 
>> - **[Issue-5] Incorrect result in loops with potential data dependence**
>> 
>> This issue can be reproduced by below corner case on AArch64 only.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     a[i] = x;
>>     a[i + OFFSET] = y;
>>   }
>> 
>> In this case, two stores in the loop have data dependence if the OFFSET
>> value is smaller than the vector length. So we cannot do vectorization
>> through replacing scalars to vectors. But the main loop vectorization
>> in this case is successful on AArch64 because AArch64 has partial vector
>> load/store support. It splits vector fill with different values in lanes
>> to several smaller-sized fills. In this patch, we add additional data
>> dependence check for this kind of cases. The check is also done with the
>> help of SWPointer class. In this check, we require that every two memory
>> accesses (with at least one store) of the same element type (or subword
>> size) in the loop has the same array index expression.
>> 
>> ### Tests
>> 
>> So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
>> experimental VM option "PostLoopMultiversioning" turned on. We found no
>> issue in all tests. We notice that those existing cases are not enough
>> because some of above issues are not spotted by them. We would like to
>> add some new cases but we found existing vectorization tests are a bit
>> cumbersome - golden results must be pre-calculated and hard-coded in the
>> test code for correctness verification. Thus, in this patch, we propose
>> a new vectorization testing framework.
>> 
>> Our new framework brings a simpler way to add new cases. For a new test
>> case, we only need to create a new method annotated with "@Test". The
>> test runner will invoke each annotated method twice automatically. First
>> time it runs in the interpreter and second time it's forced compiled by
>> C2. Then the two return results are compared. So in this framework each
>> test method should return a primitive value or an array of primitives.
>> In this way, no extra verification code for vectorization correctness is
>> required. This test runner is still jtreg-based and takes advantages of
>> the jtreg WhiteBox API, which enables test methods running at specific
>> compilation levels. Each test class inside is also jtreg-based. It just
>> need to inherit from the test runner class and run with two additional
>> options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
>> 
>> ### Summary & Future work
>> 
>> In this patch, we reworked post loop vectorization. We made it platform
>> independent and fixed several issues inside. We also implemented a new
>> vectorization testing framework with many test cases inside. Meanwhile,
>> we did some code cleanups.
>> 
>> This patch only touches C2 code guarded with PostLoopMultiversioning,
>> except a few data structure changes. So, there's no behavior change when
>> experimental VM option PostLoopMultiversioning is off. Also, to reduce
>> risks, we still propose to keep post loop vectorization experimental for
>> now. But if it receives positive feedback, we would like to change it to
>> non-experimental in the future.
>
> Pengfei Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into postloop
>    
>    Change-Id: I503edb75f0f626569c776416bfef09651935979c
>  - Update copyright year and rename a function
>    
>    Change-Id: I15845ebd3982edebd4c151284cc6f2ff727630bb
>  - Merge branch 'master' into postloop
>    
>    Change-Id: Ie639c79c9cf016dc68ebf2c0031b60453b45e9a4
>  - Fix issues in newly added test framework
>    
>    Change-Id: I6e61abf05e9665325cb3abaf407360b18355c6b1
>  - Merge branch 'master' into postloop
>    
>    Change-Id: I9bb5a808d7540426dedb141fd198d25eb1f569e6
>  - 8183390: Fix and re-enable post loop vectorization
>    
>    ** Background
>    
>    Post loop vectorization is a C2 compiler optimization in an experimental
>    VM feature called PostLoopMultiversioning. It transforms the range-check
>    eliminated post loop to a 1-iteration vectorized loop with vector mask.
>    This optimization was contributed by Intel in 2016 to support x86 AVX512
>    masked vector instructions. However, it was disabled soon after an issue
>    was found. Due to insufficient maintenance in these years, multiple bugs
>    have been accumulated inside. But we (Arm) still think this is a useful
>    framework for vector mask support in C2 auto-vectorized loops, for both
>    x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
>    post loop vectorization.
>    
>    ** Changes in this patch
>    
>    This patch reworks post loop vectorization. The most significant change
>    is removing vector mask support in C2 x86 backend and re-implementing
>    it in the mid-end. With this, we can re-enable post loop vectorization
>    for platforms other than x86.
>    
>    Previous implementation hard-codes x86 k1 register as a reserved AVX512
>    opmask register and defines two routines (setvectmask/restorevectmask)
>    to set and restore the value of k1. But after JDK-8211251 which encodes
>    AVX512 instructions as unmasked by default, generated vector masks are
>    no longer used in AVX512 vector instructions. To fix incorrect codegen
>    and add vector mask support for more platforms, we turn to add a vector
>    mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
>    to generate a mask and replace all Load/Store nodes in the post loop
>    into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
>    IR form is exactly the same to those which are used in VectorAPI mask
>    support. For now, we only add mask inputs for Load/Store nodes because
>    we don't have reduction operations supported in post loop vectorization.
>    After this change, the x86 k1 register is no longer reserved and can be
>    allocated when PostLoopMultiversioning is enabled.
>    
>    Besides this change, we have fixed a compiler crash and five incorrect
>    result issues with post loop vectorization.
>    
>    - 1) C2 crashes with segmentation fault in strip-mined loops
>    
>    Previous implementation was done before C2 loop strip-mining was merged
>    into JDK master so it didn't take strip-mined loops into consideration.
>    In C2's strip mined loops, post loop is not the sibling of the main loop
>    in ideal loop tree. Instead, it's the sibling of the main loop's parent.
>    This patch fixed a SIGSEGV issue caused by NULL pointer when locating
>    post loop from strip-mined main loop.
>    
>    - 2) Incorrect result issues with post loop vectorization
>    
>    We have also fixed five incorrect vectorization issues. Some of them are
>    hidden deep and can only be reproduced with corner cases. These issues
>    have a common cause that it assumes the post loop can be vectorized if
>    the vectorization in corresponding main loop is successful. But in many
>    cases this assumption is wrong. Below are details.
>    
>    [Issue-1] Incorrect vectorization for partial vectorizable loops
>    
>    This issue can be reproduced by below loop where only some operations in
>    the loop body are vectorizable.
>    
>      for (int i = 0; i < 10000; i++) {
>        res[i] = a[i] * b[i];
>        k = 3 * k + 1;
>      }
>    
>    In the main loop, superword can work well if parts of the operations in
>    loop body are not vectorizable since those parts can be unrolled only.
>    But for post loops, we don't create vectors through combining scalar IRs
>    generated from loop unrolling. Instead, we are doing scalars to vectors
>    replacement for all operations in the loop body. Hence, all operations
>    should be either vectorized together or not vectorized at all. To fix
>    this kind of cases, we add an extra field "_slp_vector_pack_count" in
>    CountedLoopNode to record the eventual count of vector packs in the main
>    loop. This value is then passed to post loop and compared with post loop
>    pack count. Vectorization will be bailed out in post loop if it creates
>    more vector packs than in the main loop.
>    
>    [Issue-2] Incorrect result in loops with growing-down vectors
>    
>    This issue appears with growing-down vectors, that is, vectors that grow
>    to smaller memory address as the loop iterates. It can be reproduced by
>    below counting-up loop with negative scale value in array index.
>    
>      for (int i = 0; i < 10000; i++) {
>        a[MAX - i] = b[MAX - i];
>      }
>    
>    Cause of this issue is that for a growing-down vector, generated vector
>    mask value has reversed vector-lane order so it masks incorrect vector
>    lanes. Note that if negative scale value appears in counting-down loops,
>    the vector will be growing up. With this rule, we fix the issue by only
>    allowing positive array index scales in counting-up loops and negative
>    array index scales in counting-down loops. This check is done with the
>    help of SWPointer by comparing scale values in each memory access in the
>    loop with loop stride value.
>    
>    [Issue-3] Incorrect result in manually unrolled loops
>    
>    This issue can be reproduced by below manually unrolled loop.
>    
>      for (int i = 0; i < 10000; i += 2) {
>        c[i] = a[i] + b[i];
>        c[i + 1] = a[i + 1] * b[i + 1];
>      }
>    
>    In this loop, operations in the 2nd statement duplicate those in the 1st
>    statement with a small memory address offset. Vectorization in the main
>    loop works well in this case because C2 does further unrolling and pack
>    combination. But we cannot vectorize the post loop through replacement
>    from scalars to vectors because it creates duplicated vector operations.
>    To fix this, we restrict post loop vectorization to loops with stride
>    values of 1 or -1.
>    
>    [Issue-4] Incorrect result in loops with mixed vector element sizes
>    
>    This issue is found after we enable post loop vectorization for AArch64.
>    It's reproducible by multiple array operations with different element
>    sizes inside a loop. On x86, there is no issue because the values of x86
>    AVX512 opmasks only depend on which vector lanes are active. But AArch64
>    is different - the values of SVE predicates also depend on lane size of
>    the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
>    sizes, we should use different vector masks. For now, we just support
>    loops with only one vector element size, i.e., "int + float" vectors in
>    a single loop is ok but "int + double" vectors in a single loop is not
>    vectorizable. This fix also enables subword vectors support to make all
>    primitive type array operations vectorizable.
>    
>    [Issue-5] Incorrect result in loops with potential data dependence
>    
>    This issue can be reproduced by below corner case on AArch64 only.
>    
>      for (int i = 0; i < 10000; i++) {
>        a[i] = x;
>        a[i + OFFSET] = y;
>      }
>    
>    In this case, two stores in the loop have data dependence if the OFFSET
>    value is smaller than the vector length. So we cannot do vectorization
>    through replacing scalars to vectors. But the main loop vectorization
>    in this case is successful on AArch64 because AArch64 has partial vector
>    load/store support. It splits vector fill with different values in lanes
>    to several smaller-sized fills. In this patch, we add additional data
>    dependence check for this kind of cases. The check is also done with the
>    help of SWPointer class. In this check, we require that every two memory
>    accesses (with at least one store) of the same element type (or subword
>    size) in the loop has the same array index expression.
>    
>    ** Tests
>    
>    So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
>    experimental VM option "PostLoopMultiversioning" turned on. We found no
>    issue in all tests. We notice that those existing cases are not enough
>    because some of above issues are not spotted by them. We would like to
>    add some new cases but we found existing vectorization tests are a bit
>    cumbersome - golden results must be pre-calculated and hard-coded in the
>    test code for correctness verification. Thus, in this patch, we propose
>    a new vectorization testing framework.
>    
>    Our new framework brings a simpler way to add new cases. For a new test
>    case, we only need to create a new method annotated with "@Test". The
>    test runner will invoke each annotated method twice automatically. First
>    time it runs in the interpreter and second time it's forced compiled by
>    C2. Then the two return results are compared. So in this framework each
>    test method should return a primitive value or an array of primitives.
>    In this way, no extra verification code for vectorization correctness is
>    required. This test runner is still jtreg-based and takes advantages of
>    the jtreg WhiteBox API, which enables test methods running at specific
>    compilation levels. Each test class inside is also jtreg-based. It just
>    need to inherit from the test runner class and run with two additional
>    options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
>    
>    ** Summary & Future work
>    
>    In this patch, we reworked post loop vectorization. We made it platform
>    independent and fixed several issues inside. We also implemented a new
>    vectorization testing framework with many test cases inside. Meanwhile,
>    we did some code cleanups.
>    
>    This patch only touches C2 code guarded with PostLoopMultiversioning,
>    except a few data structure changes. So, there's no behavior change when
>    experimental VM option PostLoopMultiversioning is off. Also, to reduce
>    risks, we still propose to keep post loop vectorization experimental for
>    now. But if it receives positive feedback, we would like to change it to
>    non-experimental in the future.

Thanks Roland for looking at this. Firstly I'd like to answer your general questions.

> fairly similar. Doesn't/couldn't the logic from issue 5 protect from issue 3?

True, the SWPointer logic can also protect from issue 3. But I believe keeping loop stride check for issue 3 has no harm and post loop vectorization can bail out earlier with this additional check.

> I see no reason not to proceed with this change as it attempts to fix something that's broken and nobody uses, doesn't enable it by default and doesn't affect code other than post loop vectorization.

Yes, this feature has been broken for years. And as I mentioned in the [slides](http://cr.openjdk.java.net/~pli/slides/JDK-8183390.pdf), fixing this is our first trial and initial step of adding vector mask support in C2 vectorized loops.

> I haven't looked at tests closely but I don't think there are IR tests. Maybe you want to consider adding some as a follow up to this PR.

Your guess is right. Current test code in this PR only focuses on the **correctness** of vectorization. We have been using it internally for over 1 year and we have found several superword and AArch64 vector matching rule issues with its help. And internally based on this framework we have some test logic focuses on **vectorizability** as well as **correctness**. But currently it is **not** IR tests based because our test runner logic (it invokes each test method twice, 1st time interpreter and 2nd time compiled by C2) is not compatible with the IR test driver. But currently we are working on it to make a better **vectorizability** check (IR test is already in our consideration). As we think the **correctness** check part is quite useful for adding new cases for C2 vectorization fixes and improvements, we propose to contribute this part first in this PR.

Thanks again for you review. I will address your comments, rebase and re-test this patch, and reply you later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6828

From manc at openjdk.java.net  Fri Mar 11 02:37:39 2022
From: manc at openjdk.java.net (Man Cao)
Date: Fri, 11 Mar 2022 02:37:39 GMT
Subject: RFR: 8282507: Add LICENSE file for hsdis
In-Reply-To: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
References: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
Message-ID: <HVcb6Re3Megk0CaFT0EOYozOuQRzt3xKPOX6O3USIrQ=.ad6cf4ea-7170-4daf-9891-59540298dd50@github.com>

On Tue, 1 Mar 2022 20:18:11 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone help review the addition of LICENSE file to hsdis directory?
> 
> -Man

Thank you for pointing out the difference between hsdis and other 3rd party code.

> src/java.desktop/share/native/libsplashscreen/libpng/LICENSE seems like a mistake. There should be a libpng.md file in java.desktop/share/legal instead.

Yes, src/java.desktop/share/legal/libpng.md already exists and contains the same content.

Is hsdis the only part of code in OpenJDK that is written by the OpenJDK community, but not licensed under GPLv2+Classpath Exception? If so, we cannot say which way is consistent.

I do think a separate license file for hsdis is better, as the top-level LICENSE file does not mention the UPLv1 license, and it doesn't apply to hsdis. Having a separate license file is also a common approach for open source software.

What do you think? Again if it takes a lot of your time to get legal approval for this, then it is probably not worth it. Or could we rename the file to something like hsdis-license.txt so it doesn't need legal review?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7649

From dlong at openjdk.java.net  Fri Mar 11 04:21:00 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 11 Mar 2022 04:21:00 GMT
Subject: RFR: 8279317: compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java
 assumes immutable code
Message-ID: <0p4QBsFdOEKPXTYliqwV4vhZ7e9uIv4V-853Q8U9kV0=.49b2d69e-14a1-4917-b899-02b3a7a7d504@github.com>

This test was failing in loom because of nmethod entry barriers, but there are other reasons why it shouldn't assume immutable code, such as embedded oops and NativeJump::patch_verified_entry().

-------------

Commit messages:
 - check dissasembly layout rather than checking for immutable code

Changes: https://git.openjdk.java.net/jdk/pull/7781/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7781&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8279317
  Stats: 31 lines in 1 file changed: 19 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7781.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7781/head:pull/7781

PR: https://git.openjdk.java.net/jdk/pull/7781

From duke at openjdk.java.net  Fri Mar 11 05:19:25 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Fri, 11 Mar 2022 05:19:25 GMT
Subject: RFR: 8281453: New optimization: convert "c-(~x)" into "x+(c+1)"
 and "~(c-x)" into "x+(-c-1)" [v2]
In-Reply-To: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
References: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
Message-ID: <YkXMw6OAHHV7a0p2RScHz1yPUWT2ljCSSu3fwKT-7vo=.3cab06fa-6022-413f-8e75-6e9043ccc912@github.com>

> Similar to `(~x)+c` -> `(c-1)-x` and `~(x+c)` -> `(-c-1)-x` in #6858, we can also introduce similar optimizations for subtraction, `c-(~x)` -> `x+(c+1)` and `~(c-x)` -> `x+(-c-1)`.
> 
> The results of the microbenchmark are as follows:
> 
> Baseline:                                                                                                                                         
> Benchmark                        Mode  Cnt  Score   Error  Units
> SubIdealCMinusNotX.baselineInt   avgt   60  0.504 ? 0.011  ns/op
> SubIdealCMinusNotX.baselineLong  avgt   60  0.484 ? 0.004  ns/op
> SubIdealCMinusNotX.testInt1      avgt   60  0.779 ? 0.004  ns/op
> SubIdealCMinusNotX.testInt2      avgt   60  0.896 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong1     avgt   60  0.722 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong2     avgt   60  0.720 ? 0.005  ns/op
> 
> Patch:
> Benchmark                        Mode  Cnt  Score   Error  Units
> SubIdealCMinusNotX.baselineInt   avgt   60  0.487 ? 0.009  ns/op
> SubIdealCMinusNotX.baselineLong  avgt   60  0.486 ? 0.009  ns/op
> SubIdealCMinusNotX.testInt1      avgt   60  0.372 ? 0.010  ns/op
> SubIdealCMinusNotX.testInt2      avgt   60  0.365 ? 0.003  ns/op
> SubIdealCMinusNotX.testLong1     avgt   60  0.369 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong2     avgt   60  0.399 ? 0.016  ns/op

Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:

  convert ~x into -1-x when ~x is part of Add and Sub.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7376/files
  - new: https://git.openjdk.java.net/jdk/pull/7376/files/35abcb2d..76bde38e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7376&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7376&range=00-01

  Stats: 217 lines in 4 files changed: 191 ins; 6 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7376/head:pull/7376

PR: https://git.openjdk.java.net/jdk/pull/7376

From fgao at openjdk.java.net  Fri Mar 11 06:13:33 2022
From: fgao at openjdk.java.net (Fei Gao)
Date: Fri, 11 Mar 2022 06:13:33 GMT
Subject: RFR: 8280511: AArch64: Combine shift and negate to a single
 instruction [v2]
In-Reply-To: <Aq55iB5EtUCgHU2-75Y-h-LBOqQBNxtr5QWRcTNHb4A=.b51d839c-3783-48ec-b084-f4604ca5b617@github.com>
References: <Aq55iB5EtUCgHU2-75Y-h-LBOqQBNxtr5QWRcTNHb4A=.b51d839c-3783-48ec-b084-f4604ca5b617@github.com>
Message-ID: <8fW78fSKlQDkJ3be_KdWelRSGaT38qapIj_cjvbjJ6E=.bba850f0-f823-401e-b6e3-0829139c5842@github.com>

> Hi,
> 
> In AArch64,
> 
> asr     x10, x1, #31
> neg     x0, x10
> 
> can be optimized to:
> `neg    x0, x1, asr #31`
> 
> To implement the instruction combining, we add matching rules in the backend.
> 
> Thanks.

Fei Gao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into fg8280511
   
   Change-Id: I80c9540ef3191d1d828b1d123ee346050152ac5b
 - 8280511: AArch64: Combine shift and negate to a single instruction
   
   In AArch64,
   
   asr     x10, x1, #31
   neg     x0, x10
   
   can be optimized to:
   
   neg    x0, x1, asr #31
   
   To implement the instruction combining, we add matching rules in
   the backend.
   
   Change-Id: Iaee06f7a03e97a7e092e13da75812f3722549c3b

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7471/files
  - new: https://git.openjdk.java.net/jdk/pull/7471/files/e8479747..64cbed6f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7471&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7471&range=00-01

  Stats: 39053 lines in 1020 files changed: 27283 ins; 6072 del; 5698 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7471.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7471/head:pull/7471

PR: https://git.openjdk.java.net/jdk/pull/7471

From pli at openjdk.java.net  Fri Mar 11 07:48:06 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Fri, 11 Mar 2022 07:48:06 GMT
Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v5]
In-Reply-To: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
References: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
Message-ID: <ZZRxvB2oQrb51MCIxVaKVL3rqILOvZXwMasE04FO6Fc=.998b77e0-396a-4a32-a936-38ead882009f@github.com>

> ### Background
> 
> Post loop vectorization is a C2 compiler optimization in an experimental
> VM feature called PostLoopMultiversioning. It transforms the range-check
> eliminated post loop to a 1-iteration vectorized loop with vector mask.
> This optimization was contributed by Intel in 2016 to support x86 AVX512
> masked vector instructions. However, it was disabled soon after an issue
> was found. Due to insufficient maintenance in these years, multiple bugs
> have been accumulated inside. But we (Arm) still think this is a useful
> framework for vector mask support in C2 auto-vectorized loops, for both
> x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
> post loop vectorization.
> 
> ### Changes in this patch
> 
> This patch reworks post loop vectorization. The most significant change
> is removing vector mask support in C2 x86 backend and re-implementing
> it in the mid-end. With this, we can re-enable post loop vectorization
> for platforms other than x86.
> 
> Previous implementation hard-codes x86 k1 register as a reserved AVX512
> opmask register and defines two routines (setvectmask/restorevectmask)
> to set and restore the value of k1. But after [JDK-8211251](https://bugs.openjdk.java.net/browse/JDK-8211251) which encodes
> AVX512 instructions as unmasked by default, generated vector masks are
> no longer used in AVX512 vector instructions. To fix incorrect codegen
> and add vector mask support for more platforms, we turn to add a vector
> mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
> to generate a mask and replace all Load/Store nodes in the post loop
> into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
> IR form is exactly the same to those which are used in VectorAPI mask
> support. For now, we only add mask inputs for Load/Store nodes because
> we don't have reduction operations supported in post loop vectorization.
> After this change, the x86 k1 register is no longer reserved and can be
> allocated when PostLoopMultiversioning is enabled.
> 
> Besides this change, we have fixed a compiler crash and five incorrect
> result issues with post loop vectorization.
> 
> **I) C2 crashes with segmentation fault in strip-mined loops**
> 
> Previous implementation was done before C2 loop strip-mining was merged
> into JDK master so it didn't take strip-mined loops into consideration.
> In C2's strip mined loops, post loop is not the sibling of the main loop
> in ideal loop tree. Instead, it's the sibling of the main loop's parent.
> This patch fixed a SIGSEGV issue caused by NULL pointer when locating
> post loop from strip-mined main loop.
> 
> **II) Incorrect result issues with post loop vectorization**
> 
> We have also fixed five incorrect vectorization issues. Some of them are
> hidden deep and can only be reproduced with corner cases. These issues
> have a common cause that it assumes the post loop can be vectorized if
> the vectorization in corresponding main loop is successful. But in many
> cases this assumption is wrong. Below are details.
> 
> - **[Issue-1] Incorrect vectorization for partial vectorizable loops**
> 
> This issue can be reproduced by below loop where only some operations in
> the loop body are vectorizable.
> 
>   for (int i = 0; i < 10000; i++) {
>     res[i] = a[i] * b[i];
>     k = 3 * k + 1;
>   }
> 
> In the main loop, superword can work well if parts of the operations in
> loop body are not vectorizable since those parts can be unrolled only.
> But for post loops, we don't create vectors through combining scalar IRs
> generated from loop unrolling. Instead, we are doing scalars to vectors
> replacement for all operations in the loop body. Hence, all operations
> should be either vectorized together or not vectorized at all. To fix
> this kind of cases, we add an extra field "_slp_vector_pack_count" in
> CountedLoopNode to record the eventual count of vector packs in the main
> loop. This value is then passed to post loop and compared with post loop
> pack count. Vectorization will be bailed out in post loop if it creates
> more vector packs than in the main loop.
> 
> - **[Issue-2] Incorrect result in loops with growing-down vectors**
> 
> This issue appears with growing-down vectors, that is, vectors that grow
> to smaller memory address as the loop iterates. It can be reproduced by
> below counting-up loop with negative scale value in array index.
> 
>   for (int i = 0; i < 10000; i++) {
>     a[MAX - i] = b[MAX - i];
>   }
> 
> Cause of this issue is that for a growing-down vector, generated vector
> mask value has reversed vector-lane order so it masks incorrect vector
> lanes. Note that if negative scale value appears in counting-down loops,
> the vector will be growing up. With this rule, we fix the issue by only
> allowing positive array index scales in counting-up loops and negative
> array index scales in counting-down loops. This check is done with the
> help of SWPointer by comparing scale values in each memory access in the
> loop with loop stride value.
> 
> - **[Issue-3] Incorrect result in manually unrolled loops**
> 
> This issue can be reproduced by below manually unrolled loop.
> 
>   for (int i = 0; i < 10000; i += 2) {
>     c[i] = a[i] + b[i];
>     c[i + 1] = a[i + 1] * b[i + 1];
>   }
> 
> In this loop, operations in the 2nd statement duplicate those in the 1st
> statement with a small memory address offset. Vectorization in the main
> loop works well in this case because C2 does further unrolling and pack
> combination. But we cannot vectorize the post loop through replacement
> from scalars to vectors because it creates duplicated vector operations.
> To fix this, we restrict post loop vectorization to loops with stride
> values of 1 or -1.
> 
> - **[Issue-4] Incorrect result in loops with mixed vector element sizes**
> 
> This issue is found after we enable post loop vectorization for AArch64.
> It's reproducible by multiple array operations with different element
> sizes inside a loop. On x86, there is no issue because the values of x86
> AVX512 opmasks only depend on which vector lanes are active. But AArch64
> is different - the values of SVE predicates also depend on lane size of
> the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
> sizes, we should use different vector masks. For now, we just support
> loops with only one vector element size, i.e., "int + float" vectors in
> a single loop is ok but "int + double" vectors in a single loop is not
> vectorizable. This fix also enables subword vectors support to make all
> primitive type array operations vectorizable.
> 
> - **[Issue-5] Incorrect result in loops with potential data dependence**
> 
> This issue can be reproduced by below corner case on AArch64 only.
> 
>   for (int i = 0; i < 10000; i++) {
>     a[i] = x;
>     a[i + OFFSET] = y;
>   }
> 
> In this case, two stores in the loop have data dependence if the OFFSET
> value is smaller than the vector length. So we cannot do vectorization
> through replacing scalars to vectors. But the main loop vectorization
> in this case is successful on AArch64 because AArch64 has partial vector
> load/store support. It splits vector fill with different values in lanes
> to several smaller-sized fills. In this patch, we add additional data
> dependence check for this kind of cases. The check is also done with the
> help of SWPointer class. In this check, we require that every two memory
> accesses (with at least one store) of the same element type (or subword
> size) in the loop has the same array index expression.
> 
> ### Tests
> 
> So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
> experimental VM option "PostLoopMultiversioning" turned on. We found no
> issue in all tests. We notice that those existing cases are not enough
> because some of above issues are not spotted by them. We would like to
> add some new cases but we found existing vectorization tests are a bit
> cumbersome - golden results must be pre-calculated and hard-coded in the
> test code for correctness verification. Thus, in this patch, we propose
> a new vectorization testing framework.
> 
> Our new framework brings a simpler way to add new cases. For a new test
> case, we only need to create a new method annotated with "@Test". The
> test runner will invoke each annotated method twice automatically. First
> time it runs in the interpreter and second time it's forced compiled by
> C2. Then the two return results are compared. So in this framework each
> test method should return a primitive value or an array of primitives.
> In this way, no extra verification code for vectorization correctness is
> required. This test runner is still jtreg-based and takes advantages of
> the jtreg WhiteBox API, which enables test methods running at specific
> compilation levels. Each test class inside is also jtreg-based. It just
> need to inherit from the test runner class and run with two additional
> options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
> 
> ### Summary & Future work
> 
> In this patch, we reworked post loop vectorization. We made it platform
> independent and fixed several issues inside. We also implemented a new
> vectorization testing framework with many test cases inside. Meanwhile,
> we did some code cleanups.
> 
> This patch only touches C2 code guarded with PostLoopMultiversioning,
> except a few data structure changes. So, there's no behavior change when
> experimental VM option PostLoopMultiversioning is off. Also, to reduce
> risks, we still propose to keep post loop vectorization experimental for
> now. But if it receives positive feedback, we would like to change it to
> non-experimental in the future.

Pengfei Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Add assertion of PostLoopMultiversioning
 - Merge branch 'master' into postloop
 - Merge branch 'master' into postloop
   
   Change-Id: I503edb75f0f626569c776416bfef09651935979c
 - Update copyright year and rename a function
   
   Change-Id: I15845ebd3982edebd4c151284cc6f2ff727630bb
 - Merge branch 'master' into postloop
   
   Change-Id: Ie639c79c9cf016dc68ebf2c0031b60453b45e9a4
 - Fix issues in newly added test framework
   
   Change-Id: I6e61abf05e9665325cb3abaf407360b18355c6b1
 - Merge branch 'master' into postloop
   
   Change-Id: I9bb5a808d7540426dedb141fd198d25eb1f569e6
 - 8183390: Fix and re-enable post loop vectorization
   
   ** Background
   
   Post loop vectorization is a C2 compiler optimization in an experimental
   VM feature called PostLoopMultiversioning. It transforms the range-check
   eliminated post loop to a 1-iteration vectorized loop with vector mask.
   This optimization was contributed by Intel in 2016 to support x86 AVX512
   masked vector instructions. However, it was disabled soon after an issue
   was found. Due to insufficient maintenance in these years, multiple bugs
   have been accumulated inside. But we (Arm) still think this is a useful
   framework for vector mask support in C2 auto-vectorized loops, for both
   x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
   post loop vectorization.
   
   ** Changes in this patch
   
   This patch reworks post loop vectorization. The most significant change
   is removing vector mask support in C2 x86 backend and re-implementing
   it in the mid-end. With this, we can re-enable post loop vectorization
   for platforms other than x86.
   
   Previous implementation hard-codes x86 k1 register as a reserved AVX512
   opmask register and defines two routines (setvectmask/restorevectmask)
   to set and restore the value of k1. But after JDK-8211251 which encodes
   AVX512 instructions as unmasked by default, generated vector masks are
   no longer used in AVX512 vector instructions. To fix incorrect codegen
   and add vector mask support for more platforms, we turn to add a vector
   mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
   to generate a mask and replace all Load/Store nodes in the post loop
   into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
   IR form is exactly the same to those which are used in VectorAPI mask
   support. For now, we only add mask inputs for Load/Store nodes because
   we don't have reduction operations supported in post loop vectorization.
   After this change, the x86 k1 register is no longer reserved and can be
   allocated when PostLoopMultiversioning is enabled.
   
   Besides this change, we have fixed a compiler crash and five incorrect
   result issues with post loop vectorization.
   
   - 1) C2 crashes with segmentation fault in strip-mined loops
   
   Previous implementation was done before C2 loop strip-mining was merged
   into JDK master so it didn't take strip-mined loops into consideration.
   In C2's strip mined loops, post loop is not the sibling of the main loop
   in ideal loop tree. Instead, it's the sibling of the main loop's parent.
   This patch fixed a SIGSEGV issue caused by NULL pointer when locating
   post loop from strip-mined main loop.
   
   - 2) Incorrect result issues with post loop vectorization
   
   We have also fixed five incorrect vectorization issues. Some of them are
   hidden deep and can only be reproduced with corner cases. These issues
   have a common cause that it assumes the post loop can be vectorized if
   the vectorization in corresponding main loop is successful. But in many
   cases this assumption is wrong. Below are details.
   
   [Issue-1] Incorrect vectorization for partial vectorizable loops
   
   This issue can be reproduced by below loop where only some operations in
   the loop body are vectorizable.
   
     for (int i = 0; i < 10000; i++) {
       res[i] = a[i] * b[i];
       k = 3 * k + 1;
     }
   
   In the main loop, superword can work well if parts of the operations in
   loop body are not vectorizable since those parts can be unrolled only.
   But for post loops, we don't create vectors through combining scalar IRs
   generated from loop unrolling. Instead, we are doing scalars to vectors
   replacement for all operations in the loop body. Hence, all operations
   should be either vectorized together or not vectorized at all. To fix
   this kind of cases, we add an extra field "_slp_vector_pack_count" in
   CountedLoopNode to record the eventual count of vector packs in the main
   loop. This value is then passed to post loop and compared with post loop
   pack count. Vectorization will be bailed out in post loop if it creates
   more vector packs than in the main loop.
   
   [Issue-2] Incorrect result in loops with growing-down vectors
   
   This issue appears with growing-down vectors, that is, vectors that grow
   to smaller memory address as the loop iterates. It can be reproduced by
   below counting-up loop with negative scale value in array index.
   
     for (int i = 0; i < 10000; i++) {
       a[MAX - i] = b[MAX - i];
     }
   
   Cause of this issue is that for a growing-down vector, generated vector
   mask value has reversed vector-lane order so it masks incorrect vector
   lanes. Note that if negative scale value appears in counting-down loops,
   the vector will be growing up. With this rule, we fix the issue by only
   allowing positive array index scales in counting-up loops and negative
   array index scales in counting-down loops. This check is done with the
   help of SWPointer by comparing scale values in each memory access in the
   loop with loop stride value.
   
   [Issue-3] Incorrect result in manually unrolled loops
   
   This issue can be reproduced by below manually unrolled loop.
   
     for (int i = 0; i < 10000; i += 2) {
       c[i] = a[i] + b[i];
       c[i + 1] = a[i + 1] * b[i + 1];
     }
   
   In this loop, operations in the 2nd statement duplicate those in the 1st
   statement with a small memory address offset. Vectorization in the main
   loop works well in this case because C2 does further unrolling and pack
   combination. But we cannot vectorize the post loop through replacement
   from scalars to vectors because it creates duplicated vector operations.
   To fix this, we restrict post loop vectorization to loops with stride
   values of 1 or -1.
   
   [Issue-4] Incorrect result in loops with mixed vector element sizes
   
   This issue is found after we enable post loop vectorization for AArch64.
   It's reproducible by multiple array operations with different element
   sizes inside a loop. On x86, there is no issue because the values of x86
   AVX512 opmasks only depend on which vector lanes are active. But AArch64
   is different - the values of SVE predicates also depend on lane size of
   the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
   sizes, we should use different vector masks. For now, we just support
   loops with only one vector element size, i.e., "int + float" vectors in
   a single loop is ok but "int + double" vectors in a single loop is not
   vectorizable. This fix also enables subword vectors support to make all
   primitive type array operations vectorizable.
   
   [Issue-5] Incorrect result in loops with potential data dependence
   
   This issue can be reproduced by below corner case on AArch64 only.
   
     for (int i = 0; i < 10000; i++) {
       a[i] = x;
       a[i + OFFSET] = y;
     }
   
   In this case, two stores in the loop have data dependence if the OFFSET
   value is smaller than the vector length. So we cannot do vectorization
   through replacing scalars to vectors. But the main loop vectorization
   in this case is successful on AArch64 because AArch64 has partial vector
   load/store support. It splits vector fill with different values in lanes
   to several smaller-sized fills. In this patch, we add additional data
   dependence check for this kind of cases. The check is also done with the
   help of SWPointer class. In this check, we require that every two memory
   accesses (with at least one store) of the same element type (or subword
   size) in the loop has the same array index expression.
   
   ** Tests
   
   So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
   experimental VM option "PostLoopMultiversioning" turned on. We found no
   issue in all tests. We notice that those existing cases are not enough
   because some of above issues are not spotted by them. We would like to
   add some new cases but we found existing vectorization tests are a bit
   cumbersome - golden results must be pre-calculated and hard-coded in the
   test code for correctness verification. Thus, in this patch, we propose
   a new vectorization testing framework.
   
   Our new framework brings a simpler way to add new cases. For a new test
   case, we only need to create a new method annotated with "@Test". The
   test runner will invoke each annotated method twice automatically. First
   time it runs in the interpreter and second time it's forced compiled by
   C2. Then the two return results are compared. So in this framework each
   test method should return a primitive value or an array of primitives.
   In this way, no extra verification code for vectorization correctness is
   required. This test runner is still jtreg-based and takes advantages of
   the jtreg WhiteBox API, which enables test methods running at specific
   compilation levels. Each test class inside is also jtreg-based. It just
   need to inherit from the test runner class and run with two additional
   options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
   
   ** Summary & Future work
   
   In this patch, we reworked post loop vectorization. We made it platform
   independent and fixed several issues inside. We also implemented a new
   vectorization testing framework with many test cases inside. Meanwhile,
   we did some code cleanups.
   
   This patch only touches C2 code guarded with PostLoopMultiversioning,
   except a few data structure changes. So, there's no behavior change when
   experimental VM option PostLoopMultiversioning is off. Also, to reduce
   risks, we still propose to keep post loop vectorization experimental for
   now. But if it receives positive feedback, we would like to change it to
   non-experimental in the future.

-------------

Changes: https://git.openjdk.java.net/jdk/pull/6828/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6828&range=04
  Stats: 4832 lines in 39 files changed: 4509 ins; 284 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6828.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6828/head:pull/6828

PR: https://git.openjdk.java.net/jdk/pull/6828

From thartmann at openjdk.java.net  Fri Mar 11 08:09:40 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Fri, 11 Mar 2022 08:09:40 GMT
Subject: RFR: 8282592: C2: assert(false) failed: graph should be
 schedulable
In-Reply-To: <-oXZLZYrKlxysFQgwKntZUr7dqC6G_WBEzi-ngqwqws=.c1ab815a-9065-4aba-9948-b3df225d0d3e@github.com>
References: <-oXZLZYrKlxysFQgwKntZUr7dqC6G_WBEzi-ngqwqws=.c1ab815a-9065-4aba-9948-b3df225d0d3e@github.com>
Message-ID: <omQutZHngo3WF_ouuPK_fhCFpqOVr8EKbB4Z-aXt0Cg=.f78b828a-eb3e-49c0-afe4-4716b317f7ea@github.com>

On Wed, 9 Mar 2022 13:42:01 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> This is another case of overunrolling that causes the type of the main
> loop's iv to conflict with a ConvI2L of an array access. Skeleton
> predicates were added to solve this family of issues. A predicate that
> should catch that the main loop is unreachable is indeed added but the
> predicate's condition doesn't constant fold.
> 
> What happens is that the main loop's iv phi initial value is a CastII
> (added by PhaseIdealLoop::cast_incr_before_loop()). That CastII is
> input to the predicates above the main loop and of the main loop's iv
> phi. Once loop opts are over, the type of the CastII is updated by
> CastIINode::Value() (the logic that looks at the test that guards the
> CastII). The type update causes the main loop iv phi's type to be
> updated and a ConvI2L to be become top. The predicate that should
> catch the overunrolling has the shape:
> 
> (CmpU (AddI#1 (CastII (AddI#2 (Phi ..) ConI#1)) ConI#2) ConI#3)
> 
> In the case of the test case:
> 
> ConI#3 = 10
> ConI#2 = 7
> ConI#1 = 1
> 
> CastII has type = int:<=max-8
> Phi has type = int:>=8
> 
> As a result:
> AddI#2 has type int
> AddI#1 has type int:min+7..max-1
> 
> The Phi is the pre loop Phi.
> 
> The fix I propose is that predicates when they are updated should skip
> over the CastII, that is in this case:
> 
> (CmpU (AddI#1 (AddI#2 (Phi ..) ConI#1) ConI#2) ConI#3)
> 
> which is reshaped to:
> 
> (CmpU (AddI#1' (Phi ..) ConI#1') ConI#3)
> 
> In this case:
> 
> ConI#1 = 4 (because the predicate constant fold in earlier passes of
> unrolling)
> 
> As a result AddI#1' still has type int But CmpUNode has special logic
> to deal with the (CmpU (AddI ...)) shape and it can determine that
> this one always fails.
> 
> The role of the CastII is to enforce the dependency between nodes in
> the loop and the the loop entry test so it's not required for
> predicates.
> 
> With that change, compiler/loopopts/TestOverunrolling.java fails
> because a predicate doesn't constant fold anymore. The reason in that
> case, is that PhaseIdealLoop::reorg_offsets() adds an Opaque2 between
> the pre loop iv phi and the predicate that hides the type of the iv
> phi. Without the change, the CastII captures the type of the iv phi
> and the Opaque2 node is added between the CastII and the pre loop iv
> phi. To solve that problem, I propose that
> PhaseIdealLoop::reorg_offsets() always add a CastII after the Opaque2
> so the type of the iv phi is not lost.

Gave this a quick run through testing and `compiler/c2/irTests/TestSkeletonPredicates.java` failed with `-XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation`:


 220  ConL  ===  0  [[ 221 ]]  #long:8
 218  ConL  ===  0  [[ 219 ]]  #long:1
 217  StoreP  ===  245  7  194  199  [[ 219 ]]  @rawptr:BotPTR, idx=Raw;  Memory: @rawptr:BotPTR, idx=Raw;
 224  ConL  ===  0  [[ 225 ]]  #long:12
 250  ConNKlass  ===  0  [[ 223 ]]  #narrowklass: precise [double: :Constant:exact *
 221  AddP  === _  198  198  220  [[ 223 ]] 
 219  StoreL  ===  245  217  198  218  [[ 223 ]]  @NULL  Memory: @rawptr:BotPTR, idx=Raw;
 195  ConL  ===  0  [[ 196 ]]  #long:280
 227  ConL  ===  0  [[ 232 ]]  #long:16
 225  AddP  === _  198  198  224  [[ 226 ]] 
 223  StoreNKlass  ===  245  219  221  250  [[ 226 ]]  @NULL  Memory: @rawptr:BotPTR, idx=Raw;
 196  AddP  === _  1  192  195  [[ 197 ]] 
 232  AddP  === _  198  198  227  [[ 251 ]] 
 249  ConL  ===  0  [[ 251 ]]  #long:10
 226  StoreI  ===  245  223  225  24  [[ 251 ]]  @NULL  Memory: @rawptr:BotPTR, idx=Raw;
 205  ConL  ===  0  [[ 206 ]]  #long:192
 197  LoadP  ===  5  7  196  [[ 200 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:BotPTR (does not depend only on test)
 251  ClearArray  ===  245  226  249  232  [[ 189 ]]   Memory: @rawptr:BotPTR, idx=Raw; !orig=[233]
 208  ConL  ===  0  [[ 209 ]]  #long:256
 206  AddP  === _  198  199  205  [[ 207 ]] 
 200  CmpP  === _  199  197  [[ 242 ]] 
 140  CmpI  === _  125  30  [[ 141 ]]  !jvms: TestSkeletonPredicates::test1 @ bci:22 (line 63)
 189  Phi  ===  188  54  251  [[ 60  57 ]]  #memory  Memory: @rawptr:BotPTR, idx=Raw;
 60  MergeMem  === _  1  189  1  1  1  7  [[ 57 ]]  { - - - N7:double[int:>=0]:exact+any * }  Memory: @BotPTR *+bot, idx=Bot; !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 38  ConL  ===  0  [[ 199 ]]  #long:96
 211  ConL  ===  0  [[ 212 ]]  #long:320
 209  AddP  === _  198  199  208  [[ 210 ]] 
 207  PrefetchAllocation  ===  245  6  206  [[ 210 ]] 
 242  Bool  === _  200  [[ 243 ]] [lt]
 40  ConI  ===  0  [[ 181 ]]  #int:1
 141  Bool  === _  140  [[ 142 ]] [ne] !jvms: TestSkeletonPredicates::test1 @ bci:22 (line 63)
 128  CatchProj  ===  127  [[ 142 ]] #0 at bci -1  !jvms: TestSkeletonPredicates::test1 @ bci:19 (line 63)
 193  ConL  ===  0  [[ 194 ]]  #long:264
 192  ThreadLocal  ===  0  [[ 194  196 ]] 
 57  Initialize  ===  188  1  60  1  1  1  189  [[ 236  235 ]]  !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 214  ConL  ===  0  [[ 215 ]]  #long:384
 199  AddP  === _  1  198  38  [[ 200  206  209  212  215  217 ]] 
 212  AddP  === _  198  199  211  [[ 213 ]] 
 210  PrefetchAllocation  === _  207  209  [[ 213 ]] 
 66  CmpI  === _  10  30  [[ 68 ]]  !orig=64 !jvms: TestSkeletonPredicates::test1 @ bci:11 (line 62)
 182  CmpI  === _  181  10  [[ 183 ]]  !orig=[161] !jvms: TestSkeletonPredicates::test1 @ bci:11 (line 62)
 115  Phi  ===  185  238  123  [[ 117 ]]  #memory  Memory: @double[int:>=0]:exact+any *, idx=6; !jvms: TestSkeletonPredicates::test1 @ bci:14 (line 63)
 114  Phi  ===  185  238  123  [[ 117 ]]  #memory  Memory: @java/lang/Object+8 * [narrowklass], idx=5; !jvms: TestSkeletonPredicates::test1 @ bci:14 (line 63)
 113  Phi  ===  185  238  123  [[ 117 ]]  #memory  Memory: @java/lang/Object *, idx=4; !jvms: TestSkeletonPredicates::test1 @ bci:14 (line 63)
 112  Phi  ===  185  238  123  [[ 117 ]]  #memory  Memory: @rawptr:BotPTR, idx=Raw; !jvms: TestSkeletonPredicates::test1 @ bci:14 (line 63)
 111  Phi  ===  185  7  123  [[ 117 ]]  #memory  Memory: @BotPTR *+bot, idx=Bot; !jvms: TestSkeletonPredicates::test1 @ bci:14 (line 63)
 164  IfTrue  ===  184  [[ 185 ]] #1 !jvms: TestSkeletonPredicates::test1 @ bci:11 (line 62)
 71  IfFalse  ===  69  [[ 185 ]] #0 !orig=[87],[100] !jvms: TestSkeletonPredicates::test1 @ bci:11 (line 62)
 243  If  ===  5  242  [[ 244  245 ]] P=0.999900, C=-1.000000 !orig=[202]
 181  AddI  === _  116  40  [[ 116  182 ]]  !orig=[154] !jvms: TestSkeletonPredicates::test1 @ bci:27 (line 62)
 30  ConI  ===  0  [[ 140  116  66 ]]  #int:0
 142  If  ===  128  141  [[ 143  144 ]] P=0.000000, C=12295.000000 !jvms: TestSkeletonPredicates::test1 @ bci:22 (line 63)
 194  AddP  === _  1  192  193  [[ 198  217 ]] 
 5  Parm  ===  3  [[ 243  197  198 ]] Control !jvms: TestSkeletonPredicates::test1 @ bci:-1 (line 60)
 236  Proj  ===  57  [[ 234 ]] #2  Memory: @rawptr:BotPTR, idx=Raw;
 235  Proj  ===  57  [[ 234 ]] #0
 215  AddP  === _  198  199  214  [[ 216 ]] 
 213  PrefetchAllocation  === _  210  212  [[ 216 ]] 
 245  IfTrue  ===  243  [[ 188  251  226  223  219  217  207 ]] #1 !orig=[204]
 240  CatchProj  ===  48  [[ 188 ]] #0 at bci -1  !orig=[49] !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 68  Bool  === _  66  [[ 69 ]] [le] !jvms: TestSkeletonPredicates::test1 @ bci:11 (line 62)
 183  Bool  === _  182  [[ 184 ]] [lt] !orig=[162] !jvms: TestSkeletonPredicates::test1 @ bci:11 (line 62)
 144  IfFalse  ===  142  [[ 184 ]] #0 !orig=155 !jvms: TestSkeletonPredicates::test1 @ bci:22 (line 63)
 119  ConI  ===  0  [[ 120 ]]  #int:8
 117  MergeMem  === _  1  111  112  113  114  115  [[ 120 ]]  { N112:rawptr:BotPTR N113:java/lang/Object * N114:java/lang/Object+8 * [narrowklass] N115:double[int:>=0]:exact+any * }  Memory: @BotPTR *+bot, idx=Bot; !jvms: TestSkeletonPredicates::test1 @ bci:14 (line 63)
 110  Phi  ===  185  190  122  [[ 120 ]]  #abIO !jvms: TestSkeletonPredicates::test1 @ bci:14 (line 63)
 185  CountedLoop  ===  185  71  164  [[ 185  120  110  111  112  113  114  115  116 ]] inner stride: 1  !orig=[180],[109] !jvms: TestSkeletonPredicates::test1 @ bci:14 (line 63)
 24  ConI  ===  0  [[ 239  226 ]]  #int:10
 25  ConP  ===  0  [[ 239 ]]  #precise [double: :Constant:exact *  Klass:precise [double: :Constant:exact *
 244  IfFalse  ===  243  [[ 239 ]] #0 !orig=[203]
 121  Proj  ===  120  [[ 127 ]] #0 !jvms: TestSkeletonPredicates::test1 @ bci:19 (line 63)
 45  Proj  ===  239  [[ 48 ]] #0 !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 125  Proj  ===  120  [[ 149  140 ]] #5 !jvms: TestSkeletonPredicates::test1 @ bci:19 (line 63)
 116  Phi  ===  185  30  181  [[ 120  181  149  120 ]]  #int:>=0:www #tripcount !jvms: TestSkeletonPredicates::test1 @ bci:14 (line 63)
 11  Parm  ===  3  [[ 149  120  120  239 ]] Parm1: double[int:>=0]:exact * !jvms: TestSkeletonPredicates::test1 @ bci:-1 (line 60)
 10  Parm  ===  3  [[ 182  120  149  239  66 ]] Parm0: int !jvms: TestSkeletonPredicates::test1 @ bci:-1 (line 60)
 148  ConI  ===  0  [[ 149 ]]  #int:-187
 143  IfTrue  ===  142  [[ 149 ]] #1 !jvms: TestSkeletonPredicates::test1 @ bci:22 (line 63)
 198  LoadP  ===  5  7  194  [[ 199  206  209  212  215  219  221  221  225  225  232  232  191 ]]  @rawptr:BotPTR, idx=Raw; #rawptr:BotPTR (does not depend only on test)
 241  Proj  ===  239  [[ 191 ]] #5 !orig=[56] !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 234  MemBarStoreStore  ===  235  1  236  1  1  [[ 237  238 ]] 
 238  Proj  ===  234  [[ 170  171  172  173  112  113  114  115 ]] #2  Memory: @BotPTR *+bot, idx=Bot; !orig=[59],107 !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 216  PrefetchAllocation  === _  213  215  [[ 190 ]] 
 6  Parm  ===  3  [[ 207  190 ]] I_O !jvms: TestSkeletonPredicates::test1 @ bci:-1 (line 60)
 188  Region  ===  188  240  245  [[ 188  189  190  191  57 ]]  !orig=[49] !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 69  If  ===  237  68  [[ 70  71 ]] P=0.083352, C=13413.000000 !jvms: TestSkeletonPredicates::test1 @ bci:11 (line 62)
 184  CountedLoopEnd  ===  144  183  [[ 165  164 ]] [lt] P=0.916648, C=12295.000000 !orig=[163] !jvms: TestSkeletonPredicates::test1 @ bci:11 (line 62)
 54  Proj  ===  239  [[ 138  189 ]] #2  Memory: @BotPTR *+bot, idx=Bot; !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 123  Proj  ===  120  [[ 114  113  137  138  112  149  111  172  115  171  173  169  170 ]] #2  Memory: @BotPTR *+bot, idx=Bot; !jvms: TestSkeletonPredicates::test1 @ bci:19 (line 63)
 7  Parm  ===  3  [[ 137  239  169  60  111  197  198  217 ]] Memory  Memory: @BotPTR *+bot, idx=Bot; !orig=[103] !jvms: TestSkeletonPredicates::test1 @ bci:-1 (line 60)
 120  CallStaticJava  ===  185  110  117  8  1 ( 119  116  61  11  10  11  61  116 ) [[ 121  122  123  125 ]] # Static  compiler.c2.irTests.TestSkeletonPredicates::test1_helper bool ( int, int, double[int:>=0]:exact *, double[int:>=0]:exact * ) TestSkeletonPredicates::test1 @ bci:19 (line 63) !jvms: TestSkeletonPredicates::test1 @ bci:19 (line 63)
 239  CallStaticJava  ===  244  1  7  8  1 ( 25  24  10  11  1  1 ) [[ 241  55  54  45 ]] # Static _new_array_Java  rawptr:NotNull ( java/lang/Object:NotNull *, int ) C=0.000100 TestSkeletonPredicates::test1 @ bci:4 (line 61) !orig=44 !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 127  Catch  ===  121  122  [[ 128  129 ]]  !jvms: TestSkeletonPredicates::test1 @ bci:19 (line 63)
 48  Catch  ===  45  55  [[ 240  50 ]]  !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 149  CallStaticJava  ===  143  122  123  8  9 ( 148  10  11  61  116  125 ) [[ 150 ]] # Static uncommon_trap(reason='unstable_if' action='reinterpret' debug_id='0')  void ( int ) C=0.000100 TestSkeletonPredicates::test1 @ bci:22 (line 63) reexecute !jvms: TestSkeletonPredicates::test1 @ bci:22 (line 63)
 191  Phi  ===  188  241  198  [[ 61 ]]  #rawptr:BotPTR !orig=[56] !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 237  Proj  ===  234  [[ 61  69 ]] #0 !orig=[58] !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 173  Phi  ===  74  123  238  [[ 17 ]]  #memory  Memory: @double[int:>=0]:exact+any *, idx=6; !jvms: TestSkeletonPredicates::test1 @ bci:11 (line 62)
 172  Phi  ===  74  123  238  [[ 17 ]]  #memory  Memory: @java/lang/Object+8 * [narrowklass], idx=5; !jvms: TestSkeletonPredicates::test1 @ bci:11 (line 62)
 171  Phi  ===  74  123  238  [[ 17 ]]  #memory  Memory: @java/lang/Object *, idx=4; !jvms: TestSkeletonPredicates::test1 @ bci:11 (line 62)
 170  Phi  ===  74  123  238  [[ 17 ]]  #memory  Memory: @rawptr:BotPTR, idx=Raw; !jvms: TestSkeletonPredicates::test1 @ bci:11 (line 62)
 169  Phi  ===  74  123  7  [[ 17 ]]  #memory  Memory: @BotPTR *+bot, idx=Bot; !jvms: TestSkeletonPredicates::test1 @ bci:11 (line 62)
 190  Phi  ===  188  6  216  [[ 110  168 ]]  #abIO
 70  IfTrue  ===  69  [[ 74 ]] #1 !jvms: TestSkeletonPredicates::test1 @ bci:11 (line 62)
 165  IfFalse  ===  184  [[ 74 ]] #0 !jvms: TestSkeletonPredicates::test1 @ bci:11 (line 62)
 132  CreateEx  ===  129  122  [[ 139 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: TestSkeletonPredicates::test1 @ bci:19 (line 63)
 53  CreateEx  ===  50  55  [[ 139 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 3  Start  ===  3  0  [[ 3  5  6  7  8  9  10  11 ]]  #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:int, 6:double[int:>=0]:exact *}
 138  Phi  ===  135  54  123  [[ 51 ]]  #memory  Memory: @rawptr:BotPTR, idx=Raw; !jvms: TestSkeletonPredicates::test1 @ bci:19 (line 63)
 137  Phi  ===  135  7  123  [[ 51 ]]  #memory  Memory: @BotPTR *+bot, idx=Bot; !jvms: TestSkeletonPredicates::test1 @ bci:19 (line 63)
 122  Proj  ===  120  [[ 149  127  136  132  168  110 ]] #1 !jvms: TestSkeletonPredicates::test1 @ bci:19 (line 63)
 55  Proj  ===  239  [[ 48  53  136 ]] #1 !orig=102 !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 129  CatchProj  ===  127  [[ 135  132 ]] #1 at bci -1  !jvms: TestSkeletonPredicates::test1 @ bci:19 (line 63)
 50  CatchProj  ===  48  [[ 135  53 ]] #1 at bci -1  !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 150  Proj  ===  149  [[ 153 ]] #0 !jvms: TestSkeletonPredicates::test1 @ bci:22 (line 63)
 61  CheckCastPP  ===  237  191  [[ 178  120  120  149 ]]  #double[int:10]:NotNull:exact * !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 17  MergeMem  === _  1  169  170  171  172  173  [[ 178 ]]  { N170:rawptr:BotPTR N171:java/lang/Object * N172:java/lang/Object+8 * [narrowklass] N173:double[int:>=0]:exact+any * }  Memory: @BotPTR *+bot, idx=Bot;
 168  Phi  ===  74  122  190  [[ 178 ]]  #abIO !jvms: TestSkeletonPredicates::test1 @ bci:11 (line 62)
 74  Region  ===  74  165  70  [[ 74  178  168  169  170  171  172  173 ]]  !jvms: TestSkeletonPredicates::test1 @ bci:33 (line 67)
 139  Phi  ===  135  53  132  [[ 179 ]]  #java/lang/Throwable:NotNull *  Oop:java/lang/Throwable:NotNull * !jvms: TestSkeletonPredicates::test1 @ bci:19 (line 63)
 9  Parm  ===  3  [[ 179  178  149 ]] ReturnAdr !jvms: TestSkeletonPredicates::test1 @ bci:-1 (line 60)
 8  Parm  ===  3  [[ 179  178  149  120  239  153 ]] FramePtr !jvms: TestSkeletonPredicates::test1 @ bci:-1 (line 60)
 51  MergeMem  === _  1  137  138  [[ 179 ]]  { N138:rawptr:BotPTR }  Memory: @BotPTR *+bot, idx=Bot; !jvms: TestSkeletonPredicates::test1 @ bci:4 (line 61)
 136  Phi  ===  135  55  122  [[ 179 ]]  #abIO !jvms: TestSkeletonPredicates::test1 @ bci:19 (line 63)
 135  Region  ===  135  50  129  [[ 135  136  137  138  139  179 ]]  !jvms: TestSkeletonPredicates::test1 @ bci:19 (line 63)
 153  Halt  ===  150  1  1  8  1  [[ 0 ]]  !jvms: TestSkeletonPredicates::test1 @ bci:22 (line 63)
 178  Return  ===  74  168  17  8  9 returns 61  [[ 0 ]] 
 179  Rethrow  ===  135  136  51  8  9 exception 139  [[ 0 ]] 
 0  Root  ===  0  179  178  153  [[ 0  1  3  38  24  25  148  158  30  119  94  81  40  186  187  192  193  195  205  208  211  214  218  220  224  227  228  246  247  249  250 ]] 

[...]

1) Method "static double[] compiler.c2.irTests.TestSkeletonPredicates.test1(int,double[])" - [Failed IR rules: 1]:
   * @IR rule 1: "@compiler.lib.ir_framework.IR(applyIf={}, applyIfAnd={}, failOn={}, applyIfOr={}, counts={"(\\\\d+(\\\\s){2}(CountedLoop\\\\b.*)+(\\\\s){2}===.*)", "3"}, applyIfNot={})"
     - counts: Graph contains wrong number of nodes:
       * Regex 1: (\\d+(\\s){2}(CountedLoop\\b.*)+(\\s){2}===.*)
         - Failed comparison: [found] 1 = 3 [given]
         - Matched node:
           * 185  CountedLoop  ===  185  71  164  [[ 185  120  110  111  112  113  114  115  116 ]] inner stride: 1  !orig=[180],[109] !jvms: TestSkeletonPredicates::test1 @ bci:14 (line 63)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7758

From ihse at openjdk.java.net  Fri Mar 11 08:18:41 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 11 Mar 2022 08:18:41 GMT
Subject: RFR: 8282507: Add LICENSE file for hsdis
In-Reply-To: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
References: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
Message-ID: <YwatKCYd4ONuPuvPq8eQTV5nPm89zv1bhZ-FwlWRMbk=.03b1296f-6f22-4af1-93ea-86241a79c4d9@github.com>

On Tue, 1 Mar 2022 20:18:11 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone help review the addition of LICENSE file to hsdis directory?
> 
> -Man

As an engineer and not a lawyer, these are definitely muddy waters to me. I'm trying to get an understanding of the process, but I'm not used to navigating those parts of the organization. But from what I've found out so far, it do seem that if you insist on going through with this, we'd need to get legal approval. Which would be a ton of hassle for me. :( So I implore you to reconsider this PR.

And no, hsdis is not the only part of OpenJDK with another license than GPL+CE. The entire hotspot code base, and all tests, are licensed under GPL. But afaic the GPL, GPL+CE and UPL covers all code that is created by the OpenJDK project. This is not a legal guarantee, though, it's just my current understanding of the situation.

And thank you for pointing out src/java.desktop/share/native/libsplashscreen/libpng/LICENSE. I'll bring it up with our resident 3rd party license expert. :-)

With all that said, if you were to rename the file hsdis-license.txt, I would not have any objection. My sole concern here is that the name "LICENSE" sounds so broad that a lawyer, in the way that lawyers sometime do :), might be able to misinterpret this as applying to anything else than hsdis. With a clearer name, that worry disappears. So if you can accept that name instead, I don't have any more objections. The factual licensing of hsdis under UPL is not in dispute.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7649

From tschatzl at openjdk.java.net  Fri Mar 11 08:25:05 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 11 Mar 2022 08:25:05 GMT
Subject: RFR: 8283008: KRegister documentation out of date
Message-ID: <yOwEccFWgauV9iyfz0w5tkAvM-4CzsOaw1Yzxh8Snb0=.bfc3406a-1d82-4393-ac2d-4874761111d1@github.com>

Hi all,

  can I have reviews for this cleanup of `KRegister(Impl)` documentation, currently being a mix of copy&paste from `XMMRegister` and obsolete MMX support.

Testing: local compilation

Thanks,
  Thomas

-------------

Commit messages:
 - Initial change

Changes: https://git.openjdk.java.net/jdk/pull/7784/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7784&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283008
  Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7784.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7784/head:pull/7784

PR: https://git.openjdk.java.net/jdk/pull/7784

From pli at openjdk.java.net  Fri Mar 11 10:07:46 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Fri, 11 Mar 2022 10:07:46 GMT
Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v4]
In-Reply-To: <kCO5D2ohpcWMORQCit2EMYFL9R_U7hhrFrUTAiFvcz8=.a84f707c-76e6-460d-975d-86fa7b3e42e0@github.com>
References: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
 <DPPICoKR2tIZ8nbOaBDV2vFi7dp-lCjSnPbOc4ExeJc=.861804f6-b8fa-4d0d-9504-238ea0a89ccc@github.com>
 <kCO5D2ohpcWMORQCit2EMYFL9R_U7hhrFrUTAiFvcz8=.a84f707c-76e6-460d-975d-86fa7b3e42e0@github.com>
Message-ID: <M08Hl3raR6DP7ED-t3s5eHRfpyA4DBidrPcW5aC18q8=.2472414f-5219-4a8b-b0ec-f29061b52ca4@github.com>

On Thu, 10 Mar 2022 09:35:43 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Pengfei Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into postloop
>>    
>>    Change-Id: I503edb75f0f626569c776416bfef09651935979c
>>  - Update copyright year and rename a function
>>    
>>    Change-Id: I15845ebd3982edebd4c151284cc6f2ff727630bb
>>  - Merge branch 'master' into postloop
>>    
>>    Change-Id: Ie639c79c9cf016dc68ebf2c0031b60453b45e9a4
>>  - Fix issues in newly added test framework
>>    
>>    Change-Id: I6e61abf05e9665325cb3abaf407360b18355c6b1
>>  - Merge branch 'master' into postloop
>>    
>>    Change-Id: I9bb5a808d7540426dedb141fd198d25eb1f569e6
>>  - 8183390: Fix and re-enable post loop vectorization
>>    
>>    ** Background
>>    
>>    Post loop vectorization is a C2 compiler optimization in an experimental
>>    VM feature called PostLoopMultiversioning. It transforms the range-check
>>    eliminated post loop to a 1-iteration vectorized loop with vector mask.
>>    This optimization was contributed by Intel in 2016 to support x86 AVX512
>>    masked vector instructions. However, it was disabled soon after an issue
>>    was found. Due to insufficient maintenance in these years, multiple bugs
>>    have been accumulated inside. But we (Arm) still think this is a useful
>>    framework for vector mask support in C2 auto-vectorized loops, for both
>>    x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
>>    post loop vectorization.
>>    
>>    ** Changes in this patch
>>    
>>    This patch reworks post loop vectorization. The most significant change
>>    is removing vector mask support in C2 x86 backend and re-implementing
>>    it in the mid-end. With this, we can re-enable post loop vectorization
>>    for platforms other than x86.
>>    
>>    Previous implementation hard-codes x86 k1 register as a reserved AVX512
>>    opmask register and defines two routines (setvectmask/restorevectmask)
>>    to set and restore the value of k1. But after JDK-8211251 which encodes
>>    AVX512 instructions as unmasked by default, generated vector masks are
>>    no longer used in AVX512 vector instructions. To fix incorrect codegen
>>    and add vector mask support for more platforms, we turn to add a vector
>>    mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
>>    to generate a mask and replace all Load/Store nodes in the post loop
>>    into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
>>    IR form is exactly the same to those which are used in VectorAPI mask
>>    support. For now, we only add mask inputs for Load/Store nodes because
>>    we don't have reduction operations supported in post loop vectorization.
>>    After this change, the x86 k1 register is no longer reserved and can be
>>    allocated when PostLoopMultiversioning is enabled.
>>    
>>    Besides this change, we have fixed a compiler crash and five incorrect
>>    result issues with post loop vectorization.
>>    
>>    - 1) C2 crashes with segmentation fault in strip-mined loops
>>    
>>    Previous implementation was done before C2 loop strip-mining was merged
>>    into JDK master so it didn't take strip-mined loops into consideration.
>>    In C2's strip mined loops, post loop is not the sibling of the main loop
>>    in ideal loop tree. Instead, it's the sibling of the main loop's parent.
>>    This patch fixed a SIGSEGV issue caused by NULL pointer when locating
>>    post loop from strip-mined main loop.
>>    
>>    - 2) Incorrect result issues with post loop vectorization
>>    
>>    We have also fixed five incorrect vectorization issues. Some of them are
>>    hidden deep and can only be reproduced with corner cases. These issues
>>    have a common cause that it assumes the post loop can be vectorized if
>>    the vectorization in corresponding main loop is successful. But in many
>>    cases this assumption is wrong. Below are details.
>>    
>>    [Issue-1] Incorrect vectorization for partial vectorizable loops
>>    
>>    This issue can be reproduced by below loop where only some operations in
>>    the loop body are vectorizable.
>>    
>>      for (int i = 0; i < 10000; i++) {
>>        res[i] = a[i] * b[i];
>>        k = 3 * k + 1;
>>      }
>>    
>>    In the main loop, superword can work well if parts of the operations in
>>    loop body are not vectorizable since those parts can be unrolled only.
>>    But for post loops, we don't create vectors through combining scalar IRs
>>    generated from loop unrolling. Instead, we are doing scalars to vectors
>>    replacement for all operations in the loop body. Hence, all operations
>>    should be either vectorized together or not vectorized at all. To fix
>>    this kind of cases, we add an extra field "_slp_vector_pack_count" in
>>    CountedLoopNode to record the eventual count of vector packs in the main
>>    loop. This value is then passed to post loop and compared with post loop
>>    pack count. Vectorization will be bailed out in post loop if it creates
>>    more vector packs than in the main loop.
>>    
>>    [Issue-2] Incorrect result in loops with growing-down vectors
>>    
>>    This issue appears with growing-down vectors, that is, vectors that grow
>>    to smaller memory address as the loop iterates. It can be reproduced by
>>    below counting-up loop with negative scale value in array index.
>>    
>>      for (int i = 0; i < 10000; i++) {
>>        a[MAX - i] = b[MAX - i];
>>      }
>>    
>>    Cause of this issue is that for a growing-down vector, generated vector
>>    mask value has reversed vector-lane order so it masks incorrect vector
>>    lanes. Note that if negative scale value appears in counting-down loops,
>>    the vector will be growing up. With this rule, we fix the issue by only
>>    allowing positive array index scales in counting-up loops and negative
>>    array index scales in counting-down loops. This check is done with the
>>    help of SWPointer by comparing scale values in each memory access in the
>>    loop with loop stride value.
>>    
>>    [Issue-3] Incorrect result in manually unrolled loops
>>    
>>    This issue can be reproduced by below manually unrolled loop.
>>    
>>      for (int i = 0; i < 10000; i += 2) {
>>        c[i] = a[i] + b[i];
>>        c[i + 1] = a[i + 1] * b[i + 1];
>>      }
>>    
>>    In this loop, operations in the 2nd statement duplicate those in the 1st
>>    statement with a small memory address offset. Vectorization in the main
>>    loop works well in this case because C2 does further unrolling and pack
>>    combination. But we cannot vectorize the post loop through replacement
>>    from scalars to vectors because it creates duplicated vector operations.
>>    To fix this, we restrict post loop vectorization to loops with stride
>>    values of 1 or -1.
>>    
>>    [Issue-4] Incorrect result in loops with mixed vector element sizes
>>    
>>    This issue is found after we enable post loop vectorization for AArch64.
>>    It's reproducible by multiple array operations with different element
>>    sizes inside a loop. On x86, there is no issue because the values of x86
>>    AVX512 opmasks only depend on which vector lanes are active. But AArch64
>>    is different - the values of SVE predicates also depend on lane size of
>>    the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
>>    sizes, we should use different vector masks. For now, we just support
>>    loops with only one vector element size, i.e., "int + float" vectors in
>>    a single loop is ok but "int + double" vectors in a single loop is not
>>    vectorizable. This fix also enables subword vectors support to make all
>>    primitive type array operations vectorizable.
>>    
>>    [Issue-5] Incorrect result in loops with potential data dependence
>>    
>>    This issue can be reproduced by below corner case on AArch64 only.
>>    
>>      for (int i = 0; i < 10000; i++) {
>>        a[i] = x;
>>        a[i + OFFSET] = y;
>>      }
>>    
>>    In this case, two stores in the loop have data dependence if the OFFSET
>>    value is smaller than the vector length. So we cannot do vectorization
>>    through replacing scalars to vectors. But the main loop vectorization
>>    in this case is successful on AArch64 because AArch64 has partial vector
>>    load/store support. It splits vector fill with different values in lanes
>>    to several smaller-sized fills. In this patch, we add additional data
>>    dependence check for this kind of cases. The check is also done with the
>>    help of SWPointer class. In this check, we require that every two memory
>>    accesses (with at least one store) of the same element type (or subword
>>    size) in the loop has the same array index expression.
>>    
>>    ** Tests
>>    
>>    So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
>>    experimental VM option "PostLoopMultiversioning" turned on. We found no
>>    issue in all tests. We notice that those existing cases are not enough
>>    because some of above issues are not spotted by them. We would like to
>>    add some new cases but we found existing vectorization tests are a bit
>>    cumbersome - golden results must be pre-calculated and hard-coded in the
>>    test code for correctness verification. Thus, in this patch, we propose
>>    a new vectorization testing framework.
>>    
>>    Our new framework brings a simpler way to add new cases. For a new test
>>    case, we only need to create a new method annotated with "@Test". The
>>    test runner will invoke each annotated method twice automatically. First
>>    time it runs in the interpreter and second time it's forced compiled by
>>    C2. Then the two return results are compared. So in this framework each
>>    test method should return a primitive value or an array of primitives.
>>    In this way, no extra verification code for vectorization correctness is
>>    required. This test runner is still jtreg-based and takes advantages of
>>    the jtreg WhiteBox API, which enables test methods running at specific
>>    compilation levels. Each test class inside is also jtreg-based. It just
>>    need to inherit from the test runner class and run with two additional
>>    options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
>>    
>>    ** Summary & Future work
>>    
>>    In this patch, we reworked post loop vectorization. We made it platform
>>    independent and fixed several issues inside. We also implemented a new
>>    vectorization testing framework with many test cases inside. Meanwhile,
>>    we did some code cleanups.
>>    
>>    This patch only touches C2 code guarded with PostLoopMultiversioning,
>>    except a few data structure changes. So, there's no behavior change when
>>    experimental VM option PostLoopMultiversioning is off. Also, to reduce
>>    risks, we still propose to keep post loop vectorization experimental for
>>    now. But if it receives positive feedback, we would like to change it to
>>    non-experimental in the future.
>
> src/hotspot/share/opto/loopnode.cpp line 4443:
> 
>> 4441:         CountedLoopNode *cl = lpt->_head->as_CountedLoop();
>> 4442: 
>> 4443:         if (cl->is_rce_post_loop() && !cl->is_vectorized_loop()) {
> 
> Maybe assert that PostLoopMultiversioning is true?

Done in updated patch

-------------

PR: https://git.openjdk.java.net/jdk/pull/6828

From pli at openjdk.java.net  Fri Mar 11 10:15:46 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Fri, 11 Mar 2022 10:15:46 GMT
Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v4]
In-Reply-To: <kCO5D2ohpcWMORQCit2EMYFL9R_U7hhrFrUTAiFvcz8=.a84f707c-76e6-460d-975d-86fa7b3e42e0@github.com>
References: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
 <DPPICoKR2tIZ8nbOaBDV2vFi7dp-lCjSnPbOc4ExeJc=.861804f6-b8fa-4d0d-9504-238ea0a89ccc@github.com>
 <kCO5D2ohpcWMORQCit2EMYFL9R_U7hhrFrUTAiFvcz8=.a84f707c-76e6-460d-975d-86fa7b3e42e0@github.com>
Message-ID: <OaDemq67-M0nWHt9H3X8kgdZAyTYpI-dSJj6NxnsxWI=.bce9c234-3972-4202-9ea1-cc318f70f64e@github.com>

On Thu, 10 Mar 2022 09:35:59 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Pengfei Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into postloop
>>    
>>    Change-Id: I503edb75f0f626569c776416bfef09651935979c
>>  - Update copyright year and rename a function
>>    
>>    Change-Id: I15845ebd3982edebd4c151284cc6f2ff727630bb
>>  - Merge branch 'master' into postloop
>>    
>>    Change-Id: Ie639c79c9cf016dc68ebf2c0031b60453b45e9a4
>>  - Fix issues in newly added test framework
>>    
>>    Change-Id: I6e61abf05e9665325cb3abaf407360b18355c6b1
>>  - Merge branch 'master' into postloop
>>    
>>    Change-Id: I9bb5a808d7540426dedb141fd198d25eb1f569e6
>>  - 8183390: Fix and re-enable post loop vectorization
>>    
>>    ** Background
>>    
>>    Post loop vectorization is a C2 compiler optimization in an experimental
>>    VM feature called PostLoopMultiversioning. It transforms the range-check
>>    eliminated post loop to a 1-iteration vectorized loop with vector mask.
>>    This optimization was contributed by Intel in 2016 to support x86 AVX512
>>    masked vector instructions. However, it was disabled soon after an issue
>>    was found. Due to insufficient maintenance in these years, multiple bugs
>>    have been accumulated inside. But we (Arm) still think this is a useful
>>    framework for vector mask support in C2 auto-vectorized loops, for both
>>    x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
>>    post loop vectorization.
>>    
>>    ** Changes in this patch
>>    
>>    This patch reworks post loop vectorization. The most significant change
>>    is removing vector mask support in C2 x86 backend and re-implementing
>>    it in the mid-end. With this, we can re-enable post loop vectorization
>>    for platforms other than x86.
>>    
>>    Previous implementation hard-codes x86 k1 register as a reserved AVX512
>>    opmask register and defines two routines (setvectmask/restorevectmask)
>>    to set and restore the value of k1. But after JDK-8211251 which encodes
>>    AVX512 instructions as unmasked by default, generated vector masks are
>>    no longer used in AVX512 vector instructions. To fix incorrect codegen
>>    and add vector mask support for more platforms, we turn to add a vector
>>    mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
>>    to generate a mask and replace all Load/Store nodes in the post loop
>>    into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
>>    IR form is exactly the same to those which are used in VectorAPI mask
>>    support. For now, we only add mask inputs for Load/Store nodes because
>>    we don't have reduction operations supported in post loop vectorization.
>>    After this change, the x86 k1 register is no longer reserved and can be
>>    allocated when PostLoopMultiversioning is enabled.
>>    
>>    Besides this change, we have fixed a compiler crash and five incorrect
>>    result issues with post loop vectorization.
>>    
>>    - 1) C2 crashes with segmentation fault in strip-mined loops
>>    
>>    Previous implementation was done before C2 loop strip-mining was merged
>>    into JDK master so it didn't take strip-mined loops into consideration.
>>    In C2's strip mined loops, post loop is not the sibling of the main loop
>>    in ideal loop tree. Instead, it's the sibling of the main loop's parent.
>>    This patch fixed a SIGSEGV issue caused by NULL pointer when locating
>>    post loop from strip-mined main loop.
>>    
>>    - 2) Incorrect result issues with post loop vectorization
>>    
>>    We have also fixed five incorrect vectorization issues. Some of them are
>>    hidden deep and can only be reproduced with corner cases. These issues
>>    have a common cause that it assumes the post loop can be vectorized if
>>    the vectorization in corresponding main loop is successful. But in many
>>    cases this assumption is wrong. Below are details.
>>    
>>    [Issue-1] Incorrect vectorization for partial vectorizable loops
>>    
>>    This issue can be reproduced by below loop where only some operations in
>>    the loop body are vectorizable.
>>    
>>      for (int i = 0; i < 10000; i++) {
>>        res[i] = a[i] * b[i];
>>        k = 3 * k + 1;
>>      }
>>    
>>    In the main loop, superword can work well if parts of the operations in
>>    loop body are not vectorizable since those parts can be unrolled only.
>>    But for post loops, we don't create vectors through combining scalar IRs
>>    generated from loop unrolling. Instead, we are doing scalars to vectors
>>    replacement for all operations in the loop body. Hence, all operations
>>    should be either vectorized together or not vectorized at all. To fix
>>    this kind of cases, we add an extra field "_slp_vector_pack_count" in
>>    CountedLoopNode to record the eventual count of vector packs in the main
>>    loop. This value is then passed to post loop and compared with post loop
>>    pack count. Vectorization will be bailed out in post loop if it creates
>>    more vector packs than in the main loop.
>>    
>>    [Issue-2] Incorrect result in loops with growing-down vectors
>>    
>>    This issue appears with growing-down vectors, that is, vectors that grow
>>    to smaller memory address as the loop iterates. It can be reproduced by
>>    below counting-up loop with negative scale value in array index.
>>    
>>      for (int i = 0; i < 10000; i++) {
>>        a[MAX - i] = b[MAX - i];
>>      }
>>    
>>    Cause of this issue is that for a growing-down vector, generated vector
>>    mask value has reversed vector-lane order so it masks incorrect vector
>>    lanes. Note that if negative scale value appears in counting-down loops,
>>    the vector will be growing up. With this rule, we fix the issue by only
>>    allowing positive array index scales in counting-up loops and negative
>>    array index scales in counting-down loops. This check is done with the
>>    help of SWPointer by comparing scale values in each memory access in the
>>    loop with loop stride value.
>>    
>>    [Issue-3] Incorrect result in manually unrolled loops
>>    
>>    This issue can be reproduced by below manually unrolled loop.
>>    
>>      for (int i = 0; i < 10000; i += 2) {
>>        c[i] = a[i] + b[i];
>>        c[i + 1] = a[i + 1] * b[i + 1];
>>      }
>>    
>>    In this loop, operations in the 2nd statement duplicate those in the 1st
>>    statement with a small memory address offset. Vectorization in the main
>>    loop works well in this case because C2 does further unrolling and pack
>>    combination. But we cannot vectorize the post loop through replacement
>>    from scalars to vectors because it creates duplicated vector operations.
>>    To fix this, we restrict post loop vectorization to loops with stride
>>    values of 1 or -1.
>>    
>>    [Issue-4] Incorrect result in loops with mixed vector element sizes
>>    
>>    This issue is found after we enable post loop vectorization for AArch64.
>>    It's reproducible by multiple array operations with different element
>>    sizes inside a loop. On x86, there is no issue because the values of x86
>>    AVX512 opmasks only depend on which vector lanes are active. But AArch64
>>    is different - the values of SVE predicates also depend on lane size of
>>    the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
>>    sizes, we should use different vector masks. For now, we just support
>>    loops with only one vector element size, i.e., "int + float" vectors in
>>    a single loop is ok but "int + double" vectors in a single loop is not
>>    vectorizable. This fix also enables subword vectors support to make all
>>    primitive type array operations vectorizable.
>>    
>>    [Issue-5] Incorrect result in loops with potential data dependence
>>    
>>    This issue can be reproduced by below corner case on AArch64 only.
>>    
>>      for (int i = 0; i < 10000; i++) {
>>        a[i] = x;
>>        a[i + OFFSET] = y;
>>      }
>>    
>>    In this case, two stores in the loop have data dependence if the OFFSET
>>    value is smaller than the vector length. So we cannot do vectorization
>>    through replacing scalars to vectors. But the main loop vectorization
>>    in this case is successful on AArch64 because AArch64 has partial vector
>>    load/store support. It splits vector fill with different values in lanes
>>    to several smaller-sized fills. In this patch, we add additional data
>>    dependence check for this kind of cases. The check is also done with the
>>    help of SWPointer class. In this check, we require that every two memory
>>    accesses (with at least one store) of the same element type (or subword
>>    size) in the loop has the same array index expression.
>>    
>>    ** Tests
>>    
>>    So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
>>    experimental VM option "PostLoopMultiversioning" turned on. We found no
>>    issue in all tests. We notice that those existing cases are not enough
>>    because some of above issues are not spotted by them. We would like to
>>    add some new cases but we found existing vectorization tests are a bit
>>    cumbersome - golden results must be pre-calculated and hard-coded in the
>>    test code for correctness verification. Thus, in this patch, we propose
>>    a new vectorization testing framework.
>>    
>>    Our new framework brings a simpler way to add new cases. For a new test
>>    case, we only need to create a new method annotated with "@Test". The
>>    test runner will invoke each annotated method twice automatically. First
>>    time it runs in the interpreter and second time it's forced compiled by
>>    C2. Then the two return results are compared. So in this framework each
>>    test method should return a primitive value or an array of primitives.
>>    In this way, no extra verification code for vectorization correctness is
>>    required. This test runner is still jtreg-based and takes advantages of
>>    the jtreg WhiteBox API, which enables test methods running at specific
>>    compilation levels. Each test class inside is also jtreg-based. It just
>>    need to inherit from the test runner class and run with two additional
>>    options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
>>    
>>    ** Summary & Future work
>>    
>>    In this patch, we reworked post loop vectorization. We made it platform
>>    independent and fixed several issues inside. We also implemented a new
>>    vectorization testing framework with many test cases inside. Meanwhile,
>>    we did some code cleanups.
>>    
>>    This patch only touches C2 code guarded with PostLoopMultiversioning,
>>    except a few data structure changes. So, there's no behavior change when
>>    experimental VM option PostLoopMultiversioning is off. Also, to reduce
>>    risks, we still propose to keep post loop vectorization experimental for
>>    now. But if it receives positive feedback, we would like to change it to
>>    non-experimental in the future.
>
> src/hotspot/share/opto/superword.hpp line 616:
> 
>> 614: //------------------------------SWPointer---------------------------
>> 615: // Information about an address for dependence checking and vector alignment
>> 616: class SWPointer : public ResourceObj {
> 
> Why is this required?

In function `SuperWord::create_post_loop_vmask()`, SWPointer objects are allocated in arena with `new (_arena)` so the class should inherit from `ResourceObj`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6828

From pli at openjdk.java.net  Fri Mar 11 10:24:47 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Fri, 11 Mar 2022 10:24:47 GMT
Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v5]
In-Reply-To: <kCO5D2ohpcWMORQCit2EMYFL9R_U7hhrFrUTAiFvcz8=.a84f707c-76e6-460d-975d-86fa7b3e42e0@github.com>
References: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
 <DPPICoKR2tIZ8nbOaBDV2vFi7dp-lCjSnPbOc4ExeJc=.861804f6-b8fa-4d0d-9504-238ea0a89ccc@github.com>
 <kCO5D2ohpcWMORQCit2EMYFL9R_U7hhrFrUTAiFvcz8=.a84f707c-76e6-460d-975d-86fa7b3e42e0@github.com>
Message-ID: <9y78fy0fyxl5VebzI-dQghjLhN7l-CnT2TwZ2Plcwxs=.70324394-4a40-4a37-a080-fcf515a75c9f@github.com>

On Thu, 10 Mar 2022 09:37:15 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Pengfei Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
>> 
>>  - Add assertion of PostLoopMultiversioning
>>  - Merge branch 'master' into postloop
>>  - Merge branch 'master' into postloop
>>    
>>    Change-Id: I503edb75f0f626569c776416bfef09651935979c
>>  - Update copyright year and rename a function
>>    
>>    Change-Id: I15845ebd3982edebd4c151284cc6f2ff727630bb
>>  - Merge branch 'master' into postloop
>>    
>>    Change-Id: Ie639c79c9cf016dc68ebf2c0031b60453b45e9a4
>>  - Fix issues in newly added test framework
>>    
>>    Change-Id: I6e61abf05e9665325cb3abaf407360b18355c6b1
>>  - Merge branch 'master' into postloop
>>    
>>    Change-Id: I9bb5a808d7540426dedb141fd198d25eb1f569e6
>>  - 8183390: Fix and re-enable post loop vectorization
>>    
>>    ** Background
>>    
>>    Post loop vectorization is a C2 compiler optimization in an experimental
>>    VM feature called PostLoopMultiversioning. It transforms the range-check
>>    eliminated post loop to a 1-iteration vectorized loop with vector mask.
>>    This optimization was contributed by Intel in 2016 to support x86 AVX512
>>    masked vector instructions. However, it was disabled soon after an issue
>>    was found. Due to insufficient maintenance in these years, multiple bugs
>>    have been accumulated inside. But we (Arm) still think this is a useful
>>    framework for vector mask support in C2 auto-vectorized loops, for both
>>    x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
>>    post loop vectorization.
>>    
>>    ** Changes in this patch
>>    
>>    This patch reworks post loop vectorization. The most significant change
>>    is removing vector mask support in C2 x86 backend and re-implementing
>>    it in the mid-end. With this, we can re-enable post loop vectorization
>>    for platforms other than x86.
>>    
>>    Previous implementation hard-codes x86 k1 register as a reserved AVX512
>>    opmask register and defines two routines (setvectmask/restorevectmask)
>>    to set and restore the value of k1. But after JDK-8211251 which encodes
>>    AVX512 instructions as unmasked by default, generated vector masks are
>>    no longer used in AVX512 vector instructions. To fix incorrect codegen
>>    and add vector mask support for more platforms, we turn to add a vector
>>    mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
>>    to generate a mask and replace all Load/Store nodes in the post loop
>>    into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
>>    IR form is exactly the same to those which are used in VectorAPI mask
>>    support. For now, we only add mask inputs for Load/Store nodes because
>>    we don't have reduction operations supported in post loop vectorization.
>>    After this change, the x86 k1 register is no longer reserved and can be
>>    allocated when PostLoopMultiversioning is enabled.
>>    
>>    Besides this change, we have fixed a compiler crash and five incorrect
>>    result issues with post loop vectorization.
>>    
>>    - 1) C2 crashes with segmentation fault in strip-mined loops
>>    
>>    Previous implementation was done before C2 loop strip-mining was merged
>>    into JDK master so it didn't take strip-mined loops into consideration.
>>    In C2's strip mined loops, post loop is not the sibling of the main loop
>>    in ideal loop tree. Instead, it's the sibling of the main loop's parent.
>>    This patch fixed a SIGSEGV issue caused by NULL pointer when locating
>>    post loop from strip-mined main loop.
>>    
>>    - 2) Incorrect result issues with post loop vectorization
>>    
>>    We have also fixed five incorrect vectorization issues. Some of them are
>>    hidden deep and can only be reproduced with corner cases. These issues
>>    have a common cause that it assumes the post loop can be vectorized if
>>    the vectorization in corresponding main loop is successful. But in many
>>    cases this assumption is wrong. Below are details.
>>    
>>    [Issue-1] Incorrect vectorization for partial vectorizable loops
>>    
>>    This issue can be reproduced by below loop where only some operations in
>>    the loop body are vectorizable.
>>    
>>      for (int i = 0; i < 10000; i++) {
>>        res[i] = a[i] * b[i];
>>        k = 3 * k + 1;
>>      }
>>    
>>    In the main loop, superword can work well if parts of the operations in
>>    loop body are not vectorizable since those parts can be unrolled only.
>>    But for post loops, we don't create vectors through combining scalar IRs
>>    generated from loop unrolling. Instead, we are doing scalars to vectors
>>    replacement for all operations in the loop body. Hence, all operations
>>    should be either vectorized together or not vectorized at all. To fix
>>    this kind of cases, we add an extra field "_slp_vector_pack_count" in
>>    CountedLoopNode to record the eventual count of vector packs in the main
>>    loop. This value is then passed to post loop and compared with post loop
>>    pack count. Vectorization will be bailed out in post loop if it creates
>>    more vector packs than in the main loop.
>>    
>>    [Issue-2] Incorrect result in loops with growing-down vectors
>>    
>>    This issue appears with growing-down vectors, that is, vectors that grow
>>    to smaller memory address as the loop iterates. It can be reproduced by
>>    below counting-up loop with negative scale value in array index.
>>    
>>      for (int i = 0; i < 10000; i++) {
>>        a[MAX - i] = b[MAX - i];
>>      }
>>    
>>    Cause of this issue is that for a growing-down vector, generated vector
>>    mask value has reversed vector-lane order so it masks incorrect vector
>>    lanes. Note that if negative scale value appears in counting-down loops,
>>    the vector will be growing up. With this rule, we fix the issue by only
>>    allowing positive array index scales in counting-up loops and negative
>>    array index scales in counting-down loops. This check is done with the
>>    help of SWPointer by comparing scale values in each memory access in the
>>    loop with loop stride value.
>>    
>>    [Issue-3] Incorrect result in manually unrolled loops
>>    
>>    This issue can be reproduced by below manually unrolled loop.
>>    
>>      for (int i = 0; i < 10000; i += 2) {
>>        c[i] = a[i] + b[i];
>>        c[i + 1] = a[i + 1] * b[i + 1];
>>      }
>>    
>>    In this loop, operations in the 2nd statement duplicate those in the 1st
>>    statement with a small memory address offset. Vectorization in the main
>>    loop works well in this case because C2 does further unrolling and pack
>>    combination. But we cannot vectorize the post loop through replacement
>>    from scalars to vectors because it creates duplicated vector operations.
>>    To fix this, we restrict post loop vectorization to loops with stride
>>    values of 1 or -1.
>>    
>>    [Issue-4] Incorrect result in loops with mixed vector element sizes
>>    
>>    This issue is found after we enable post loop vectorization for AArch64.
>>    It's reproducible by multiple array operations with different element
>>    sizes inside a loop. On x86, there is no issue because the values of x86
>>    AVX512 opmasks only depend on which vector lanes are active. But AArch64
>>    is different - the values of SVE predicates also depend on lane size of
>>    the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
>>    sizes, we should use different vector masks. For now, we just support
>>    loops with only one vector element size, i.e., "int + float" vectors in
>>    a single loop is ok but "int + double" vectors in a single loop is not
>>    vectorizable. This fix also enables subword vectors support to make all
>>    primitive type array operations vectorizable.
>>    
>>    [Issue-5] Incorrect result in loops with potential data dependence
>>    
>>    This issue can be reproduced by below corner case on AArch64 only.
>>    
>>      for (int i = 0; i < 10000; i++) {
>>        a[i] = x;
>>        a[i + OFFSET] = y;
>>      }
>>    
>>    In this case, two stores in the loop have data dependence if the OFFSET
>>    value is smaller than the vector length. So we cannot do vectorization
>>    through replacing scalars to vectors. But the main loop vectorization
>>    in this case is successful on AArch64 because AArch64 has partial vector
>>    load/store support. It splits vector fill with different values in lanes
>>    to several smaller-sized fills. In this patch, we add additional data
>>    dependence check for this kind of cases. The check is also done with the
>>    help of SWPointer class. In this check, we require that every two memory
>>    accesses (with at least one store) of the same element type (or subword
>>    size) in the loop has the same array index expression.
>>    
>>    ** Tests
>>    
>>    So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
>>    experimental VM option "PostLoopMultiversioning" turned on. We found no
>>    issue in all tests. We notice that those existing cases are not enough
>>    because some of above issues are not spotted by them. We would like to
>>    add some new cases but we found existing vectorization tests are a bit
>>    cumbersome - golden results must be pre-calculated and hard-coded in the
>>    test code for correctness verification. Thus, in this patch, we propose
>>    a new vectorization testing framework.
>>    
>>    Our new framework brings a simpler way to add new cases. For a new test
>>    case, we only need to create a new method annotated with "@Test". The
>>    test runner will invoke each annotated method twice automatically. First
>>    time it runs in the interpreter and second time it's forced compiled by
>>    C2. Then the two return results are compared. So in this framework each
>>    test method should return a primitive value or an array of primitives.
>>    In this way, no extra verification code for vectorization correctness is
>>    required. This test runner is still jtreg-based and takes advantages of
>>    the jtreg WhiteBox API, which enables test methods running at specific
>>    compilation levels. Each test class inside is also jtreg-based. It just
>>    need to inherit from the test runner class and run with two additional
>>    options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
>>    
>>    ** Summary & Future work
>>    
>>    In this patch, we reworked post loop vectorization. We made it platform
>>    independent and fixed several issues inside. We also implemented a new
>>    vectorization testing framework with many test cases inside. Meanwhile,
>>    we did some code cleanups.
>>    
>>    This patch only touches C2 code guarded with PostLoopMultiversioning,
>>    except a few data structure changes. So, there's no behavior change when
>>    experimental VM option PostLoopMultiversioning is off. Also, to reduce
>>    risks, we still propose to keep post loop vectorization experimental for
>>    now. But if it receives positive feedback, we would like to change it to
>>    non-experimental in the future.
>
> src/hotspot/share/opto/superword.cpp line 114:
> 
>> 112:   if (post_loop_allowed) {
>> 113:     if (cl->is_reduction_loop()) return; // no predication mapping
>> 114:     Node *limit = cl->limit();
> 
> Why was this required but no longer is?

All the checks still exist. In this patch I unified the checks and put some of them together to reduce duplicated code. The multiversioned post loop checks everywhere are replaced by `is_rce_post_loop()`. Predicated vector check is moved to `IdealLoopTree::iteration_split_impl()` when inserting the multiversioned post loop, as I think there is no much value to do multiversioning if current architecture doesn't support vector masks. And the reduction loop check is still there in `SuperWord::transform_loop()`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6828

From eliu at openjdk.java.net  Fri Mar 11 10:47:00 2022
From: eliu at openjdk.java.net (Eric Liu)
Date: Fri, 11 Mar 2022 10:47:00 GMT
Subject: RFR: 8282926: AArch64: Optimize out WHILELO with PTRUE
Message-ID: <eiqjLHtDLFDiGzOv5r5soUA5j70X71nYhyCcJ5JgYrI=.2762d722-06d3-469f-811e-f10096278a6b@github.com>

This patch uses PTRUE instruction instead of WHILELO instruction to
create vector masks for certain length. It would be more efficient than
WHILELO instruction according to the software optimization guide of
Neoverse N2[1], Neoverse V1[2], and A64FX[3].

The final code changes as shown below:

Before:

    0x0000ffff6d4747b4:   orr     x8, xzr, #0x10
    0x0000ffff6d4747b8:   whilelo p0.b, xzr, x8

After:

    0x0000ffff89476aec:   ptrue   p0.b, vl16

The micro benchmark improves 15% ~ 20% in my SVE test system.

[TEST]
jdk/incubator/vector, hotspot/compiler/vectorapi passed on my SVE test
machine.

[1] https://developer.arm.com/documentation/PJDOC-466751330-18256/0001
[2] https://developer.arm.com/documentation/pjdoc466751330-9685/latest/
[3] https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_Microarchitecture_Manual_en_1.6.pdf

-------------

Commit messages:
 - 8282926: AArch64: Optimize out WHILELO with PTRUE

Changes: https://git.openjdk.java.net/jdk/pull/7786/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7786&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282926
  Stats: 174 lines in 3 files changed: 0 ins; 71 del; 103 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7786.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7786/head:pull/7786

PR: https://git.openjdk.java.net/jdk/pull/7786

From dlong at openjdk.java.net  Fri Mar 11 10:47:50 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 11 Mar 2022 10:47:50 GMT
Subject: RFR: 8283008: KRegister documentation out of date
In-Reply-To: <yOwEccFWgauV9iyfz0w5tkAvM-4CzsOaw1Yzxh8Snb0=.bfc3406a-1d82-4393-ac2d-4874761111d1@github.com>
References: <yOwEccFWgauV9iyfz0w5tkAvM-4CzsOaw1Yzxh8Snb0=.bfc3406a-1d82-4393-ac2d-4874761111d1@github.com>
Message-ID: <WzubPJdSIE_FLl2jNjbQdxj5anMn-Y7h_StBcnyIa7A=.a4599b57-43ae-4380-8067-c0b54e375042@github.com>

On Fri, 11 Mar 2022 08:17:07 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this cleanup of `KRegister(Impl)` documentation, currently being a mix of copy&paste from `XMMRegister` and obsolete MMX support.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

Looks good, and trivial.  Thanks for fixing this.

-------------

Marked as reviewed by dlong (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7784

From dlong at openjdk.java.net  Fri Mar 11 10:50:47 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 11 Mar 2022 10:50:47 GMT
Subject: RFR: 8279317:
 compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java assumes immutable
 code
In-Reply-To: <0p4QBsFdOEKPXTYliqwV4vhZ7e9uIv4V-853Q8U9kV0=.49b2d69e-14a1-4917-b899-02b3a7a7d504@github.com>
References: <0p4QBsFdOEKPXTYliqwV4vhZ7e9uIv4V-853Q8U9kV0=.49b2d69e-14a1-4917-b899-02b3a7a7d504@github.com>
Message-ID: <jZRGGb0Hsg7oSjjon6DeV52P9mVMgdVxdVPZaCSOeUw=.31956ed5-93cc-4541-8c65-cada35dd0c92@github.com>

On Fri, 11 Mar 2022 04:14:00 GMT, Dean Long <dlong at openjdk.org> wrote:

> This test was failing in loom because of nmethod entry barriers, but there are other reasons why it shouldn't assume immutable code, such as embedded oops and NativeJump::patch_verified_entry().

Got some test failures, putting back into Draft mode.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7781

From jiefu at openjdk.java.net  Fri Mar 11 12:02:45 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 11 Mar 2022 12:02:45 GMT
Subject: RFR: 8283008: KRegister documentation out of date
In-Reply-To: <yOwEccFWgauV9iyfz0w5tkAvM-4CzsOaw1Yzxh8Snb0=.bfc3406a-1d82-4393-ac2d-4874761111d1@github.com>
References: <yOwEccFWgauV9iyfz0w5tkAvM-4CzsOaw1Yzxh8Snb0=.bfc3406a-1d82-4393-ac2d-4874761111d1@github.com>
Message-ID: <xVgO4HX_Va2-1Ox45ip6BSLfGNIbSL3QlRPJCxkjF7Q=.2be9c0fe-8c9f-4c97-ab4a-89f653b0dc06@github.com>

On Fri, 11 Mar 2022 08:17:07 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this cleanup of `KRegister(Impl)` documentation, currently being a mix of copy&paste from `XMMRegister` and obsolete MMX support.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

Please also update the copyright year.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7784

From dnsimon at openjdk.java.net  Fri Mar 11 12:08:44 2022
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Fri, 11 Mar 2022 12:08:44 GMT
Subject: RFR: 8279317:
 compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java assumes immutable
 code
In-Reply-To: <0p4QBsFdOEKPXTYliqwV4vhZ7e9uIv4V-853Q8U9kV0=.49b2d69e-14a1-4917-b899-02b3a7a7d504@github.com>
References: <0p4QBsFdOEKPXTYliqwV4vhZ7e9uIv4V-853Q8U9kV0=.49b2d69e-14a1-4917-b899-02b3a7a7d504@github.com>
Message-ID: <MZhc_bJvuGwna7TTQzrkIb18jJSSjBLnlADuKBI8lAQ=.ece523fc-ff5c-4ee9-b7cd-104fe6c47ad3@github.com>

On Fri, 11 Mar 2022 04:14:00 GMT, Dean Long <dlong at openjdk.org> wrote:

> This test was failing in loom because of nmethod entry barriers, but there are other reasons why it shouldn't assume immutable code, such as embedded oops and NativeJump::patch_verified_entry().

Marked as reviewed by dnsimon (Committer).

I see now that it's probably unrealistic to expect compiled code to be immutable, even if said code is never executed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7781

From roland at openjdk.java.net  Fri Mar 11 12:08:49 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 11 Mar 2022 12:08:49 GMT
Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v5]
In-Reply-To: <ZZRxvB2oQrb51MCIxVaKVL3rqILOvZXwMasE04FO6Fc=.998b77e0-396a-4a32-a936-38ead882009f@github.com>
References: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
 <ZZRxvB2oQrb51MCIxVaKVL3rqILOvZXwMasE04FO6Fc=.998b77e0-396a-4a32-a936-38ead882009f@github.com>
Message-ID: <1SoIxCUdIYtHkAElb87zsSPULJsm56Wgij2ikm9ZjB4=.581dad35-41de-4327-9a79-4ea02c9f5121@github.com>

On Fri, 11 Mar 2022 07:48:06 GMT, Pengfei Li <pli at openjdk.org> wrote:

>> ### Background
>> 
>> Post loop vectorization is a C2 compiler optimization in an experimental
>> VM feature called PostLoopMultiversioning. It transforms the range-check
>> eliminated post loop to a 1-iteration vectorized loop with vector mask.
>> This optimization was contributed by Intel in 2016 to support x86 AVX512
>> masked vector instructions. However, it was disabled soon after an issue
>> was found. Due to insufficient maintenance in these years, multiple bugs
>> have been accumulated inside. But we (Arm) still think this is a useful
>> framework for vector mask support in C2 auto-vectorized loops, for both
>> x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
>> post loop vectorization.
>> 
>> ### Changes in this patch
>> 
>> This patch reworks post loop vectorization. The most significant change
>> is removing vector mask support in C2 x86 backend and re-implementing
>> it in the mid-end. With this, we can re-enable post loop vectorization
>> for platforms other than x86.
>> 
>> Previous implementation hard-codes x86 k1 register as a reserved AVX512
>> opmask register and defines two routines (setvectmask/restorevectmask)
>> to set and restore the value of k1. But after [JDK-8211251](https://bugs.openjdk.java.net/browse/JDK-8211251) which encodes
>> AVX512 instructions as unmasked by default, generated vector masks are
>> no longer used in AVX512 vector instructions. To fix incorrect codegen
>> and add vector mask support for more platforms, we turn to add a vector
>> mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
>> to generate a mask and replace all Load/Store nodes in the post loop
>> into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
>> IR form is exactly the same to those which are used in VectorAPI mask
>> support. For now, we only add mask inputs for Load/Store nodes because
>> we don't have reduction operations supported in post loop vectorization.
>> After this change, the x86 k1 register is no longer reserved and can be
>> allocated when PostLoopMultiversioning is enabled.
>> 
>> Besides this change, we have fixed a compiler crash and five incorrect
>> result issues with post loop vectorization.
>> 
>> **I) C2 crashes with segmentation fault in strip-mined loops**
>> 
>> Previous implementation was done before C2 loop strip-mining was merged
>> into JDK master so it didn't take strip-mined loops into consideration.
>> In C2's strip mined loops, post loop is not the sibling of the main loop
>> in ideal loop tree. Instead, it's the sibling of the main loop's parent.
>> This patch fixed a SIGSEGV issue caused by NULL pointer when locating
>> post loop from strip-mined main loop.
>> 
>> **II) Incorrect result issues with post loop vectorization**
>> 
>> We have also fixed five incorrect vectorization issues. Some of them are
>> hidden deep and can only be reproduced with corner cases. These issues
>> have a common cause that it assumes the post loop can be vectorized if
>> the vectorization in corresponding main loop is successful. But in many
>> cases this assumption is wrong. Below are details.
>> 
>> - **[Issue-1] Incorrect vectorization for partial vectorizable loops**
>> 
>> This issue can be reproduced by below loop where only some operations in
>> the loop body are vectorizable.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     res[i] = a[i] * b[i];
>>     k = 3 * k + 1;
>>   }
>> 
>> In the main loop, superword can work well if parts of the operations in
>> loop body are not vectorizable since those parts can be unrolled only.
>> But for post loops, we don't create vectors through combining scalar IRs
>> generated from loop unrolling. Instead, we are doing scalars to vectors
>> replacement for all operations in the loop body. Hence, all operations
>> should be either vectorized together or not vectorized at all. To fix
>> this kind of cases, we add an extra field "_slp_vector_pack_count" in
>> CountedLoopNode to record the eventual count of vector packs in the main
>> loop. This value is then passed to post loop and compared with post loop
>> pack count. Vectorization will be bailed out in post loop if it creates
>> more vector packs than in the main loop.
>> 
>> - **[Issue-2] Incorrect result in loops with growing-down vectors**
>> 
>> This issue appears with growing-down vectors, that is, vectors that grow
>> to smaller memory address as the loop iterates. It can be reproduced by
>> below counting-up loop with negative scale value in array index.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     a[MAX - i] = b[MAX - i];
>>   }
>> 
>> Cause of this issue is that for a growing-down vector, generated vector
>> mask value has reversed vector-lane order so it masks incorrect vector
>> lanes. Note that if negative scale value appears in counting-down loops,
>> the vector will be growing up. With this rule, we fix the issue by only
>> allowing positive array index scales in counting-up loops and negative
>> array index scales in counting-down loops. This check is done with the
>> help of SWPointer by comparing scale values in each memory access in the
>> loop with loop stride value.
>> 
>> - **[Issue-3] Incorrect result in manually unrolled loops**
>> 
>> This issue can be reproduced by below manually unrolled loop.
>> 
>>   for (int i = 0; i < 10000; i += 2) {
>>     c[i] = a[i] + b[i];
>>     c[i + 1] = a[i + 1] * b[i + 1];
>>   }
>> 
>> In this loop, operations in the 2nd statement duplicate those in the 1st
>> statement with a small memory address offset. Vectorization in the main
>> loop works well in this case because C2 does further unrolling and pack
>> combination. But we cannot vectorize the post loop through replacement
>> from scalars to vectors because it creates duplicated vector operations.
>> To fix this, we restrict post loop vectorization to loops with stride
>> values of 1 or -1.
>> 
>> - **[Issue-4] Incorrect result in loops with mixed vector element sizes**
>> 
>> This issue is found after we enable post loop vectorization for AArch64.
>> It's reproducible by multiple array operations with different element
>> sizes inside a loop. On x86, there is no issue because the values of x86
>> AVX512 opmasks only depend on which vector lanes are active. But AArch64
>> is different - the values of SVE predicates also depend on lane size of
>> the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
>> sizes, we should use different vector masks. For now, we just support
>> loops with only one vector element size, i.e., "int + float" vectors in
>> a single loop is ok but "int + double" vectors in a single loop is not
>> vectorizable. This fix also enables subword vectors support to make all
>> primitive type array operations vectorizable.
>> 
>> - **[Issue-5] Incorrect result in loops with potential data dependence**
>> 
>> This issue can be reproduced by below corner case on AArch64 only.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     a[i] = x;
>>     a[i + OFFSET] = y;
>>   }
>> 
>> In this case, two stores in the loop have data dependence if the OFFSET
>> value is smaller than the vector length. So we cannot do vectorization
>> through replacing scalars to vectors. But the main loop vectorization
>> in this case is successful on AArch64 because AArch64 has partial vector
>> load/store support. It splits vector fill with different values in lanes
>> to several smaller-sized fills. In this patch, we add additional data
>> dependence check for this kind of cases. The check is also done with the
>> help of SWPointer class. In this check, we require that every two memory
>> accesses (with at least one store) of the same element type (or subword
>> size) in the loop has the same array index expression.
>> 
>> ### Tests
>> 
>> So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
>> experimental VM option "PostLoopMultiversioning" turned on. We found no
>> issue in all tests. We notice that those existing cases are not enough
>> because some of above issues are not spotted by them. We would like to
>> add some new cases but we found existing vectorization tests are a bit
>> cumbersome - golden results must be pre-calculated and hard-coded in the
>> test code for correctness verification. Thus, in this patch, we propose
>> a new vectorization testing framework.
>> 
>> Our new framework brings a simpler way to add new cases. For a new test
>> case, we only need to create a new method annotated with "@Test". The
>> test runner will invoke each annotated method twice automatically. First
>> time it runs in the interpreter and second time it's forced compiled by
>> C2. Then the two return results are compared. So in this framework each
>> test method should return a primitive value or an array of primitives.
>> In this way, no extra verification code for vectorization correctness is
>> required. This test runner is still jtreg-based and takes advantages of
>> the jtreg WhiteBox API, which enables test methods running at specific
>> compilation levels. Each test class inside is also jtreg-based. It just
>> need to inherit from the test runner class and run with two additional
>> options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
>> 
>> ### Summary & Future work
>> 
>> In this patch, we reworked post loop vectorization. We made it platform
>> independent and fixed several issues inside. We also implemented a new
>> vectorization testing framework with many test cases inside. Meanwhile,
>> we did some code cleanups.
>> 
>> This patch only touches C2 code guarded with PostLoopMultiversioning,
>> except a few data structure changes. So, there's no behavior change when
>> experimental VM option PostLoopMultiversioning is off. Also, to reduce
>> risks, we still propose to keep post loop vectorization experimental for
>> now. But if it receives positive feedback, we would like to change it to
>> non-experimental in the future.
>
> Pengfei Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Add assertion of PostLoopMultiversioning
>  - Merge branch 'master' into postloop
>  - Merge branch 'master' into postloop
>    
>    Change-Id: I503edb75f0f626569c776416bfef09651935979c
>  - Update copyright year and rename a function
>    
>    Change-Id: I15845ebd3982edebd4c151284cc6f2ff727630bb
>  - Merge branch 'master' into postloop
>    
>    Change-Id: Ie639c79c9cf016dc68ebf2c0031b60453b45e9a4
>  - Fix issues in newly added test framework
>    
>    Change-Id: I6e61abf05e9665325cb3abaf407360b18355c6b1
>  - Merge branch 'master' into postloop
>    
>    Change-Id: I9bb5a808d7540426dedb141fd198d25eb1f569e6
>  - 8183390: Fix and re-enable post loop vectorization
>    
>    ** Background
>    
>    Post loop vectorization is a C2 compiler optimization in an experimental
>    VM feature called PostLoopMultiversioning. It transforms the range-check
>    eliminated post loop to a 1-iteration vectorized loop with vector mask.
>    This optimization was contributed by Intel in 2016 to support x86 AVX512
>    masked vector instructions. However, it was disabled soon after an issue
>    was found. Due to insufficient maintenance in these years, multiple bugs
>    have been accumulated inside. But we (Arm) still think this is a useful
>    framework for vector mask support in C2 auto-vectorized loops, for both
>    x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
>    post loop vectorization.
>    
>    ** Changes in this patch
>    
>    This patch reworks post loop vectorization. The most significant change
>    is removing vector mask support in C2 x86 backend and re-implementing
>    it in the mid-end. With this, we can re-enable post loop vectorization
>    for platforms other than x86.
>    
>    Previous implementation hard-codes x86 k1 register as a reserved AVX512
>    opmask register and defines two routines (setvectmask/restorevectmask)
>    to set and restore the value of k1. But after JDK-8211251 which encodes
>    AVX512 instructions as unmasked by default, generated vector masks are
>    no longer used in AVX512 vector instructions. To fix incorrect codegen
>    and add vector mask support for more platforms, we turn to add a vector
>    mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
>    to generate a mask and replace all Load/Store nodes in the post loop
>    into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
>    IR form is exactly the same to those which are used in VectorAPI mask
>    support. For now, we only add mask inputs for Load/Store nodes because
>    we don't have reduction operations supported in post loop vectorization.
>    After this change, the x86 k1 register is no longer reserved and can be
>    allocated when PostLoopMultiversioning is enabled.
>    
>    Besides this change, we have fixed a compiler crash and five incorrect
>    result issues with post loop vectorization.
>    
>    - 1) C2 crashes with segmentation fault in strip-mined loops
>    
>    Previous implementation was done before C2 loop strip-mining was merged
>    into JDK master so it didn't take strip-mined loops into consideration.
>    In C2's strip mined loops, post loop is not the sibling of the main loop
>    in ideal loop tree. Instead, it's the sibling of the main loop's parent.
>    This patch fixed a SIGSEGV issue caused by NULL pointer when locating
>    post loop from strip-mined main loop.
>    
>    - 2) Incorrect result issues with post loop vectorization
>    
>    We have also fixed five incorrect vectorization issues. Some of them are
>    hidden deep and can only be reproduced with corner cases. These issues
>    have a common cause that it assumes the post loop can be vectorized if
>    the vectorization in corresponding main loop is successful. But in many
>    cases this assumption is wrong. Below are details.
>    
>    [Issue-1] Incorrect vectorization for partial vectorizable loops
>    
>    This issue can be reproduced by below loop where only some operations in
>    the loop body are vectorizable.
>    
>      for (int i = 0; i < 10000; i++) {
>        res[i] = a[i] * b[i];
>        k = 3 * k + 1;
>      }
>    
>    In the main loop, superword can work well if parts of the operations in
>    loop body are not vectorizable since those parts can be unrolled only.
>    But for post loops, we don't create vectors through combining scalar IRs
>    generated from loop unrolling. Instead, we are doing scalars to vectors
>    replacement for all operations in the loop body. Hence, all operations
>    should be either vectorized together or not vectorized at all. To fix
>    this kind of cases, we add an extra field "_slp_vector_pack_count" in
>    CountedLoopNode to record the eventual count of vector packs in the main
>    loop. This value is then passed to post loop and compared with post loop
>    pack count. Vectorization will be bailed out in post loop if it creates
>    more vector packs than in the main loop.
>    
>    [Issue-2] Incorrect result in loops with growing-down vectors
>    
>    This issue appears with growing-down vectors, that is, vectors that grow
>    to smaller memory address as the loop iterates. It can be reproduced by
>    below counting-up loop with negative scale value in array index.
>    
>      for (int i = 0; i < 10000; i++) {
>        a[MAX - i] = b[MAX - i];
>      }
>    
>    Cause of this issue is that for a growing-down vector, generated vector
>    mask value has reversed vector-lane order so it masks incorrect vector
>    lanes. Note that if negative scale value appears in counting-down loops,
>    the vector will be growing up. With this rule, we fix the issue by only
>    allowing positive array index scales in counting-up loops and negative
>    array index scales in counting-down loops. This check is done with the
>    help of SWPointer by comparing scale values in each memory access in the
>    loop with loop stride value.
>    
>    [Issue-3] Incorrect result in manually unrolled loops
>    
>    This issue can be reproduced by below manually unrolled loop.
>    
>      for (int i = 0; i < 10000; i += 2) {
>        c[i] = a[i] + b[i];
>        c[i + 1] = a[i + 1] * b[i + 1];
>      }
>    
>    In this loop, operations in the 2nd statement duplicate those in the 1st
>    statement with a small memory address offset. Vectorization in the main
>    loop works well in this case because C2 does further unrolling and pack
>    combination. But we cannot vectorize the post loop through replacement
>    from scalars to vectors because it creates duplicated vector operations.
>    To fix this, we restrict post loop vectorization to loops with stride
>    values of 1 or -1.
>    
>    [Issue-4] Incorrect result in loops with mixed vector element sizes
>    
>    This issue is found after we enable post loop vectorization for AArch64.
>    It's reproducible by multiple array operations with different element
>    sizes inside a loop. On x86, there is no issue because the values of x86
>    AVX512 opmasks only depend on which vector lanes are active. But AArch64
>    is different - the values of SVE predicates also depend on lane size of
>    the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
>    sizes, we should use different vector masks. For now, we just support
>    loops with only one vector element size, i.e., "int + float" vectors in
>    a single loop is ok but "int + double" vectors in a single loop is not
>    vectorizable. This fix also enables subword vectors support to make all
>    primitive type array operations vectorizable.
>    
>    [Issue-5] Incorrect result in loops with potential data dependence
>    
>    This issue can be reproduced by below corner case on AArch64 only.
>    
>      for (int i = 0; i < 10000; i++) {
>        a[i] = x;
>        a[i + OFFSET] = y;
>      }
>    
>    In this case, two stores in the loop have data dependence if the OFFSET
>    value is smaller than the vector length. So we cannot do vectorization
>    through replacing scalars to vectors. But the main loop vectorization
>    in this case is successful on AArch64 because AArch64 has partial vector
>    load/store support. It splits vector fill with different values in lanes
>    to several smaller-sized fills. In this patch, we add additional data
>    dependence check for this kind of cases. The check is also done with the
>    help of SWPointer class. In this check, we require that every two memory
>    accesses (with at least one store) of the same element type (or subword
>    size) in the loop has the same array index expression.
>    
>    ** Tests
>    
>    So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
>    experimental VM option "PostLoopMultiversioning" turned on. We found no
>    issue in all tests. We notice that those existing cases are not enough
>    because some of above issues are not spotted by them. We would like to
>    add some new cases but we found existing vectorization tests are a bit
>    cumbersome - golden results must be pre-calculated and hard-coded in the
>    test code for correctness verification. Thus, in this patch, we propose
>    a new vectorization testing framework.
>    
>    Our new framework brings a simpler way to add new cases. For a new test
>    case, we only need to create a new method annotated with "@Test". The
>    test runner will invoke each annotated method twice automatically. First
>    time it runs in the interpreter and second time it's forced compiled by
>    C2. Then the two return results are compared. So in this framework each
>    test method should return a primitive value or an array of primitives.
>    In this way, no extra verification code for vectorization correctness is
>    required. This test runner is still jtreg-based and takes advantages of
>    the jtreg WhiteBox API, which enables test methods running at specific
>    compilation levels. Each test class inside is also jtreg-based. It just
>    need to inherit from the test runner class and run with two additional
>    options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
>    
>    ** Summary & Future work
>    
>    In this patch, we reworked post loop vectorization. We made it platform
>    independent and fixed several issues inside. We also implemented a new
>    vectorization testing framework with many test cases inside. Meanwhile,
>    we did some code cleanups.
>    
>    This patch only touches C2 code guarded with PostLoopMultiversioning,
>    except a few data structure changes. So, there's no behavior change when
>    experimental VM option PostLoopMultiversioning is off. Also, to reduce
>    risks, we still propose to keep post loop vectorization experimental for
>    now. But if it receives positive feedback, we would like to change it to
>    non-experimental in the future.

Looks reasonable to me.

-------------

Marked as reviewed by roland (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6828

From roland at openjdk.java.net  Fri Mar 11 12:08:49 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 11 Mar 2022 12:08:49 GMT
Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v4]
In-Reply-To: <iTklGXAiiq93HancC9EZFPvrqf0hdc8dC5y686NlSCc=.1f4cef48-05a0-4951-8ea3-597bedc9c991@github.com>
References: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
 <DPPICoKR2tIZ8nbOaBDV2vFi7dp-lCjSnPbOc4ExeJc=.861804f6-b8fa-4d0d-9504-238ea0a89ccc@github.com>
 <iTklGXAiiq93HancC9EZFPvrqf0hdc8dC5y686NlSCc=.1f4cef48-05a0-4951-8ea3-597bedc9c991@github.com>
Message-ID: <MC7c4Qja0eDoGc5caaAtb3UjPZmK9B6FUkprzKUhpnc=.879dca45-ed9d-481c-b2ca-1ce36f369279@github.com>

On Fri, 11 Mar 2022 02:31:08 GMT, Pengfei Li <pli at openjdk.org> wrote:

> > fairly similar. Doesn't/couldn't the logic from issue 5 protect from issue 3?
> 
> True, the SWPointer logic can also protect from issue 3. But I believe keeping loop stride check for issue 3 has no harm and post loop vectorization can bail out earlier with this additional check.

Maybe it's worth mentioning that in a comment next to that code in case someone finds the test too strict and wonder if it can be removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6828

From jbhateja at openjdk.java.net  Fri Mar 11 19:10:11 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 11 Mar 2022 19:10:11 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v9]
In-Reply-To: <7lwsCvdSjkvDYJNwuA7fVPrWFUbzchuwx0Z3IID5VZw=.0c00c3d7-2106-40df-88bc-38bf7e2655f9@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <zLyvngX3pdv0AhZamk10DX9bl1jSNJTo8uBYI0NMXJo=.ff366924-9e04-4f43-b539-fe7e991eefa1@github.com>
 <C8UrQ5i-1DBVeT7O3uFmyLkGTCmHLcRVkyupDPocqeg=.d7ecc45f-e9f2-4ab9-9d4f-8c084f0d1a6a@github.com>
 <HnLSn9vdNL5YBqaQXPS9QNzFF6CM37GzX1cF-HUVq7Y=.6e99b156-1b77-44e4-9b73-e7e389ab6ff8@github.com>
 <2jFjnftd7VluGsxgp8BK0vgHA68VrgGREj0fk7F6Dhk=.e40ddcaa-5a31-4115-976d-5f43e94b8ccf@github.com>
 <7lwsCvdSjkvDYJNwuA7fVPrWFUbzchuwx0Z3IID5VZw=.0c00c3d7-2106-40df-88bc-38bf7e2655f9@github.com>
Message-ID: <BV9C7ScbqGADSYLNPi2GWwhTi9kzNI1NJEjyX5d7mLM=.2463afe4-8d0b-41fd-8778-367164fff0ca@github.com>

On Thu, 10 Mar 2022 14:29:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Hi @jddarcy , 
>> 
>> Test has been modified on the same lines using generic options which manipulate compilation thresholds and agnostic to target platforms.
>> 
>>  * @run main/othervm -XX:Tier3CompileThreshold=100 -XX:CompileThresholdScaling=0.01 -XX:+TieredCompilation RoundTests
>> 
>> Verified that  RoundTests::test* methods gets compiled by c2.
>> Test execution time with and without change is almost same ~7.80sec over Skylake-server.
>> 
>> Regards
>
> To be more explicit, the existing RoundTests.java test runs in a fraction of a second.  The updated test runs many times slower, even if now under 10 second, at least on some platforms.
> 
> Can something closer to the original performance be restored?
> 
> As a tier 1 library test, these tests are run quite frequently.

Hi @jddarcy , 
Earlier none of the test methods in  RoundTests.java were compiled on account of low invocation count,  a loop with 2000 iterations under the influence controlled compilation threshold now triggers tier4 compilation of test points. I did several runs in Skylake machine with patch and without patch and could see no perceptible difference in runtime due to modification.

I have further reduced the invocation count and compile threshold.

Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From jbhateja at openjdk.java.net  Fri Mar 11 19:10:09 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 11 Mar 2022 19:10:09 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v14]
In-Reply-To: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
Message-ID: <Lb-EoZJHvv26gSOuRRmBTz57-6ZSBqL2a5tkyJWqHLc=.cf1fc559-36e2-4987-9991-4b595d73deed@github.com>

> Summary of changes:
> - Intrinsify Math.round(float) and Math.round(double) APIs.
> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
> - Test creation using new IR testing framework.
> 
> Following are the performance number of a JMH micro included with the patch 
> 
> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
> 
> 
> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
> -- | -- | -- | -- | -- | -- | -- | --
> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8279508: Reducing the invocation count and compile thresholds for RoundTests.java.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7094/files
  - new: https://git.openjdk.java.net/jdk/pull/7094/files/fcb73212..2519a58c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=12-13

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094

PR: https://git.openjdk.java.net/jdk/pull/7094

From tschatzl at openjdk.java.net  Fri Mar 11 21:05:30 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Fri, 11 Mar 2022 21:05:30 GMT
Subject: RFR: 8283008: KRegister documentation out of date [v2]
In-Reply-To: <yOwEccFWgauV9iyfz0w5tkAvM-4CzsOaw1Yzxh8Snb0=.bfc3406a-1d82-4393-ac2d-4874761111d1@github.com>
References: <yOwEccFWgauV9iyfz0w5tkAvM-4CzsOaw1Yzxh8Snb0=.bfc3406a-1d82-4393-ac2d-4874761111d1@github.com>
Message-ID: <bsGAsb5fkWLYfDo_LbDZCuxsL0awJT59ffPqHzRu-2s=.9f014adc-0bf7-4441-ae53-8f4bf5e231cb@github.com>

> Hi all,
> 
>   can I have reviews for this cleanup of `KRegister(Impl)` documentation, currently being a mix of copy&paste from `XMMRegister` and obsolete MMX support.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7784/files
  - new: https://git.openjdk.java.net/jdk/pull/7784/files/4ea657d2..1e4a8c95

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7784&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7784&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7784.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7784/head:pull/7784

PR: https://git.openjdk.java.net/jdk/pull/7784

From sviswanathan at openjdk.java.net  Fri Mar 11 21:19:37 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 11 Mar 2022 21:19:37 GMT
Subject: RFR: 8283008: KRegister documentation out of date [v2]
In-Reply-To: <bsGAsb5fkWLYfDo_LbDZCuxsL0awJT59ffPqHzRu-2s=.9f014adc-0bf7-4441-ae53-8f4bf5e231cb@github.com>
References: <yOwEccFWgauV9iyfz0w5tkAvM-4CzsOaw1Yzxh8Snb0=.bfc3406a-1d82-4393-ac2d-4874761111d1@github.com>
 <bsGAsb5fkWLYfDo_LbDZCuxsL0awJT59ffPqHzRu-2s=.9f014adc-0bf7-4441-ae53-8f4bf5e231cb@github.com>
Message-ID: <OF43mmZ8fD4c3d_CEwKUfRCL9sMmcWU2EQJ-yCu5qs8=.cf668b27-d81d-485e-bea9-e4f57bc1e85b@github.com>

On Fri, 11 Mar 2022 21:05:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this cleanup of `KRegister(Impl)` documentation, currently being a mix of copy&paste from `XMMRegister` and obsolete MMX support.
>> 
>> Testing: local compilation
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7784

From Divino.Cesar at microsoft.com  Fri Mar 11 21:26:15 2022
From: Divino.Cesar at microsoft.com (Cesar Soares Lucas)
Date: Fri, 11 Mar 2022 21:26:15 +0000
Subject: Questions about C2 IR verification
In-Reply-To: <c859ae5a-8e02-774b-602a-45e603103df8@oracle.com>
References: <BY5PR21MB147332CD770CEE03DE3C4BF49A0A9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <c859ae5a-8e02-774b-602a-45e603103df8@oracle.com>
Message-ID: <BY5PR21MB147377DFC6EC973E937293949A0C9@BY5PR21MB1473.namprd21.prod.outlook.com>

Hi Roberto,

Thank you for replying. I found the problem in the graph. The error message confused me a bit but at the end I found which ?use? wasn?t being dominated by a ?definition?.


Cheers,
Cesar

From: Roberto Casta?eda Lozano <roberto.castaneda.lozano at oracle.com>
Date: Wednesday, March 9, 2022 at 11:00 PM
To: Cesar Soares Lucas <Divino.Cesar at microsoft.com>, hotspot-compiler-dev at openjdk.java.net <hotspot-compiler-dev at openjdk.java.net>
Subject: Re: Questions about C2 IR verification
Hi Cesar,

On 2022-03-09 18:58, Cesar Soares Lucas wrote:
> Would you mind taking a quick look at the graph? I placed the IR printout, IR graphs and error message here: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcr.openjdk.java.net%2F~cslucas%2Fquestion0%2F&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7C8d49d19d3f7f49e0bed708da0263b19e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637824924455286741%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=PB8GdvAhE9W7YJVaKmrxcgQNIRwuV0riRLXXLnW7rWI%3D&amp;reserved=0.

Could you perhaps also upload the corresponding XML graph file as
emitted by -XX:PrintIdealGraphLevel=N -XX:PrintIdealGraphFile=FILE?

Thanks,

Roberto

From sviswanathan at openjdk.java.net  Fri Mar 11 21:49:56 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Fri, 11 Mar 2022 21:49:56 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v2]
In-Reply-To: <3JoM4khNMz85gwfyxZeBNxJCZ_B7826cc-iO4pHtTJM=.5b21a96e-b2f5-4093-a763-eec2b6d77a2e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <LQMZEAy-QU55kNt5fwFQSI8JPGuYz-nRWhuWVkKMt5c=.e5245c2f-c111-4c3d-829c-db44bca43e47@github.com>
 <AUfAFRB2Ki1dBUDYXNBQlF4FW0-HFotjDoKW3c6YzmQ=.59c5ce0b-482e-409b-944c-44afa409ea23@github.com>
 <3JoM4khNMz85gwfyxZeBNxJCZ_B7826cc-iO4pHtTJM=.5b21a96e-b2f5-4093-a763-eec2b6d77a2e@github.com>
Message-ID: <tI2SFzJCMp6T8jR9p2NyST_auGS0AleXsKrgjOTstVw=.af309906-d4d8-477f-8ba8-6fc1b11f1b94@github.com>

On Thu, 3 Mar 2022 05:42:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> The testing for this PR doesn't look adequate to me. I don't see any testing for the values where the behavior of round has been redefined at points in the last decade. See JDK-8010430 and JDK-6430675, both of which have regression tests in the core libs area. Thanks.
>
> Hi @jddarcy , can you kindly validate your feedback, it has been incorporated.

@jatin-bhateja There is a failure reported in the Pre-submit tests on Windows x64 for compiler/vectorization/TestRoundVect.java. Could you please take a look?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From dlong at openjdk.java.net  Fri Mar 11 22:52:21 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 11 Mar 2022 22:52:21 GMT
Subject: RFR: 8279317:
 compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java assumes immutable
 code [v2]
In-Reply-To: <0p4QBsFdOEKPXTYliqwV4vhZ7e9uIv4V-853Q8U9kV0=.49b2d69e-14a1-4917-b899-02b3a7a7d504@github.com>
References: <0p4QBsFdOEKPXTYliqwV4vhZ7e9uIv4V-853Q8U9kV0=.49b2d69e-14a1-4917-b899-02b3a7a7d504@github.com>
Message-ID: <v94W5TU7YUNMEpAxqHYNd5ULqK7TMJYrxOxk8t8UdXQ=.e2fc661d-9a31-48dd-a3a9-9ee75ef67fe2@github.com>

> This test was failing in loom because of nmethod entry barriers, but there are other reasons why it shouldn't assume immutable code, such as embedded oops and NativeJump::patch_verified_entry().

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  support both [Disassembly] and [MachCode] markers

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7781/files
  - new: https://git.openjdk.java.net/jdk/pull/7781/files/b62af58b..9b2f9014

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7781&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7781&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7781.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7781/head:pull/7781

PR: https://git.openjdk.java.net/jdk/pull/7781

From dlong at openjdk.java.net  Fri Mar 11 23:03:44 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 11 Mar 2022 23:03:44 GMT
Subject: RFR: 8279317:
 compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java assumes immutable
 code [v2]
In-Reply-To: <v94W5TU7YUNMEpAxqHYNd5ULqK7TMJYrxOxk8t8UdXQ=.e2fc661d-9a31-48dd-a3a9-9ee75ef67fe2@github.com>
References: <0p4QBsFdOEKPXTYliqwV4vhZ7e9uIv4V-853Q8U9kV0=.49b2d69e-14a1-4917-b899-02b3a7a7d504@github.com>
 <v94W5TU7YUNMEpAxqHYNd5ULqK7TMJYrxOxk8t8UdXQ=.e2fc661d-9a31-48dd-a3a9-9ee75ef67fe2@github.com>
Message-ID: <-E-_j2NOhqHmaXkj9R34mQpzuE_o2KZwxwIvo0-Tj9I=.e1f9961d-adbd-43b9-a980-bc3c834d4c32@github.com>

On Fri, 11 Mar 2022 22:52:21 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This test was failing in loom because of nmethod entry barriers, but there are other reasons why it shouldn't assume immutable code, such as embedded oops and NativeJump::patch_verified_entry().
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   support both [Disassembly] and [MachCode] markers

Test updated.  Rerunning tests.

Thanks Doug.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7781

From jiefu at openjdk.java.net  Fri Mar 11 23:04:51 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 11 Mar 2022 23:04:51 GMT
Subject: RFR: 8283008: KRegister documentation out of date [v2]
In-Reply-To: <bsGAsb5fkWLYfDo_LbDZCuxsL0awJT59ffPqHzRu-2s=.9f014adc-0bf7-4441-ae53-8f4bf5e231cb@github.com>
References: <yOwEccFWgauV9iyfz0w5tkAvM-4CzsOaw1Yzxh8Snb0=.bfc3406a-1d82-4393-ac2d-4874761111d1@github.com>
 <bsGAsb5fkWLYfDo_LbDZCuxsL0awJT59ffPqHzRu-2s=.9f014adc-0bf7-4441-ae53-8f4bf5e231cb@github.com>
Message-ID: <-C9Su_o7Hy3UaQ7g7GqC5zVEc87xGbL1r-3ttI6efYQ=.c79724db-5d9d-4e8c-8626-a8e97a6fe277@github.com>

On Fri, 11 Mar 2022 21:05:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this cleanup of `KRegister(Impl)` documentation, currently being a mix of copy&paste from `XMMRegister` and obsolete MMX support.
>> 
>> Testing: local compilation
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright

Marked as reviewed by jiefu (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7784

From duke at openjdk.java.net  Fri Mar 11 23:59:45 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Fri, 11 Mar 2022 23:59:45 GMT
Subject: RFR: 8281453: New optimization: convert "c-(~x)" into "x+(c+1)"
 and "~(c-x)" into "x+(-c-1)"
In-Reply-To: <JxLShkjYwqKV0ECiSmpz_R7Za5SNLRLvd6HNw-R0Fsk=.dad28be6-4cc5-4d1e-b51c-ed5d4a243c88@github.com>
References: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
 <JxLShkjYwqKV0ECiSmpz_R7Za5SNLRLvd6HNw-R0Fsk=.dad28be6-4cc5-4d1e-b51c-ed5d4a243c88@github.com>
Message-ID: <xzmtDP3K_f-rRrRyx2vK0JVnZE-rVXrVXsX5TdZkEv8=.fdc3c6ec-93d0-4e0c-9073-514911109791@github.com>

On Wed, 9 Feb 2022 16:12:30 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Since `~x == -1 - x` and these 2 operations' costs are essentially the same. It would be much easier if you just check whether the not result is used in an arithmetic operation and transform the former to the latter. The reverse is also true, if you find a `-1 - x` being fed into a bitwise just transform it to a `~x` then. Thanks.

Thank you for your comment. I am looking at this pending PR again. I drafted it for now until I get a rfr version.

While I am implementing your suggestion, I found another typical optimization that is missing, which is pushing constant to right from `x + (con - y)` to `(x - y) + con`. I created a separate PR for it, https://github.com/openjdk/jdk/pull/7795. Can you take a look at that one if you get a chance? Thank you!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7376

From sviswanathan at openjdk.java.net  Sat Mar 12 01:06:47 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 12 Mar 2022 01:06:47 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v10]
In-Reply-To: <cdQ7cLMPxxW0p-nK1DdHcQTrfouGC2kvXjSiDxHiMTw=.753e3892-e538-4890-a9f0-dd493d5fbf78@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <cdQ7cLMPxxW0p-nK1DdHcQTrfouGC2kvXjSiDxHiMTw=.753e3892-e538-4890-a9f0-dd493d5fbf78@github.com>
Message-ID: <n9NJlQ983a66g65L0PBa7EylUmRaw_co7UsHnaojjzU=.f0d31d0c-be9c-42ff-b248-1b7530181787@github.com>

On Fri, 4 Mar 2022 08:29:40 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unreached rules

src/hotspot/cpu/x86/assembler_x86.cpp line 2393:

> 2391:   InstructionMark im(this);
> 2392: #ifdef _LP64
> 2393:   emit_int8(0x67); // addr32

By removing the 0x67 prefix, we are now doing 64 bit computation even for 32 bit inputs. Wouldn't this cause partial register stalls (see section 3.5.2.4 end of section).

src/hotspot/cpu/x86/x86_64.ad line 7527:

> 7525:   predicate(VM_Version::supports_fast_2op_lea());
> 7526:   match(Set dst (AddI base (LShiftI index scale)));
> 7527:   match(Set dst (AddI (LShiftI index scale) base));

I think the commutativity is automatically handled by adlc.

src/hotspot/cpu/x86/x86_64.ad line 7699:

> 7697:   predicate(VM_Version::supports_fast_2op_lea());
> 7698:   match(Set dst (AddL base (LShiftL index scale)));
> 7699:   match(Set dst (AddL (LShiftL index scale) base));

commutativity is automatically handled by adlc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From sviswanathan at openjdk.java.net  Sat Mar 12 01:06:48 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 12 Mar 2022 01:06:48 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v5]
In-Reply-To: <bQqm-OVDKj7riwhp8W1bMNKKeZ5fmurESHENA5QQT6I=.f2ca086b-53ae-4a3a-b0be-30a804eac444@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <U5murwRIPLVjVFrBqWcUjQhF2pTXmeLKOSajrvd_ly4=.94307f88-dc5b-42aa-9410-01af01e114ef@github.com>
 <oy1Ecg-Q0lCrL0_VYvXJ8bWmrTK7q76_ukRKgRDMAdw=.88a14343-12e3-4506-b968-8911407a75fc@github.com>
 <Td0k0p6nfSuNy586YViYw7qACpR-P3ZtVC4frPcPprg=.8508a6a6-5cdd-4d89-a25b-483b63f816f8@github.com>
 <bQqm-OVDKj7riwhp8W1bMNKKeZ5fmurESHENA5QQT6I=.f2ca086b-53ae-4a3a-b0be-30a804eac444@github.com>
Message-ID: <mmbMFvac1B2gwHv9XHZJBPsKyElTrHojA-TOLPnbv3w=.0e33154e-6dfe-4da3-bb53-6b43c53ba0bd@github.com>

On Mon, 28 Feb 2022 15:01:06 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Icelakes introduce `clwb` instruction so I use that to filter Intel cpus.
>
>> Icelakes introduce `clwb` instruction so I use that to filter Intel cpus.
> 
> I'm not sure if we can find a better way (e.g., cpuid) to filter Intel CPUs.
> However, this seems fine since gcc and llvm will generate `lea` even without `clwb`.

supports_clwb() is true on the previous Cascade Lake architecture as well so it will be good to pick some other new Icelake feature to differentiate.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From sviswanathan at openjdk.java.net  Sat Mar 12 01:13:42 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Sat, 12 Mar 2022 01:13:42 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v10]
In-Reply-To: <cdQ7cLMPxxW0p-nK1DdHcQTrfouGC2kvXjSiDxHiMTw=.753e3892-e538-4890-a9f0-dd493d5fbf78@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <cdQ7cLMPxxW0p-nK1DdHcQTrfouGC2kvXjSiDxHiMTw=.753e3892-e538-4890-a9f0-dd493d5fbf78@github.com>
Message-ID: <eZ7llB0_a3s9huzs3jEzniiSMD_ZtA2zJUyi-i4zxa0=.84ad401e-f99f-42d4-9ee5-7b884f74c478@github.com>

On Fri, 4 Mar 2022 08:29:40 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unreached rules

src/hotspot/cpu/x86/vm_version_x86.hpp line 1062:

> 1060:   static bool supports_fast_3op_lea() {
> 1061:     return supports_fast_2op_lea() &&
> 1062:            ((is_intel() && supports_clwb()) || // Icelake and above

supports_clwb() is true on the previous Cascade Lake architecture as well so it will be good to pick some other new Icelake feature to differentiate.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Sat Mar 12 02:21:30 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sat, 12 Mar 2022 02:21:30 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v11]
In-Reply-To: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
Message-ID: <yPNo53YMU5roSilNMNro3Ea8TngXQ0BkPy3PbRecDJo=.260fbbdb-284a-4c65-a002-6ab08d874888@github.com>

> Hi,
> 
> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  reviews

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7560/files
  - new: https://git.openjdk.java.net/jdk/pull/7560/files/69a1afc9..669dea58

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=09-10

  Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7560/head:pull/7560

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Sat Mar 12 02:21:30 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sat, 12 Mar 2022 02:21:30 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v11]
In-Reply-To: <n9NJlQ983a66g65L0PBa7EylUmRaw_co7UsHnaojjzU=.f0d31d0c-be9c-42ff-b248-1b7530181787@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <cdQ7cLMPxxW0p-nK1DdHcQTrfouGC2kvXjSiDxHiMTw=.753e3892-e538-4890-a9f0-dd493d5fbf78@github.com>
 <n9NJlQ983a66g65L0PBa7EylUmRaw_co7UsHnaojjzU=.f0d31d0c-be9c-42ff-b248-1b7530181787@github.com>
Message-ID: <mUT5Bw0Q__Sd5MZmUqRg_YgxVrgkrmjLjPDapG97LXE=.f9830453-14b1-4ff1-a52c-9106875ec149@github.com>

On Sat, 12 Mar 2022 00:54:41 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reviews
>
> src/hotspot/cpu/x86/assembler_x86.cpp line 2393:
> 
>> 2391:   InstructionMark im(this);
>> 2392: #ifdef _LP64
>> 2393:   emit_int8(0x67); // addr32
> 
> By removing the 0x67 prefix, we are now doing 64 bit computation even for 32 bit inputs. Wouldn't this cause partial register stalls (see section 3.5.2.4 end of section).

Partial writes only happen with data size smaller than 32-bit since 32-bit writes are zero-extended to full register width. As a result, there should be no additional stalls here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Sat Mar 12 02:21:31 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sat, 12 Mar 2022 02:21:31 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v10]
In-Reply-To: <eZ7llB0_a3s9huzs3jEzniiSMD_ZtA2zJUyi-i4zxa0=.84ad401e-f99f-42d4-9ee5-7b884f74c478@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <cdQ7cLMPxxW0p-nK1DdHcQTrfouGC2kvXjSiDxHiMTw=.753e3892-e538-4890-a9f0-dd493d5fbf78@github.com>
 <eZ7llB0_a3s9huzs3jEzniiSMD_ZtA2zJUyi-i4zxa0=.84ad401e-f99f-42d4-9ee5-7b884f74c478@github.com>
Message-ID: <edvjYKh108t2IV42TzYPZzGYnYgXb7jHr2muRko419I=.d6b802f0-36ec-44fe-8a0b-86d14c79462c@github.com>

On Sat, 12 Mar 2022 01:10:33 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unreached rules
>
> src/hotspot/cpu/x86/vm_version_x86.hpp line 1062:
> 
>> 1060:   static bool supports_fast_3op_lea() {
>> 1061:     return supports_fast_2op_lea() &&
>> 1062:            ((is_intel() && supports_clwb()) || // Icelake and above
> 
> supports_clwb() is true on the previous Cascade Lake architecture as well so it will be good to pick some other new Icelake feature to differentiate.

I have fixed this, thank you very much.

> src/hotspot/cpu/x86/x86_64.ad line 7527:
> 
>> 7525:   predicate(VM_Version::supports_fast_2op_lea());
>> 7526:   match(Set dst (AddI base (LShiftI index scale)));
>> 7527:   match(Set dst (AddI (LShiftI index scale) base));
> 
> I think the commutativity is automatically handled by adlc.

Yes you are right, I have removed the unnecessaries.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From jiefu at openjdk.java.net  Sat Mar 12 02:31:42 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 12 Mar 2022 02:31:42 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v11]
In-Reply-To: <mUT5Bw0Q__Sd5MZmUqRg_YgxVrgkrmjLjPDapG97LXE=.f9830453-14b1-4ff1-a52c-9106875ec149@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <cdQ7cLMPxxW0p-nK1DdHcQTrfouGC2kvXjSiDxHiMTw=.753e3892-e538-4890-a9f0-dd493d5fbf78@github.com>
 <n9NJlQ983a66g65L0PBa7EylUmRaw_co7UsHnaojjzU=.f0d31d0c-be9c-42ff-b248-1b7530181787@github.com>
 <mUT5Bw0Q__Sd5MZmUqRg_YgxVrgkrmjLjPDapG97LXE=.f9830453-14b1-4ff1-a52c-9106875ec149@github.com>
Message-ID: <Bss8YuiObzB3TlIw-fxMUSNX9SO8-7uNcedl3BEixkc=.296d7c1b-a668-459f-9861-cc2365c31e76@github.com>

On Sat, 12 Mar 2022 02:17:40 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> src/hotspot/cpu/x86/assembler_x86.cpp line 2393:
>> 
>>> 2391:   InstructionMark im(this);
>>> 2392: #ifdef _LP64
>>> 2393:   emit_int8(0x67); // addr32
>> 
>> By removing the 0x67 prefix, we are now doing 64 bit computation even for 32 bit inputs. Wouldn't this cause partial register stalls (see section 3.5.2.4 end of section).
>
> Partial writes only happen with data size smaller than 32-bit since 32-bit writes are zero-extended to full register width. As a result, there should be no additional stalls here.

> By removing the 0x67 prefix, we are now doing 64 bit computation even for 32 bit inputs. Wouldn't this cause partial register stalls (see section 3.5.2.4 end of section).

I agree with @merykitty .
The manual mentions

Note that in Intel 64 architecture, an update to the lower 32 bits of a 64 bit integer register is architecturally defined to zero extend the upper 32 bits. While this action may be logically viewed as a 32 bit
update, it is really a 64 bit update (and therefore does not cause a partial stall).


TBH, I didn't know this opt rule before.
Thanks @sviswa7 for sharing this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From jbhateja at openjdk.java.net  Sat Mar 12 04:26:43 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sat, 12 Mar 2022 04:26:43 GMT
Subject: RFR: 8283008: KRegister documentation out of date [v2]
In-Reply-To: <bsGAsb5fkWLYfDo_LbDZCuxsL0awJT59ffPqHzRu-2s=.9f014adc-0bf7-4441-ae53-8f4bf5e231cb@github.com>
References: <yOwEccFWgauV9iyfz0w5tkAvM-4CzsOaw1Yzxh8Snb0=.bfc3406a-1d82-4393-ac2d-4874761111d1@github.com>
 <bsGAsb5fkWLYfDo_LbDZCuxsL0awJT59ffPqHzRu-2s=.9f014adc-0bf7-4441-ae53-8f4bf5e231cb@github.com>
Message-ID: <vOjcDhhvRetB--dx0N1ngN4GBHKVtA88_BDTkpte8MM=.db800a6c-410b-4d55-b7dc-62573e03d880@github.com>

On Fri, 11 Mar 2022 21:05:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this cleanup of `KRegister(Impl)` documentation, currently being a mix of copy&paste from `XMMRegister` and obsolete MMX support.
>> 
>> Testing: local compilation
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright

Marked as reviewed by jbhateja (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7784

From duke at openjdk.java.net  Sat Mar 12 04:52:41 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sat, 12 Mar 2022 04:52:41 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v12]
In-Reply-To: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
Message-ID: <ipzQF1uR_cuz1f7hI8RZ1HhokXaf6VGYGhx58h2VVQQ=.78863db8-b67f-4835-af92-e32c1a524353@github.com>

> Hi,
> 
> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
> 
> Thank you very much.

Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Merge branch 'master' into leaIns
 - reviews
 - remove unreached rules
 - remove 0x67 prefix
 - address reviews
 - remove irrelevent changes
 - reviews
 - address reviews
 - add benchmark
 - add predicate
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6b57a825...e0fd81f6

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7560/files
  - new: https://git.openjdk.java.net/jdk/pull/7560/files/669dea58..e0fd81f6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7560&range=10-11

  Stats: 32166 lines in 878 files changed: 21235 ins; 5960 del; 4971 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7560.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7560/head:pull/7560

PR: https://git.openjdk.java.net/jdk/pull/7560

From dlong at openjdk.java.net  Sat Mar 12 12:03:16 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Sat, 12 Mar 2022 12:03:16 GMT
Subject: RFR: 8279317:
 compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java assumes immutable
 code [v3]
In-Reply-To: <0p4QBsFdOEKPXTYliqwV4vhZ7e9uIv4V-853Q8U9kV0=.49b2d69e-14a1-4917-b899-02b3a7a7d504@github.com>
References: <0p4QBsFdOEKPXTYliqwV4vhZ7e9uIv4V-853Q8U9kV0=.49b2d69e-14a1-4917-b899-02b3a7a7d504@github.com>
Message-ID: <IG2zcgNdQPI1tFok-80Zu9QXyn4sv5UvUa_3DmuTnno=.19ca20d1-6688-4d01-9d24-a604170c909b@github.com>

> This test was failing in loom because of nmethod entry barriers, but there are other reasons why it shouldn't assume immutable code, such as embedded oops and NativeJump::patch_verified_entry().

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  fix Windows failures

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7781/files
  - new: https://git.openjdk.java.net/jdk/pull/7781/files/9b2f9014..c7a61fa4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7781&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7781&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7781.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7781/head:pull/7781

PR: https://git.openjdk.java.net/jdk/pull/7781

From jbhateja at openjdk.java.net  Sat Mar 12 19:58:37 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sat, 12 Mar 2022 19:58:37 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v15]
In-Reply-To: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
Message-ID: <Iv1sKvCahNhEMUynJAFeJBvI_i9Llg1IFGuMufxHKEU=.31394133-6f11-4cdd-92a3-2d387f948936@github.com>

> Summary of changes:
> - Intrinsify Math.round(float) and Math.round(double) APIs.
> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
> - Test creation using new IR testing framework.
> 
> Following are the performance number of a JMH micro included with the patch 
> 
> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
> 
> 
> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
> -- | -- | -- | -- | -- | -- | -- | --
> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8279508: Creating separate test for round double under feature check.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7094/files
  - new: https://git.openjdk.java.net/jdk/pull/7094/files/2519a58c..e4d4e29b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=13-14

  Stats: 239 lines in 3 files changed: 143 ins; 96 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094

PR: https://git.openjdk.java.net/jdk/pull/7094

From jiefu at openjdk.java.net  Sat Mar 12 23:44:43 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 12 Mar 2022 23:44:43 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity"
In-Reply-To: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
Message-ID: <F7UGMqAg4mdYkPMGCnnQy0dEoU6DQcOYsj9R_v9hMCE=.083f4b7d-1986-4188-b139-cf5bb965c608@github.com>

On Sat, 12 Mar 2022 23:28:43 GMT, Dean Long <dlong at openjdk.org> wrote:

> This change adds extra stub space for large values of CodeEntryAlignment, and it changes the test to try large values of CodeEntryAlignment.

test/hotspot/jtreg/compiler/arguments/TestCodeEntryAlignment.java line 69:

> 67: 
> 68:     public static void driver() throws IOException {
> 69:         for (int align = 32; align <= 1024; align *= 2) {

This wouldn't test for `-XX:CodeEntryAlignment=16`.
However, we used to find a bug with `-XX:CodeEntryAlignment=16`.
https://github.com/openjdk/jdk/pull/7485

Why not testing with `-XX:CodeEntryAlignment=16`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7800

From duke at openjdk.java.net  Sun Mar 13 00:10:46 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sun, 13 Mar 2022 00:10:46 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v15]
In-Reply-To: <Iv1sKvCahNhEMUynJAFeJBvI_i9Llg1IFGuMufxHKEU=.31394133-6f11-4cdd-92a3-2d387f948936@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <Iv1sKvCahNhEMUynJAFeJBvI_i9Llg1IFGuMufxHKEU=.31394133-6f11-4cdd-92a3-2d387f948936@github.com>
Message-ID: <DumsZCzq7RGmmWNBnTSHpNL91DbZ93sib12cl-0dhKs=.620444b6-4692-4614-a8cd-132f0d335115@github.com>

On Sat, 12 Mar 2022 19:58:37 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
>> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279508: Creating separate test for round double under feature check.

src/hotspot/cpu/x86/assembler_x86.hpp line 1159:

> 1157:   void cvttsd2siq(Register dst, Address src);
> 1158:   void cvttsd2siq(Register dst, XMMRegister src);
> 1159:   void cvtsd2siq(Register dst, XMMRegister src);

Hi, some small suggestions only, the instructions are sorted alphabetically so the `cvtsd2si` should come before `scttsd2si`, the same for the below instructions.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4024:

> 4022:  * the result is equal to the value of Integer.MAX_VALUE.
> 4023:  */
> 4024: void C2_MacroAssembler::vector_cast_float_special_cases_avx(XMMRegister dst, XMMRegister src, XMMRegister xtmp1,

This special handling is really large, could we use a stub routine for it?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4161:

> 4159:   movl(scratch, 1056964608);
> 4160:   movq(xtmp1, scratch);
> 4161:   vbroadcastss(xtmp1, xtmp1, vec_enc);

An `evpbroadcastd` would reduce this by one instruction I guess?

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4178:

> 4176:   movl(scratch, 1056964608);
> 4177:   movq(xtmp1, scratch);
> 4178:   vbroadcastss(xtmp1, xtmp1, vec_enc);

You could put the constant in the constant table and use `vbroadcastss` here also.

Thank you very much.

src/hotspot/cpu/x86/x86.ad line 7297:

> 7295:   ins_encode %{
> 7296:     int vlen_enc = vector_length_encoding(this);
> 7297:     InternalAddress new_mxcsr = $constantaddress(0x3F80L);

`ldmxcsr` takes a `m32` argument so this constant can be an `int` instead. Also, I would suggest putting the `mxcst_std` in the constant table also.

src/hotspot/cpu/x86/x86_64.ad line 10699:

> 10697:   match(Set dst (ConvD2L src));
> 10698:   effect(KILL cr);
> 10699:   format %{ "round_or_convert_d2l $dst,$src"%}

You could revert the changes for `ConvD2L` and `ConvF2I` here

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From duke at openjdk.java.net  Sun Mar 13 00:10:46 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sun, 13 Mar 2022 00:10:46 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v15]
In-Reply-To: <DumsZCzq7RGmmWNBnTSHpNL91DbZ93sib12cl-0dhKs=.620444b6-4692-4614-a8cd-132f0d335115@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <Iv1sKvCahNhEMUynJAFeJBvI_i9Llg1IFGuMufxHKEU=.31394133-6f11-4cdd-92a3-2d387f948936@github.com>
 <DumsZCzq7RGmmWNBnTSHpNL91DbZ93sib12cl-0dhKs=.620444b6-4692-4614-a8cd-132f0d335115@github.com>
Message-ID: <QuytGP23Sin4NeBZ3_vhCKAwxWWwUr-2xd7UCu4NuxU=.ad33766e-bd5c-4dec-b417-db7022decbb7@github.com>

On Sat, 12 Mar 2022 23:22:16 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8279508: Creating separate test for round double under feature check.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4161:
> 
>> 4159:   movl(scratch, 1056964608);
>> 4160:   movq(xtmp1, scratch);
>> 4161:   vbroadcastss(xtmp1, xtmp1, vec_enc);
> 
> An `evpbroadcastd` would reduce this by one instruction I guess?

Anyway an `evpbroadcastd xmm, r` has around 5 latency on the gpr so I think you could just put the constant in the constant table and use `vbroadcastsd`

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From dlong at openjdk.java.net  Sun Mar 13 03:19:45 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Sun, 13 Mar 2022 03:19:45 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity"
In-Reply-To: <F7UGMqAg4mdYkPMGCnnQy0dEoU6DQcOYsj9R_v9hMCE=.083f4b7d-1986-4188-b139-cf5bb965c608@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
 <F7UGMqAg4mdYkPMGCnnQy0dEoU6DQcOYsj9R_v9hMCE=.083f4b7d-1986-4188-b139-cf5bb965c608@github.com>
Message-ID: <Q-PitRTQwJxuZGiE8BtawdB_G3lhR7gOwn6iE6RPyc4=.57d7c0c8-1aae-463d-b6bc-ef58dc53e3f9@github.com>

On Sat, 12 Mar 2022 23:41:42 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> This change adds extra stub space for large values of CodeEntryAlignment, and it changes the test to try large values of CodeEntryAlignment.
>
> test/hotspot/jtreg/compiler/arguments/TestCodeEntryAlignment.java line 69:
> 
>> 67: 
>> 68:     public static void driver() throws IOException {
>> 69:         for (int align = 32; align <= 1024; align *= 2) {
> 
> This wouldn't test for `-XX:CodeEntryAlignment=16`.
> However, we used to find a bug with `-XX:CodeEntryAlignment=16`.
> https://github.com/openjdk/jdk/pull/7485
> 
> Why not testing with `-XX:CodeEntryAlignment=16`?

The only reason is because -XX:CodeCacheSegmentSize=16 gives an error.  If it's important to test for -XX:CodeEntryAlignment=16 then I'll have to rework the logic to be more clever.  I'll probably have to use WhiteBox APIs to read the default CodeCacheSegmentSize and only set it to values that are >= the default.  It's unfortunate that -XX:CodeEntryAlignment doesn't adjust the default value of CodeCacheSegmentSize automatically.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7800

From jbhateja at openjdk.java.net  Sun Mar 13 04:33:46 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 13 Mar 2022 04:33:46 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v15]
In-Reply-To: <DumsZCzq7RGmmWNBnTSHpNL91DbZ93sib12cl-0dhKs=.620444b6-4692-4614-a8cd-132f0d335115@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <Iv1sKvCahNhEMUynJAFeJBvI_i9Llg1IFGuMufxHKEU=.31394133-6f11-4cdd-92a3-2d387f948936@github.com>
 <DumsZCzq7RGmmWNBnTSHpNL91DbZ93sib12cl-0dhKs=.620444b6-4692-4614-a8cd-132f0d335115@github.com>
Message-ID: <ClrjytnyyLKM7-F3AJyWRsmfy5uQBmt6yia4yq8kk3g=.be46074b-0bf8-4b97-a7d4-fc2559b60d64@github.com>

On Sat, 12 Mar 2022 23:20:58 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8279508: Creating separate test for round double under feature check.
>
> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4024:
> 
>> 4022:  * the result is equal to the value of Integer.MAX_VALUE.
>> 4023:  */
>> 4024: void C2_MacroAssembler::vector_cast_float_special_cases_avx(XMMRegister dst, XMMRegister src, XMMRegister xtmp1,
> 
> This special handling is really large, could we use a stub routine for it?

Good suggestion, but as of now we are not using vector calling conventions for stubs.

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4178:
> 
>> 4176:   movl(scratch, 1056964608);
>> 4177:   movq(xtmp1, scratch);
>> 4178:   vbroadcastss(xtmp1, xtmp1, vec_enc);
> 
> You could put the constant in the constant table and use `vbroadcastss` here also.
> 
> Thank you very much.

constant and register to register moves are never issued to execution ports,  rematerializing value rather than reading from memory will give better performance.

> src/hotspot/cpu/x86/x86.ad line 7297:
> 
>> 7295:   ins_encode %{
>> 7296:     int vlen_enc = vector_length_encoding(this);
>> 7297:     InternalAddress new_mxcsr = $constantaddress(0x3F80L);
> 
> `ldmxcsr` takes a `m32` argument so this constant can be an `int` instead. Also, I would suggest putting the `mxcst_std` in the constant table also.

Correct, if we do so constant emitted will occupy 4 bytes.  

FTR we can also improve on the alignment padding for constants such that start address of next emitted constant aligned based on the constant size. This will be beneficial for large sized vector constants (32/64 byte) as we can save cache line split penalty during vector load.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From jbhateja at openjdk.java.net  Sun Mar 13 04:33:47 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 13 Mar 2022 04:33:47 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v15]
In-Reply-To: <QuytGP23Sin4NeBZ3_vhCKAwxWWwUr-2xd7UCu4NuxU=.ad33766e-bd5c-4dec-b417-db7022decbb7@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <Iv1sKvCahNhEMUynJAFeJBvI_i9Llg1IFGuMufxHKEU=.31394133-6f11-4cdd-92a3-2d387f948936@github.com>
 <DumsZCzq7RGmmWNBnTSHpNL91DbZ93sib12cl-0dhKs=.620444b6-4692-4614-a8cd-132f0d335115@github.com>
 <QuytGP23Sin4NeBZ3_vhCKAwxWWwUr-2xd7UCu4NuxU=.ad33766e-bd5c-4dec-b417-db7022decbb7@github.com>
Message-ID: <UXi0aQkMPb1TVG4SLBdxzqeXpFU5j3zJaBFWhjJXHXw=.66fb3cde-b57d-4cde-ada6-c0d93eddab00@github.com>

On Sun, 13 Mar 2022 00:06:07 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4161:
>> 
>>> 4159:   movl(scratch, 1056964608);
>>> 4160:   movq(xtmp1, scratch);
>>> 4161:   vbroadcastss(xtmp1, xtmp1, vec_enc);
>> 
>> An `evpbroadcastd` would reduce this by one instruction I guess?
>
> Anyway an `evpbroadcastd xmm, r` has around 5 latency on the gpr so I think you could just put the constant in the constant table and use `vbroadcastsd`

It was done to save redundant floating point to integer domain switch over penalties.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From jbhateja at openjdk.java.net  Sun Mar 13 04:46:21 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 13 Mar 2022 04:46:21 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v16]
In-Reply-To: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
Message-ID: <TN26g50zgYaTIea8sSzUPbjN4JSLOBWr-z8HTG16hwU=.2d74659c-1e41-4b21-917a-076f5df711de@github.com>

> Summary of changes:
> - Intrinsify Math.round(float) and Math.round(double) APIs.
> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
> - Test creation using new IR testing framework.
> 
> Following are the performance number of a JMH micro included with the patch 
> 
> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
> 
> 
> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
> -- | -- | -- | -- | -- | -- | -- | --
> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8279508: Styling comments resolved.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7094/files
  - new: https://git.openjdk.java.net/jdk/pull/7094/files/e4d4e29b..c881d11c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=14-15

  Stats: 11 lines in 3 files changed: 3 ins; 3 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094

PR: https://git.openjdk.java.net/jdk/pull/7094

From jbhateja at openjdk.java.net  Sun Mar 13 06:36:15 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Sun, 13 Mar 2022 06:36:15 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v17]
In-Reply-To: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
Message-ID: <zyFWnsymbgIL0sdxE9QXNWQ4lnoWrjd__As3bNUV88s=.ff7fefe5-59d6-4b1a-967f-e84bfc30d5ef@github.com>

> Summary of changes:
> - Intrinsify Math.round(float) and Math.round(double) APIs.
> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
> - Test creation using new IR testing framework.
> 
> Following are the performance number of a JMH micro included with the patch 
> 
> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
> 
> 
> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
> -- | -- | -- | -- | -- | -- | -- | --
> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  8279508: Windows build failure fix.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7094/files
  - new: https://git.openjdk.java.net/jdk/pull/7094/files/c881d11c..b1323a82

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=15-16

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094

PR: https://git.openjdk.java.net/jdk/pull/7094

From jiefu at openjdk.java.net  Sun Mar 13 07:15:42 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 13 Mar 2022 07:15:42 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity"
In-Reply-To: <Q-PitRTQwJxuZGiE8BtawdB_G3lhR7gOwn6iE6RPyc4=.57d7c0c8-1aae-463d-b6bc-ef58dc53e3f9@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
 <F7UGMqAg4mdYkPMGCnnQy0dEoU6DQcOYsj9R_v9hMCE=.083f4b7d-1986-4188-b139-cf5bb965c608@github.com>
 <Q-PitRTQwJxuZGiE8BtawdB_G3lhR7gOwn6iE6RPyc4=.57d7c0c8-1aae-463d-b6bc-ef58dc53e3f9@github.com>
Message-ID: <2cg-lvZcZd3ZEYaXtVuCA2bF2w6WXIdIDYGnPaZwEyA=.529b568b-e8c8-4271-ae4f-f761d16421eb@github.com>

On Sun, 13 Mar 2022 03:16:14 GMT, Dean Long <dlong at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/arguments/TestCodeEntryAlignment.java line 69:
>> 
>>> 67: 
>>> 68:     public static void driver() throws IOException {
>>> 69:         for (int align = 32; align <= 1024; align *= 2) {
>> 
>> This wouldn't test for `-XX:CodeEntryAlignment=16`.
>> However, we used to find a bug with `-XX:CodeEntryAlignment=16`.
>> https://github.com/openjdk/jdk/pull/7485
>> 
>> Why not testing with `-XX:CodeEntryAlignment=16`?
>
> The only reason is because -XX:CodeCacheSegmentSize=16 gives an error.  If it's important to test for -XX:CodeEntryAlignment=16 then I'll have to rework the logic to be more clever.  I'll probably have to use WhiteBox APIs to read the default CodeCacheSegmentSize and only set it to values that are >= the default.  It's unfortunate that -XX:CodeEntryAlignment doesn't adjust the default value of CodeCacheSegmentSize automatically.

Maybe we can add testing for `-XX:CodeEntryAlignment={512, 1024}` like this.

diff --git a/test/hotspot/jtreg/compiler/arguments/TestCodeEntryAlignment.java b/test/hotspot/jtreg/compiler/arguments/TestCodeEntryAlignment.java
index fd6c8ca..f07030e 100644
--- a/test/hotspot/jtreg/compiler/arguments/TestCodeEntryAlignment.java
+++ b/test/hotspot/jtreg/compiler/arguments/TestCodeEntryAlignment.java
@@ -72,6 +72,14 @@ public class TestCodeEntryAlignment {
                 "-XX:CodeEntryAlignment=" + align
             );
         }
+
+        for (int align = 512; align < 1024; align *= 2) {
+            shouldPass(
+                "-XX:+UnlockExperimentalVMOptions",
+                "-XX:CodeCacheSegmentSize=" + align,
+                "-XX:CodeEntryAlignment=" + align
+            );
+        }
     }
 
 }

What do you think?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7800

From duke at openjdk.java.net  Sun Mar 13 16:59:43 2022
From: duke at openjdk.java.net (hakib1)
Date: Sun, 13 Mar 2022 16:59:43 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity"
In-Reply-To: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
Message-ID: <-H86iYx9-94GUkEwMoVkznxVz1MzMUux_7EE5m9S4uE=.b57eb99d-0762-4f4b-9c84-77319e4ba06b@github.com>

On Sat, 12 Mar 2022 23:28:43 GMT, Dean Long <dlong at openjdk.org> wrote:

> This change adds extra stub space for large values of CodeEntryAlignment, and it changes the test to try large values of CodeEntryAlignment.

Marked as reviewed by hakib1 at github.com (no known OpenJDK username).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7800

From dlong at openjdk.java.net  Sun Mar 13 20:28:18 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Sun, 13 Mar 2022 20:28:18 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity" [v2]
In-Reply-To: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
Message-ID: <jo8ETqamI_NuREYJ7Fgf5szxNidIWX5-43SK0T6X4DY=.592ad8c0-3f48-4791-b488-3ed660b1e356@github.com>

> This change adds extra stub space for large values of CodeEntryAlignment, and it changes the test to try large values of CodeEntryAlignment.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  improvement based on review

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7800/files
  - new: https://git.openjdk.java.net/jdk/pull/7800/files/65fa6fda..e72382ef

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7800&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7800&range=00-01

  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7800.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7800/head:pull/7800

PR: https://git.openjdk.java.net/jdk/pull/7800

From dlong at openjdk.java.net  Sun Mar 13 20:28:20 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Sun, 13 Mar 2022 20:28:20 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity" [v2]
In-Reply-To: <2cg-lvZcZd3ZEYaXtVuCA2bF2w6WXIdIDYGnPaZwEyA=.529b568b-e8c8-4271-ae4f-f761d16421eb@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
 <F7UGMqAg4mdYkPMGCnnQy0dEoU6DQcOYsj9R_v9hMCE=.083f4b7d-1986-4188-b139-cf5bb965c608@github.com>
 <Q-PitRTQwJxuZGiE8BtawdB_G3lhR7gOwn6iE6RPyc4=.57d7c0c8-1aae-463d-b6bc-ef58dc53e3f9@github.com>
 <2cg-lvZcZd3ZEYaXtVuCA2bF2w6WXIdIDYGnPaZwEyA=.529b568b-e8c8-4271-ae4f-f761d16421eb@github.com>
Message-ID: <sQN6A6TXrin9QqGK9QesvJVwXOKBHeniXhLgPSDtpPI=.b6608944-2c7a-4e03-b81d-3ffd365d264e@github.com>

On Sun, 13 Mar 2022 07:12:57 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> The only reason is because -XX:CodeCacheSegmentSize=16 gives an error.  If it's important to test for -XX:CodeEntryAlignment=16 then I'll have to rework the logic to be more clever.  I'll probably have to use WhiteBox APIs to read the default CodeCacheSegmentSize and only set it to values that are >= the default.  It's unfortunate that -XX:CodeEntryAlignment doesn't adjust the default value of CodeCacheSegmentSize automatically.
>
> Maybe we can add testing for `-XX:CodeEntryAlignment={512, 1024}` like this.
> 
> diff --git a/test/hotspot/jtreg/compiler/arguments/TestCodeEntryAlignment.java b/test/hotspot/jtreg/compiler/arguments/TestCodeEntryAlignment.java
> index fd6c8ca..f07030e 100644
> --- a/test/hotspot/jtreg/compiler/arguments/TestCodeEntryAlignment.java
> +++ b/test/hotspot/jtreg/compiler/arguments/TestCodeEntryAlignment.java
> @@ -72,6 +72,14 @@ public class TestCodeEntryAlignment {
>                  "-XX:CodeEntryAlignment=" + align
>              );
>          }
> +
> +        for (int align = 512; align < 1024; align *= 2) {
> +            shouldPass(
> +                "-XX:+UnlockExperimentalVMOptions",
> +                "-XX:CodeCacheSegmentSize=" + align,
> +                "-XX:CodeEntryAlignment=" + align
> +            );
> +        }
>      }
>  
>  }
> 
> What do you think?

That sounds good.  Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7800

From jiefu at openjdk.java.net  Mon Mar 14 00:18:36 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 14 Mar 2022 00:18:36 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity" [v2]
In-Reply-To: <jo8ETqamI_NuREYJ7Fgf5szxNidIWX5-43SK0T6X4DY=.592ad8c0-3f48-4791-b488-3ed660b1e356@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
 <jo8ETqamI_NuREYJ7Fgf5szxNidIWX5-43SK0T6X4DY=.592ad8c0-3f48-4791-b488-3ed660b1e356@github.com>
Message-ID: <bB6RB3yM-YNyZ-rWSZ6G5zvXMaJGiQ34MvftQK0Ruww=.24dee710-8533-41d4-9b8b-12be6c83bf21@github.com>

On Sun, 13 Mar 2022 20:28:18 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This change adds extra stub space for large values of CodeEntryAlignment, and it changes the test to try large values of CodeEntryAlignment.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improvement based on review

src/hotspot/share/runtime/stubRoutines.cpp line 219:

> 217:     TraceTime timer("StubRoutines generation 1", TRACETIME_LOG(Info, startuptime));
> 218:     // Add extra space for large CodeEntryAlignment
> 219:     int max_stubs = 10;

Thanks for your update.

There are about 30 stubs (max number of stubs) to be generated in `generate_initial()` for x86_64.
Why not `max_stubs = 30` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7800

From njian at openjdk.java.net  Mon Mar 14 01:33:40 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Mon, 14 Mar 2022 01:33:40 GMT
Subject: RFR: 8282926: AArch64: Optimize out WHILELO with PTRUE
In-Reply-To: <eiqjLHtDLFDiGzOv5r5soUA5j70X71nYhyCcJ5JgYrI=.2762d722-06d3-469f-811e-f10096278a6b@github.com>
References: <eiqjLHtDLFDiGzOv5r5soUA5j70X71nYhyCcJ5JgYrI=.2762d722-06d3-469f-811e-f10096278a6b@github.com>
Message-ID: <XZWvegMKQx2l1j4xrgJySORCWgQjkTHeSst4DeeT0pY=.8ca2d52b-db58-48c0-9340-0fcb3123f104@github.com>

On Fri, 11 Mar 2022 10:40:00 GMT, Eric Liu <eliu at openjdk.org> wrote:

> This patch uses PTRUE instruction instead of WHILELO instruction to
> create vector masks for certain length. It would be more efficient than
> WHILELO instruction according to the software optimization guide of
> Neoverse N2[1], Neoverse V1[2], and A64FX[3].
> 
> The final code changes as shown below:
> 
> Before:
> 
>     0x0000ffff6d4747b4:   orr     x8, xzr, #0x10
>     0x0000ffff6d4747b8:   whilelo p0.b, xzr, x8
> 
> After:
> 
>     0x0000ffff89476aec:   ptrue   p0.b, vl16
> 
> The micro benchmark improves 15% ~ 20% in my SVE test system.
> 
> [TEST]
> jdk/incubator/vector, hotspot/compiler/vectorapi passed on my SVE test
> machine.
> 
> [1] https://developer.arm.com/documentation/PJDOC-466751330-18256/0001
> [2] https://developer.arm.com/documentation/pjdoc466751330-9685/latest/
> [3] https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_Microarchitecture_Manual_en_1.6.pdf

Looks good to me.

-------------

Marked as reviewed by njian (Committer).

PR: https://git.openjdk.java.net/jdk/pull/7786

From pli at openjdk.java.net  Mon Mar 14 01:45:40 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Mon, 14 Mar 2022 01:45:40 GMT
Subject: RFR: 8280510: AArch64: Vectorize operations with loop induction
 variable
In-Reply-To: <w_vldryKEmdOE2X3ksGAVlDHr9ijiS6SozKO7nUNwIM=.cd4f7874-b3be-4719-ba90-19234588a2aa@github.com>
References: <w_vldryKEmdOE2X3ksGAVlDHr9ijiS6SozKO7nUNwIM=.cd4f7874-b3be-4719-ba90-19234588a2aa@github.com>
Message-ID: <Q50JM19XUaIzR7j9kbHQjuw2WYIlJ001oj1fgcUxs_0=.88aef0c6-ac71-4663-a1fd-4c2b416a7c9f@github.com>

On Wed, 16 Feb 2022 08:26:14 GMT, Pengfei Li <pli at openjdk.org> wrote:

> AArch64 has SVE instruction of populating incrementing indices into an
> SVE vector register. With this we can vectorize some operations in loop
> with the induction variable operand, such as below.
> 
>   for (int i = 0; i < count; i++) {
>     b[i] = a[i] * i;
>   }
> 
> This patch enables the vectorization of operations with loop induction
> variable by extending current scope of C2 superword vectorizable packs.
> Before this patch, any scalar input node in a vectorizable pack must be
> an out-of-loop invariant. This patch takes the induction variable input
> as consideration. It allows the input to be the iv phi node or phi plus
> its index offset, and creates a `PopulateIndexNode` to generate a vector
> filled with incrementing indices. On AArch64 SVE, final generated code
> for above loop expression is like below.
> 
>   add     x12, x16, x10
>   add     x12, x12, #0x10
>   ld1w    {z16.s}, p7/z, [x12]
>   index   z17.s, w1, #1
>   mul     z17.s, p7/m, z17.s, z16.s
>   add     x10, x17, x10
>   add     x10, x10, #0x10
>   st1w    {z17.s}, p7, [x10]
> 
> As there is no populating index instruction on AArch64 NEON or other
> platforms like x86, a function named `is_populate_index_supported()` is
> created in the VectorNode class for the backend support check.
> 
> Jtreg hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1
> are tested and no issue is found. Hotspot jtreg has existing tests in
> `compiler/c2/cr7192963/Test*Vect.java` covering this kind of use cases so
> no new jtreg is created within this patch. A new JMH is created in this
> patch and tested on a 512-bit SVE machine. Below test result shows the
> performance can be significantly improved in some cases.
> 
>   Benchmark                       Performance
>   IndexVector.exprWithIndex1            ~7.7x
>   IndexVector.exprWithIndex2           ~13.3x
>   IndexVector.indexArrayFill            ~5.7x

Can anyone help review this? This optimization is currently for AArch64 but changes are mainly in C2 mid-end.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7491

From thartmann at openjdk.java.net  Mon Mar 14 06:06:38 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 14 Mar 2022 06:06:38 GMT
Subject: RFR: 8283056: show abstract machine code for all VM crashes
In-Reply-To: <yHSC3bjUUS--PwyQyUrZ8QW9iVcipFbuc3lDOyLCf2o=.cf7847fa-fd79-4705-82ec-324825a9fd25@github.com>
References: <kKS2Tk_nZOc6NXbUOuluZ6IGvrUrZY9IRh5tT7BSb70=.4ad088ee-ba8d-4ab6-9132-bae951036bba@github.com>
 <yHSC3bjUUS--PwyQyUrZ8QW9iVcipFbuc3lDOyLCf2o=.cf7847fa-fd79-4705-82ec-324825a9fd25@github.com>
Message-ID: <jIWzucRIDkTcO64uelotQb77Rtx1t_IQ72toaAzNjkc=.7ac11ba3-4595-4be8-8c4d-e5733ef01ab1@github.com>

On Sat, 12 Mar 2022 16:27:26 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> Suggestions on how to write an automatic test that can be part of this PR are welcome.

What about using `-XX:CICrashAt` and other flags that trigger asserts? You can have a look at `TestDwarf.java` in Christian's PR https://github.com/openjdk/jdk/pull/7126.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7791

From pli at openjdk.java.net  Mon Mar 14 06:13:30 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Mon, 14 Mar 2022 06:13:30 GMT
Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v6]
In-Reply-To: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
References: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
Message-ID: <4f4q-PLj6psH50mRQCVLAX8bMjzF4XWzAornt_t4PNE=.4331b19d-469b-4e0d-8a1f-d1eeb5aaf9ed@github.com>

> ### Background
> 
> Post loop vectorization is a C2 compiler optimization in an experimental
> VM feature called PostLoopMultiversioning. It transforms the range-check
> eliminated post loop to a 1-iteration vectorized loop with vector mask.
> This optimization was contributed by Intel in 2016 to support x86 AVX512
> masked vector instructions. However, it was disabled soon after an issue
> was found. Due to insufficient maintenance in these years, multiple bugs
> have been accumulated inside. But we (Arm) still think this is a useful
> framework for vector mask support in C2 auto-vectorized loops, for both
> x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
> post loop vectorization.
> 
> ### Changes in this patch
> 
> This patch reworks post loop vectorization. The most significant change
> is removing vector mask support in C2 x86 backend and re-implementing
> it in the mid-end. With this, we can re-enable post loop vectorization
> for platforms other than x86.
> 
> Previous implementation hard-codes x86 k1 register as a reserved AVX512
> opmask register and defines two routines (setvectmask/restorevectmask)
> to set and restore the value of k1. But after [JDK-8211251](https://bugs.openjdk.java.net/browse/JDK-8211251) which encodes
> AVX512 instructions as unmasked by default, generated vector masks are
> no longer used in AVX512 vector instructions. To fix incorrect codegen
> and add vector mask support for more platforms, we turn to add a vector
> mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
> to generate a mask and replace all Load/Store nodes in the post loop
> into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
> IR form is exactly the same to those which are used in VectorAPI mask
> support. For now, we only add mask inputs for Load/Store nodes because
> we don't have reduction operations supported in post loop vectorization.
> After this change, the x86 k1 register is no longer reserved and can be
> allocated when PostLoopMultiversioning is enabled.
> 
> Besides this change, we have fixed a compiler crash and five incorrect
> result issues with post loop vectorization.
> 
> **I) C2 crashes with segmentation fault in strip-mined loops**
> 
> Previous implementation was done before C2 loop strip-mining was merged
> into JDK master so it didn't take strip-mined loops into consideration.
> In C2's strip mined loops, post loop is not the sibling of the main loop
> in ideal loop tree. Instead, it's the sibling of the main loop's parent.
> This patch fixed a SIGSEGV issue caused by NULL pointer when locating
> post loop from strip-mined main loop.
> 
> **II) Incorrect result issues with post loop vectorization**
> 
> We have also fixed five incorrect vectorization issues. Some of them are
> hidden deep and can only be reproduced with corner cases. These issues
> have a common cause that it assumes the post loop can be vectorized if
> the vectorization in corresponding main loop is successful. But in many
> cases this assumption is wrong. Below are details.
> 
> - **[Issue-1] Incorrect vectorization for partial vectorizable loops**
> 
> This issue can be reproduced by below loop where only some operations in
> the loop body are vectorizable.
> 
>   for (int i = 0; i < 10000; i++) {
>     res[i] = a[i] * b[i];
>     k = 3 * k + 1;
>   }
> 
> In the main loop, superword can work well if parts of the operations in
> loop body are not vectorizable since those parts can be unrolled only.
> But for post loops, we don't create vectors through combining scalar IRs
> generated from loop unrolling. Instead, we are doing scalars to vectors
> replacement for all operations in the loop body. Hence, all operations
> should be either vectorized together or not vectorized at all. To fix
> this kind of cases, we add an extra field "_slp_vector_pack_count" in
> CountedLoopNode to record the eventual count of vector packs in the main
> loop. This value is then passed to post loop and compared with post loop
> pack count. Vectorization will be bailed out in post loop if it creates
> more vector packs than in the main loop.
> 
> - **[Issue-2] Incorrect result in loops with growing-down vectors**
> 
> This issue appears with growing-down vectors, that is, vectors that grow
> to smaller memory address as the loop iterates. It can be reproduced by
> below counting-up loop with negative scale value in array index.
> 
>   for (int i = 0; i < 10000; i++) {
>     a[MAX - i] = b[MAX - i];
>   }
> 
> Cause of this issue is that for a growing-down vector, generated vector
> mask value has reversed vector-lane order so it masks incorrect vector
> lanes. Note that if negative scale value appears in counting-down loops,
> the vector will be growing up. With this rule, we fix the issue by only
> allowing positive array index scales in counting-up loops and negative
> array index scales in counting-down loops. This check is done with the
> help of SWPointer by comparing scale values in each memory access in the
> loop with loop stride value.
> 
> - **[Issue-3] Incorrect result in manually unrolled loops**
> 
> This issue can be reproduced by below manually unrolled loop.
> 
>   for (int i = 0; i < 10000; i += 2) {
>     c[i] = a[i] + b[i];
>     c[i + 1] = a[i + 1] * b[i + 1];
>   }
> 
> In this loop, operations in the 2nd statement duplicate those in the 1st
> statement with a small memory address offset. Vectorization in the main
> loop works well in this case because C2 does further unrolling and pack
> combination. But we cannot vectorize the post loop through replacement
> from scalars to vectors because it creates duplicated vector operations.
> To fix this, we restrict post loop vectorization to loops with stride
> values of 1 or -1.
> 
> - **[Issue-4] Incorrect result in loops with mixed vector element sizes**
> 
> This issue is found after we enable post loop vectorization for AArch64.
> It's reproducible by multiple array operations with different element
> sizes inside a loop. On x86, there is no issue because the values of x86
> AVX512 opmasks only depend on which vector lanes are active. But AArch64
> is different - the values of SVE predicates also depend on lane size of
> the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
> sizes, we should use different vector masks. For now, we just support
> loops with only one vector element size, i.e., "int + float" vectors in
> a single loop is ok but "int + double" vectors in a single loop is not
> vectorizable. This fix also enables subword vectors support to make all
> primitive type array operations vectorizable.
> 
> - **[Issue-5] Incorrect result in loops with potential data dependence**
> 
> This issue can be reproduced by below corner case on AArch64 only.
> 
>   for (int i = 0; i < 10000; i++) {
>     a[i] = x;
>     a[i + OFFSET] = y;
>   }
> 
> In this case, two stores in the loop have data dependence if the OFFSET
> value is smaller than the vector length. So we cannot do vectorization
> through replacing scalars to vectors. But the main loop vectorization
> in this case is successful on AArch64 because AArch64 has partial vector
> load/store support. It splits vector fill with different values in lanes
> to several smaller-sized fills. In this patch, we add additional data
> dependence check for this kind of cases. The check is also done with the
> help of SWPointer class. In this check, we require that every two memory
> accesses (with at least one store) of the same element type (or subword
> size) in the loop has the same array index expression.
> 
> ### Tests
> 
> So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
> experimental VM option "PostLoopMultiversioning" turned on. We found no
> issue in all tests. We notice that those existing cases are not enough
> because some of above issues are not spotted by them. We would like to
> add some new cases but we found existing vectorization tests are a bit
> cumbersome - golden results must be pre-calculated and hard-coded in the
> test code for correctness verification. Thus, in this patch, we propose
> a new vectorization testing framework.
> 
> Our new framework brings a simpler way to add new cases. For a new test
> case, we only need to create a new method annotated with "@Test". The
> test runner will invoke each annotated method twice automatically. First
> time it runs in the interpreter and second time it's forced compiled by
> C2. Then the two return results are compared. So in this framework each
> test method should return a primitive value or an array of primitives.
> In this way, no extra verification code for vectorization correctness is
> required. This test runner is still jtreg-based and takes advantages of
> the jtreg WhiteBox API, which enables test methods running at specific
> compilation levels. Each test class inside is also jtreg-based. It just
> need to inherit from the test runner class and run with two additional
> options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
> 
> ### Summary & Future work
> 
> In this patch, we reworked post loop vectorization. We made it platform
> independent and fixed several issues inside. We also implemented a new
> vectorization testing framework with many test cases inside. Meanwhile,
> we did some code cleanups.
> 
> This patch only touches C2 code guarded with PostLoopMultiversioning,
> except a few data structure changes. So, there's no behavior change when
> experimental VM option PostLoopMultiversioning is off. Also, to reduce
> risks, we still propose to keep post loop vectorization experimental for
> now. But if it receives positive feedback, we would like to change it to
> non-experimental in the future.

Pengfei Li has updated the pull request incrementally with one additional commit since the last revision:

  Update a few comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/6828/files
  - new: https://git.openjdk.java.net/jdk/pull/6828/files/e150e056..4442e002

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6828&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6828&range=04-05

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/6828.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/6828/head:pull/6828

PR: https://git.openjdk.java.net/jdk/pull/6828

From thartmann at openjdk.java.net  Mon Mar 14 06:23:44 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 14 Mar 2022 06:23:44 GMT
Subject: RFR: 8281322: C2: always construct strip mined loop initially
 (even if strip mining is disabled) [v4]
In-Reply-To: <Eia1OglOOzTW2plgeEpnnSVvzR0R5ar2tTz8F3VYOnw=.6bf16fe5-694f-4a61-9300-1a661242db85@github.com>
References: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
 <Eia1OglOOzTW2plgeEpnnSVvzR0R5ar2tTz8F3VYOnw=.6bf16fe5-694f-4a61-9300-1a661242db85@github.com>
Message-ID: <VzK6lmsFKweDiG54qp-Rr2bnIkdtnibbh68GtZfOEKI=.2016ad57-9d2d-42d3-8734-2cc3ea7abc50@github.com>

On Mon, 7 Mar 2022 17:18:39 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Some of the long range check transformations take advantage of the
>> safepoint captured by loop strip mining to extract jvm state (in order
>> to add back empty predicates to the inner loop of a loop nest). As a
>> consequence, irTests/TestLongRangeChecks.java fails with strip mining
>> off and users might experience performance anomalies where changing
>> GCs affect purely computational code.
>> 
>> The strip mined loop nest creation is a 2 step process:
>> 
>> 1- when a CountedLoop is created, an OuterStripMinedLoop is also added
>>   but it's not fully constructed
>> 
>> 2- at macro expansion time, the OuterStripMinedLoop is turned into an
>>   actual loop by adding Phis and a proper exit condition
>> 
>> I propose always doing 1- whether loop strip mining is enabled or
>> not. This causes the safepoint to always be captured. Loop strip ming
>> is not expected to get in the way of loop transformations so this
>> change in itself should be performance neutral. Then at 2-, if loop
>> strip mining is not enabled, the OuterStripMinedLoop can be removed
>> and the safepoint moved back into the loop in case
>> LoopStripMiningIter=1 or simply removed too.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   build fix

This looks reasonable to me. All tests passed.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7364

From thartmann at openjdk.java.net  Mon Mar 14 06:43:43 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 14 Mar 2022 06:43:43 GMT
Subject: RFR: 8282414: x86: Enhance the assembler to generate more compact
 instructions [v4]
In-Reply-To: <ypcKly_jm9OQUYxLQGqMv4tc0Z4XDv3Ur5O3N1O4-nU=.f285822f-749b-4f59-9d19-446c0fa835bf@github.com>
References: <a1TTMEGFGtczuNoBlg3G7FruGyHBtxuS_euIoxGUzaE=.a4b51199-d869-4ed9-bda3-b28bfcd2b4e5@github.com>
 <ypcKly_jm9OQUYxLQGqMv4tc0Z4XDv3Ur5O3N1O4-nU=.f285822f-749b-4f59-9d19-446c0fa835bf@github.com>
Message-ID: <pLJu96ODyty3l5TYLOgu2AMQOZRxio2SDj9uus4s6JA=.7a4c18db-a231-4596-b859-704892d59163@github.com>

On Sat, 26 Feb 2022 07:44:28 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi, this patch enhances the x86 assembler to emit more compact code for some popular instructions.
>> 
>> For common arithmetic instructions against immediates, if the immediate requires more than 1 byte to encode, we can still shave off 1 byte if the register operand is rax.
>> 
>> For test instruction, since the operation does not write the result, we can downgrade a long to an int and an int to a byte instruction if the immediate is positive and encodable using a smaller amount of bytes.
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment

Looks reasonable to me and all tests pass. @sviswa7 could you have a look at this as well?

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7628

From thartmann at openjdk.java.net  Mon Mar 14 07:04:47 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 14 Mar 2022 07:04:47 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v8]
In-Reply-To: <vxDwpCRmu3HvXKL8NegsH_wBHLEkJzAFosN5WMyCx0g=.0a147a58-ebe3-42e7-b15e-22b7d6e45e4d@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <vxDwpCRmu3HvXKL8NegsH_wBHLEkJzAFosN5WMyCx0g=.0a147a58-ebe3-42e7-b15e-22b7d6e45e4d@github.com>
Message-ID: <5av6X1BvTQ_OcG9FfjwIi50Pgj-522wK_t-ipURWnBs=.0c2dfedf-6a8c-4cd3-b386-c0b4939eb6e5@github.com>

On Fri, 4 Mar 2022 20:27:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> 
>> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
>> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
>> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
>> 
>> 
>> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
>> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
>> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
>> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
>> 
>> Please review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8281375: Review comments resolved.

Looks good to me too.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7373

From pli at openjdk.java.net  Mon Mar 14 07:08:48 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Mon, 14 Mar 2022 07:08:48 GMT
Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v4]
In-Reply-To: <MC7c4Qja0eDoGc5caaAtb3UjPZmK9B6FUkprzKUhpnc=.879dca45-ed9d-481c-b2ca-1ce36f369279@github.com>
References: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
 <DPPICoKR2tIZ8nbOaBDV2vFi7dp-lCjSnPbOc4ExeJc=.861804f6-b8fa-4d0d-9504-238ea0a89ccc@github.com>
 <iTklGXAiiq93HancC9EZFPvrqf0hdc8dC5y686NlSCc=.1f4cef48-05a0-4951-8ea3-597bedc9c991@github.com>
 <MC7c4Qja0eDoGc5caaAtb3UjPZmK9B6FUkprzKUhpnc=.879dca45-ed9d-481c-b2ca-1ce36f369279@github.com>
Message-ID: <WOP9Lbb-z-P491uXH1rOCBJ4F64_Y7ZhCLZ0-Lz_KVA=.0869574f-900c-4580-9d24-21bc4540ebec@github.com>

On Fri, 11 Mar 2022 12:06:45 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Maybe it's worth mentioning that in a comment next to that code in case someone finds the test too strict and wonder if it can be removed.

The comment there is updated. Thanks for suggestion!

-------------

PR: https://git.openjdk.java.net/jdk/pull/6828

From jbhateja at openjdk.java.net  Mon Mar 14 07:11:48 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 14 Mar 2022 07:11:48 GMT
Subject: RFR: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target. [v8]
In-Reply-To: <5av6X1BvTQ_OcG9FfjwIi50Pgj-522wK_t-ipURWnBs=.0c2dfedf-6a8c-4cd3-b386-c0b4939eb6e5@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
 <vxDwpCRmu3HvXKL8NegsH_wBHLEkJzAFosN5WMyCx0g=.0a147a58-ebe3-42e7-b15e-22b7d6e45e4d@github.com>
 <5av6X1BvTQ_OcG9FfjwIi50Pgj-522wK_t-ipURWnBs=.0c2dfedf-6a8c-4cd3-b386-c0b4939eb6e5@github.com>
Message-ID: <VnWNREHBBnwJh_osHK4FLJV142vn6k4Ep0-cgfVYKNw=.db1dca70-ef04-4d1b-b267-40d2780cccdf@github.com>

On Mon, 14 Mar 2022 07:01:33 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8281375: Review comments resolved.
>
> Looks good to me too.

Thanks @TobiHartmann and @sviswa7.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From pli at openjdk.java.net  Mon Mar 14 07:12:51 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Mon, 14 Mar 2022 07:12:51 GMT
Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v4]
In-Reply-To: <kCO5D2ohpcWMORQCit2EMYFL9R_U7hhrFrUTAiFvcz8=.a84f707c-76e6-460d-975d-86fa7b3e42e0@github.com>
References: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
 <DPPICoKR2tIZ8nbOaBDV2vFi7dp-lCjSnPbOc4ExeJc=.861804f6-b8fa-4d0d-9504-238ea0a89ccc@github.com>
 <kCO5D2ohpcWMORQCit2EMYFL9R_U7hhrFrUTAiFvcz8=.a84f707c-76e6-460d-975d-86fa7b3e42e0@github.com>
Message-ID: <ra5NCsprKzgUHvZT8Hwi8pqbEN0JhbRi8GB_hppHBMk=.ea03046c-c328-4e99-ac87-3727a0793944@github.com>

On Thu, 10 Mar 2022 12:27:10 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Another review (ideally by someone familiar with the superword code) is required.

Can I have another review from Oracle? Perhaps @chhagedorn or @TobiHartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/6828

From jbhateja at openjdk.java.net  Mon Mar 14 07:14:49 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 14 Mar 2022 07:14:49 GMT
Subject: Integrated: 8281375: Accelerate bitCount operation for AVX2 and AVX512
 target.
In-Reply-To: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
References: <mby-uaUjK_CwtNPmPTY0d5WSfreSz25mCdcaT_P-_Hs=.0197891d-ff92-46a2-b17f-107063cfa471@github.com>
Message-ID: <0mRUW8pZVmHGfQSgN2VKWQDz0eKTBanFzEXsJ2QxNTM=.b49704b5-098c-41d5-bc16-7f2eae2cf486@github.com>

On Mon, 7 Feb 2022 20:08:35 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Summary of changes:
> 
> - Patch extends existing vectorized bitCount optimization added with [JDK-8278868](https://bugs.openjdk.java.net/browse/JDK-8278868) and emits optimized JIT sequence for AVX2 and other AVX512 targets which do not support avx512_vpopcntdq feature.
> - Since PopCountVI/PopCountVL node emit different instruction sequence based on the target features hence a rudimentary cost mode has been added which influences the SLP unrolling factor to prevent generating bloated main loops.
> - Following are the performance results of an existing [JMH micro](https://github.com/jatin-bhateja/jdk/blob/master/test/micro/org/openjdk/bench/vm/compiler/VectorBitCount.java) over various X86 targets.
> 
> 
> Benchmark | SIZE | Baseline AVX2 (ns/op) | Withopt AVX2 (ns/op) | Gain % | Baseline AVX3 (ns/op) | Withopt AVX3 (ns/op) | Gain % | Baseline AVX3 (VPOPCOUNTDQ) | Withopt AVX3 (VPOCOUNTDQ) | Gain %
> -- | -- | -- | -- | -- | -- | -- | -- | -- | -- | --
> VectorBitCount.WithSuperword.intBitCount | 1024 | 1089.799 | 420.156 | 159.3796114 | 1083.92 | 203.958 | 431.442748 | 88.958 | 60.096 | 48.02649095
> VectorBitCount.WithSuperword.longBitCount | 1024 | 417.458 | 413.859 | 0.869619846 | 417.203 | 214.949 | 94.09394787 | 105.954 | 117.019 | -9.455729411
> 
> Please review and share your feedback.
> 
> Best Regards,
> Jatin

This pull request has now been integrated.

Changeset: fde31498
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fde31498963d76630ada31bd0e0cf3035f87445b
Stats:     271 lines in 16 files changed: 259 ins; 3 del; 9 mod

8281375: Accelerate bitCount operation for AVX2 and AVX512 target.

Reviewed-by: sviswanathan, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7373

From fgao at openjdk.java.net  Mon Mar 14 08:25:10 2022
From: fgao at openjdk.java.net (Fei Gao)
Date: Mon, 14 Mar 2022 08:25:10 GMT
Subject: RFR: 8283091: Support type conversion between different data sizes in
 SLP
Message-ID: <4qFrtxwRHZfnzJbdVl2z7l6XENvxR3N8Sruc2fraKkw=.1391f639-1514-4e50-899a-d56cdd4afa99@github.com>

After JDK-8275317, C2's SLP vectorizer has supported type conversion between the same data size. We can also support conversions between different data sizes like:
int <-> double
float <-> long
int <-> long
float <-> double

A typical test case:

int[] a;
double[] b;
for (int i = start; i < limit; i++) {
    b[i] = (double) a[i];
}

Our expected OptoAssembly code for one iteration is like below:

add R12, R2, R11, LShiftL #2
vector_load   V16,[R12, #16]
vectorcast_i2d  V16, V16  # convert I to D vector
add R11, R1, R11, LShiftL #3	# ptr
add R13, R11, #16	# ptr
vector_store [R13], V16

To enable the vectorization, the patch solves the following problems in the SLP.

There are three main operations in the case above, LoadI, ConvI2D and StoreD. Assuming that the vector length is 128 bits, how many scalar nodes should be packed together to a vector? If we decide it separately for each operation node, like what we did before the patch in SuperWord::combine_packs(), a 128-bit vector will support 4 LoadI or 2 ConvI2D or 2 StoreD nodes. However, if we put these packed nodes in a vector node sequence, like loading 4 elements to a vector, then typecasting 2 elements and lastly storing these 2 elements, they become invalid. As a result, we should look through the whole def-use chain
and then pick up the minimum of these element sizes, like function SuperWord::max_vector_size_in_ud_chain() do in the superword.cpp. In this case, we pack 2 LoadI, 2 ConvI2D and 2 StoreD nodes, and then generate valid vector node sequence, like loading 2 elements, converting the 2 elements to another type and storing the 2 elements with new type.

After this, LoadI nodes don't make full use of the whole vector and only occupy part of it. So we adapt the code in SuperWord::get_vw_bytes_special() to the situation.

In SLP, we calculate a kind of alignment as position trace for each scalar node in the whole vector. In this case, the alignments for 2 LoadI nodes are 0, 4 while the alignment for 2 ConvI2D nodes are 0, 8. Sometimes, 4 for LoadI and 8 for ConvI2D work the same, both of which mark that this node is the second node in the whole vector, while the difference between 4 and 8 are just because of their own data sizes. In this situation, we should try to remove the impact caused by different data size in SLP. For example, in the stage of SuperWord::extend_packlist(), while determining if it's potential to pack a pair of def nodes in the function SuperWord::follow_use_defs(), we remove the side effect of different data size by transforming the target alignment from the use node. Because we believe that, assuming that the vector length is 512 bits, if the ConvI2D use nodes have alignments of 16-24 and their def nodes, LoadI, have alignments of 8-12, these two LoadI nodes should be packed as a
  pair as well.

Similarly, when determining if the vectorization is profitable, type conversion between different data size takes a type of one size and produces a type of another size, hence the special checks on alignment and size should be applied, like what we do in SuperWord::is_vector_use().

After solving these problems, we successfully implemented the vectorization of type conversion between different data sizes.

Here is the test data on NEON:

Before the patch:
Benchmark              (length)  Mode  Cnt    Score   Error  Units
  VectorLoop.convertD2F       523  avgt   15  216.431 ? 0.131  ns/op
  VectorLoop.convertD2I       523  avgt   15  220.522 ? 0.311  ns/op
  VectorLoop.convertF2D       523  avgt   15  217.034 ? 0.292  ns/op
  VectorLoop.convertF2L       523  avgt   15  231.634 ? 1.881  ns/op
  VectorLoop.convertI2D       523  avgt   15  229.538 ? 0.095  ns/op
  VectorLoop.convertI2L       523  avgt   15  214.822 ? 0.131  ns/op
  VectorLoop.convertL2F       523  avgt   15  230.188 ? 0.217  ns/op
  VectorLoop.convertL2I       523  avgt   15  162.234 ? 0.235  ns/op

After the patch:
Benchmark              (length)  Mode  Cnt    Score    Error  Units
  VectorLoop.convertD2F       523  avgt   15  124.352 ?  1.079  ns/op
  VectorLoop.convertD2I       523  avgt   15  557.388 ?  8.166  ns/op
  VectorLoop.convertF2D       523  avgt   15  118.082 ?  4.026  ns/op
  VectorLoop.convertF2L       523  avgt   15  225.810 ? 11.180  ns/op
  VectorLoop.convertI2D       523  avgt   15  166.247 ?  0.120  ns/op
  VectorLoop.convertI2L       523  avgt   15  119.699 ?  2.925  ns/op
  VectorLoop.convertL2F       523  avgt   15  220.847 ?  0.053  ns/op
  VectorLoop.convertL2I       523  avgt   15  122.339 ?  2.738  ns/op

perf data on X86:
Before the patch:
Benchmark              (length)  Mode  Cnt    Score   Error  Units
  VectorLoop.convertD2F       523  avgt   15  279.466 ? 0.069  ns/op
  VectorLoop.convertD2I       523  avgt   15  551.009 ? 7.459  ns/op
  VectorLoop.convertF2D       523  avgt   15  276.066 ? 0.117  ns/op
  VectorLoop.convertF2L       523  avgt   15  545.108 ? 5.697  ns/op
  VectorLoop.convertI2D       523  avgt   15  745.303 ? 0.185  ns/op
  VectorLoop.convertI2L       523  avgt   15  260.878 ? 0.044  ns/op
  VectorLoop.convertL2F       523  avgt   15  502.016 ? 0.172  ns/op
  VectorLoop.convertL2I       523  avgt   15  261.654 ? 3.326  ns/op

After the patch:
Benchmark              (length)  Mode  Cnt    Score   Error  Units
  VectorLoop.convertD2F       523  avgt   15  106.975 ? 0.045  ns/op
  VectorLoop.convertD2I       523  avgt   15  546.866 ? 9.287  ns/op
  VectorLoop.convertF2D       523  avgt   15   82.414 ? 0.340  ns/op
  VectorLoop.convertF2L       523  avgt   15  542.235 ? 2.785  ns/op
  VectorLoop.convertI2D       523  avgt   15   92.966 ? 1.400  ns/op
  VectorLoop.convertI2L       523  avgt   15   79.960 ? 0.528  ns/op
  VectorLoop.convertL2F       523  avgt   15  504.712 ? 4.794  ns/op
  VectorLoop.convertL2I       523  avgt   15  129.753 ? 0.094  ns/op

perf data on AVX512:
Before the patch:
Benchmark              (length)  Mode  Cnt    Score   Error  Units
  VectorLoop.convertD2F       523  avgt   15  282.984 ? 4.022  ns/op
  VectorLoop.convertD2I       523  avgt   15  543.080 ? 3.873  ns/op
  VectorLoop.convertF2D       523  avgt   15  273.950 ? 0.131  ns/op
  VectorLoop.convertF2L       523  avgt   15  539.568 ? 2.747  ns/op
  VectorLoop.convertI2D       523  avgt   15  745.238 ? 0.069  ns/op
  VectorLoop.convertI2L       523  avgt   15  260.935 ? 0.169  ns/op
  VectorLoop.convertL2F       523  avgt   15  501.870 ? 0.359  ns/op
  VectorLoop.convertL2I       523  avgt   15  257.508 ? 0.174  ns/op

After the patch:
Benchmark              (length)  Mode  Cnt    Score   Error  Units
  VectorLoop.convertD2F       523  avgt   15   76.687 ? 0.530  ns/op
  VectorLoop.convertD2I       523  avgt   15  545.408 ? 4.657  ns/op
  VectorLoop.convertF2D       523  avgt   15  273.935 ? 0.099  ns/op
  VectorLoop.convertF2L       523  avgt   15  540.534 ? 3.032  ns/op
  VectorLoop.convertI2D       523  avgt   15  745.234 ? 0.053  ns/op
  VectorLoop.convertI2L       523  avgt   15  260.865 ? 0.104  ns/op
  VectorLoop.convertL2F       523  avgt   15   63.834 ? 4.777  ns/op
  VectorLoop.convertL2I       523  avgt   15   48.183 ? 0.990  ns/op

-------------

Commit messages:
 - 8283091: Support type conversion between different data sizes in SLP

Changes: https://git.openjdk.java.net/jdk/pull/7806/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7806&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283091
  Stats: 1085 lines in 14 files changed: 1036 ins; 14 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7806.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7806/head:pull/7806

PR: https://git.openjdk.java.net/jdk/pull/7806

From fgao at openjdk.java.net  Mon Mar 14 08:33:26 2022
From: fgao at openjdk.java.net (Fei Gao)
Date: Mon, 14 Mar 2022 08:33:26 GMT
Subject: RFR: 8283091: Support type conversion between different data sizes
 in SLP [v2]
In-Reply-To: <4qFrtxwRHZfnzJbdVl2z7l6XENvxR3N8Sruc2fraKkw=.1391f639-1514-4e50-899a-d56cdd4afa99@github.com>
References: <4qFrtxwRHZfnzJbdVl2z7l6XENvxR3N8Sruc2fraKkw=.1391f639-1514-4e50-899a-d56cdd4afa99@github.com>
Message-ID: <eKT6M7R9NTOMdWKTli4nOpNqjJ75QfJycYq7yo08qjA=.5ae1f119-de65-4d97-88c6-04c4626cc0ab@github.com>

> After JDK-8275317, C2's SLP vectorizer has supported type conversion between the same data size. We can also support conversions between different data sizes like:
> int <-> double
> float <-> long
> int <-> long
> float <-> double
> 
> A typical test case:
> 
> int[] a;
> double[] b;
> for (int i = start; i < limit; i++) {
>     b[i] = (double) a[i];
> }
> 
> Our expected OptoAssembly code for one iteration is like below:
> 
> add R12, R2, R11, LShiftL #2
> vector_load   V16,[R12, #16]
> vectorcast_i2d  V16, V16  # convert I to D vector
> add R11, R1, R11, LShiftL #3	# ptr
> add R13, R11, #16	# ptr
> vector_store [R13], V16
> 
> To enable the vectorization, the patch solves the following problems in the SLP.
> 
> There are three main operations in the case above, LoadI, ConvI2D and StoreD. Assuming that the vector length is 128 bits, how many scalar nodes should be packed together to a vector? If we decide it separately for each operation node, like what we did before the patch in SuperWord::combine_packs(), a 128-bit vector will support 4 LoadI or 2 ConvI2D or 2 StoreD nodes. However, if we put these packed nodes in a vector node sequence, like loading 4 elements to a vector, then typecasting 2 elements and lastly storing these 2 elements, they become invalid. As a result, we should look through the whole def-use chain
> and then pick up the minimum of these element sizes, like function SuperWord::max_vector_size_in_ud_chain() do in the superword.cpp. In this case, we pack 2 LoadI, 2 ConvI2D and 2 StoreD nodes, and then generate valid vector node sequence, like loading 2 elements, converting the 2 elements to another type and storing the 2 elements with new type.
> 
> After this, LoadI nodes don't make full use of the whole vector and only occupy part of it. So we adapt the code in SuperWord::get_vw_bytes_special() to the situation.
> 
> In SLP, we calculate a kind of alignment as position trace for each scalar node in the whole vector. In this case, the alignments for 2 LoadI nodes are 0, 4 while the alignment for 2 ConvI2D nodes are 0, 8. Sometimes, 4 for LoadI and 8 for ConvI2D work the same, both of which mark that this node is the second node in the whole vector, while the difference between 4 and 8 are just because of their own data sizes. In this situation, we should try to remove the impact caused by different data size in SLP. For example, in the stage of SuperWord::extend_packlist(), while determining if it's potential to pack a pair of def nodes in the function SuperWord::follow_use_defs(), we remove the side effect of different data size by transforming the target alignment from the use node. Because we believe that, assuming that the vector length is 512 bits, if the ConvI2D use nodes have alignments of 16-24 and their def nodes, LoadI, have alignments of 8-12, these two LoadI nodes should be packed as
  a pair as well.
> 
> Similarly, when determining if the vectorization is profitable, type conversion between different data size takes a type of one size and produces a type of another size, hence the special checks on alignment and size should be applied, like what we do in SuperWord::is_vector_use().
> 
> After solving these problems, we successfully implemented the vectorization of type conversion between different data sizes.
> 
> Here is the test data on NEON:
> 
> Before the patch:
> Benchmark              (length)  Mode  Cnt    Score   Error  Units
>   VectorLoop.convertD2F       523  avgt   15  216.431 ? 0.131  ns/op
>   VectorLoop.convertD2I       523  avgt   15  220.522 ? 0.311  ns/op
>   VectorLoop.convertF2D       523  avgt   15  217.034 ? 0.292  ns/op
>   VectorLoop.convertF2L       523  avgt   15  231.634 ? 1.881  ns/op
>   VectorLoop.convertI2D       523  avgt   15  229.538 ? 0.095  ns/op
>   VectorLoop.convertI2L       523  avgt   15  214.822 ? 0.131  ns/op
>   VectorLoop.convertL2F       523  avgt   15  230.188 ? 0.217  ns/op
>   VectorLoop.convertL2I       523  avgt   15  162.234 ? 0.235  ns/op
> 
> After the patch:
> Benchmark              (length)  Mode  Cnt    Score    Error  Units
>   VectorLoop.convertD2F       523  avgt   15  124.352 ?  1.079  ns/op
>   VectorLoop.convertD2I       523  avgt   15  557.388 ?  8.166  ns/op
>   VectorLoop.convertF2D       523  avgt   15  118.082 ?  4.026  ns/op
>   VectorLoop.convertF2L       523  avgt   15  225.810 ? 11.180  ns/op
>   VectorLoop.convertI2D       523  avgt   15  166.247 ?  0.120  ns/op
>   VectorLoop.convertI2L       523  avgt   15  119.699 ?  2.925  ns/op
>   VectorLoop.convertL2F       523  avgt   15  220.847 ?  0.053  ns/op
>   VectorLoop.convertL2I       523  avgt   15  122.339 ?  2.738  ns/op
> 
> perf data on X86:
> Before the patch:
> Benchmark              (length)  Mode  Cnt    Score   Error  Units
>   VectorLoop.convertD2F       523  avgt   15  279.466 ? 0.069  ns/op
>   VectorLoop.convertD2I       523  avgt   15  551.009 ? 7.459  ns/op
>   VectorLoop.convertF2D       523  avgt   15  276.066 ? 0.117  ns/op
>   VectorLoop.convertF2L       523  avgt   15  545.108 ? 5.697  ns/op
>   VectorLoop.convertI2D       523  avgt   15  745.303 ? 0.185  ns/op
>   VectorLoop.convertI2L       523  avgt   15  260.878 ? 0.044  ns/op
>   VectorLoop.convertL2F       523  avgt   15  502.016 ? 0.172  ns/op
>   VectorLoop.convertL2I       523  avgt   15  261.654 ? 3.326  ns/op
> 
> After the patch:
> Benchmark              (length)  Mode  Cnt    Score   Error  Units
>   VectorLoop.convertD2F       523  avgt   15  106.975 ? 0.045  ns/op
>   VectorLoop.convertD2I       523  avgt   15  546.866 ? 9.287  ns/op
>   VectorLoop.convertF2D       523  avgt   15   82.414 ? 0.340  ns/op
>   VectorLoop.convertF2L       523  avgt   15  542.235 ? 2.785  ns/op
>   VectorLoop.convertI2D       523  avgt   15   92.966 ? 1.400  ns/op
>   VectorLoop.convertI2L       523  avgt   15   79.960 ? 0.528  ns/op
>   VectorLoop.convertL2F       523  avgt   15  504.712 ? 4.794  ns/op
>   VectorLoop.convertL2I       523  avgt   15  129.753 ? 0.094  ns/op
> 
> perf data on AVX512:
> Before the patch:
> Benchmark              (length)  Mode  Cnt    Score   Error  Units
>   VectorLoop.convertD2F       523  avgt   15  282.984 ? 4.022  ns/op
>   VectorLoop.convertD2I       523  avgt   15  543.080 ? 3.873  ns/op
>   VectorLoop.convertF2D       523  avgt   15  273.950 ? 0.131  ns/op
>   VectorLoop.convertF2L       523  avgt   15  539.568 ? 2.747  ns/op
>   VectorLoop.convertI2D       523  avgt   15  745.238 ? 0.069  ns/op
>   VectorLoop.convertI2L       523  avgt   15  260.935 ? 0.169  ns/op
>   VectorLoop.convertL2F       523  avgt   15  501.870 ? 0.359  ns/op
>   VectorLoop.convertL2I       523  avgt   15  257.508 ? 0.174  ns/op
> 
> After the patch:
> Benchmark              (length)  Mode  Cnt    Score   Error  Units
>   VectorLoop.convertD2F       523  avgt   15   76.687 ? 0.530  ns/op
>   VectorLoop.convertD2I       523  avgt   15  545.408 ? 4.657  ns/op
>   VectorLoop.convertF2D       523  avgt   15  273.935 ? 0.099  ns/op
>   VectorLoop.convertF2L       523  avgt   15  540.534 ? 3.032  ns/op
>   VectorLoop.convertI2D       523  avgt   15  745.234 ? 0.053  ns/op
>   VectorLoop.convertI2L       523  avgt   15  260.865 ? 0.104  ns/op
>   VectorLoop.convertL2F       523  avgt   15   63.834 ? 4.777  ns/op
>   VectorLoop.convertL2I       523  avgt   15   48.183 ? 0.990  ns/op

Fei Gao has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8283091: Support type conversion between different data sizes in SLP
  
  After JDK-8275317, C2's SLP vectorizer has supported type conversion
  between the same data size. We can also support conversions between
  different data sizes like:
  int <-> double
  float <-> long
  int <-> long
  float <-> double
  
  A typical test case:
  
  int[] a;
  double[] b;
  for (int i = start; i < limit; i++) {
      b[i] = (double) a[i];
  }
  
  Our expected OptoAssembly code for one iteration is like below:
  
  add R12, R2, R11, LShiftL #2
  vector_load   V16,[R12, #16]
  vectorcast_i2d  V16, V16  # convert I to D vector
  add R11, R1, R11, LShiftL #3	# ptr
  add R13, R11, #16	# ptr
  vector_store [R13], V16
  
  To enable the vectorization, the patch solves the following problems
  in the SLP.
  
  There are three main operations in the case above, LoadI, ConvI2D and
  StoreD. Assuming that the vector length is 128 bits, how many scalar
  nodes should be packed together to a vector? If we decide it
  separately for each operation node, like what we did before the patch
  in SuperWord::combine_packs(), a 128-bit vector will support 4 LoadI
  or 2 ConvI2D or 2 StoreD nodes. However, if we put these packed nodes
  in a vector node sequence, like loading 4 elements to a vector, then
  typecasting 2 elements and lastly storing these 2 elements, they become
  invalid. As a result, we should look through the whole def-use chain
  and then pick up the minimum of these element sizes, like function
  SuperWord::max_vector_size_in_ud_chain() do in the superword.cpp.
  In this case, we pack 2 LoadI, 2 ConvI2D and 2 StoreD nodes, and then
  generate valid vector node sequence, like loading 2 elements,
  converting the 2 elements to another type and storing the 2 elements
  with new type.
  
  After this, LoadI nodes don't make full use of the whole vector and
  only occupy part of it. So we adapt the code in
  SuperWord::get_vw_bytes_special() to the situation.
  
  In SLP, we calculate a kind of alignment as position trace for each
  scalar node in the whole vector. In this case, the alignments for 2
  LoadI nodes are 0, 4 while the alignment for 2 ConvI2D nodes are 0, 8.
  Sometimes, 4 for LoadI and 8 for ConvI2D work the same, both of which
  mark that this node is the second node in the whole vector, while the
  difference between 4 and 8 are just because of their own data sizes. In
  this situation, we should try to remove the impact caused by different
  data size in SLP. For example, in the stage of
  SuperWord::extend_packlist(), while determining if it's potential to
  pack a pair of def nodes in the function SuperWord::follow_use_defs(),
  we remove the side effect of different data size by transforming the
  target alignment from the use node. Because we believe that, assuming
  that the vector length is 512 bits, if the ConvI2D use nodes have
  alignments of 16-24 and their def nodes, LoadI, have alignments of 8-12,
  these two LoadI nodes should be packed as a pair as well.
  
  Similarly, when determining if the vectorization is profitable, type
  conversion between different data size takes a type of one size and
  produces a type of another size, hence the special checks on alignment
  and size should be applied, like what we do in SuperWord::is_vector_use.
  
  After solving these problems, we successfully implemented the
  vectorization of type conversion between different data sizes.
  
  Here is the test data on NEON:
  
  Before the patch:
  Benchmark              (length)  Mode  Cnt    Score   Error  Units
    VectorLoop.convertD2F       523  avgt   15  216.431 ? 0.131  ns/op
    VectorLoop.convertD2I       523  avgt   15  220.522 ? 0.311  ns/op
    VectorLoop.convertF2D       523  avgt   15  217.034 ? 0.292  ns/op
    VectorLoop.convertF2L       523  avgt   15  231.634 ? 1.881  ns/op
    VectorLoop.convertI2D       523  avgt   15  229.538 ? 0.095  ns/op
    VectorLoop.convertI2L       523  avgt   15  214.822 ? 0.131  ns/op
    VectorLoop.convertL2F       523  avgt   15  230.188 ? 0.217  ns/op
    VectorLoop.convertL2I       523  avgt   15  162.234 ? 0.235  ns/op
  
  After the patch:
  Benchmark              (length)  Mode  Cnt    Score    Error  Units
    VectorLoop.convertD2F       523  avgt   15  124.352 ?  1.079  ns/op
    VectorLoop.convertD2I       523  avgt   15  557.388 ?  8.166  ns/op
    VectorLoop.convertF2D       523  avgt   15  118.082 ?  4.026  ns/op
    VectorLoop.convertF2L       523  avgt   15  225.810 ? 11.180  ns/op
    VectorLoop.convertI2D       523  avgt   15  166.247 ?  0.120  ns/op
    VectorLoop.convertI2L       523  avgt   15  119.699 ?  2.925  ns/op
    VectorLoop.convertL2F       523  avgt   15  220.847 ?  0.053  ns/op
    VectorLoop.convertL2I       523  avgt   15  122.339 ?  2.738  ns/op
  
  perf data on X86:
  Before the patch:
  Benchmark              (length)  Mode  Cnt    Score   Error  Units
    VectorLoop.convertD2F       523  avgt   15  279.466 ? 0.069  ns/op
    VectorLoop.convertD2I       523  avgt   15  551.009 ? 7.459  ns/op
    VectorLoop.convertF2D       523  avgt   15  276.066 ? 0.117  ns/op
    VectorLoop.convertF2L       523  avgt   15  545.108 ? 5.697  ns/op
    VectorLoop.convertI2D       523  avgt   15  745.303 ? 0.185  ns/op
    VectorLoop.convertI2L       523  avgt   15  260.878 ? 0.044  ns/op
    VectorLoop.convertL2F       523  avgt   15  502.016 ? 0.172  ns/op
    VectorLoop.convertL2I       523  avgt   15  261.654 ? 3.326  ns/op
  
  After the patch:
  Benchmark              (length)  Mode  Cnt    Score   Error  Units
    VectorLoop.convertD2F       523  avgt   15  106.975 ? 0.045  ns/op
    VectorLoop.convertD2I       523  avgt   15  546.866 ? 9.287  ns/op
    VectorLoop.convertF2D       523  avgt   15   82.414 ? 0.340  ns/op
    VectorLoop.convertF2L       523  avgt   15  542.235 ? 2.785  ns/op
    VectorLoop.convertI2D       523  avgt   15   92.966 ? 1.400  ns/op
    VectorLoop.convertI2L       523  avgt   15   79.960 ? 0.528  ns/op
    VectorLoop.convertL2F       523  avgt   15  504.712 ? 4.794  ns/op
    VectorLoop.convertL2I       523  avgt   15  129.753 ? 0.094  ns/op
  
  perf data on AVX512:
  Before the patch:
  Benchmark              (length)  Mode  Cnt    Score   Error  Units
    VectorLoop.convertD2F       523  avgt   15  282.984 ? 4.022  ns/op
    VectorLoop.convertD2I       523  avgt   15  543.080 ? 3.873  ns/op
    VectorLoop.convertF2D       523  avgt   15  273.950 ? 0.131  ns/op
    VectorLoop.convertF2L       523  avgt   15  539.568 ? 2.747  ns/op
    VectorLoop.convertI2D       523  avgt   15  745.238 ? 0.069  ns/op
    VectorLoop.convertI2L       523  avgt   15  260.935 ? 0.169  ns/op
    VectorLoop.convertL2F       523  avgt   15  501.870 ? 0.359  ns/op
    VectorLoop.convertL2I       523  avgt   15  257.508 ? 0.174  ns/op
  
  After the patch:
  Benchmark              (length)  Mode  Cnt    Score   Error  Units
    VectorLoop.convertD2F       523  avgt   15   76.687 ? 0.530  ns/op
    VectorLoop.convertD2I       523  avgt   15  545.408 ? 4.657  ns/op
    VectorLoop.convertF2D       523  avgt   15  273.935 ? 0.099  ns/op
    VectorLoop.convertF2L       523  avgt   15  540.534 ? 3.032  ns/op
    VectorLoop.convertI2D       523  avgt   15  745.234 ? 0.053  ns/op
    VectorLoop.convertI2L       523  avgt   15  260.865 ? 0.104  ns/op
    VectorLoop.convertL2F       523  avgt   15   63.834 ? 4.777  ns/op
    VectorLoop.convertL2I       523  avgt   15   48.183 ? 0.990  ns/op
  
  Change-Id: I93e60fd956547dad9204ceec90220145c58a72ef

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7806/files
  - new: https://git.openjdk.java.net/jdk/pull/7806/files/c6d0716e..c2c13739

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7806&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7806&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7806.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7806/head:pull/7806

PR: https://git.openjdk.java.net/jdk/pull/7806

From dlong at openjdk.java.net  Mon Mar 14 08:34:40 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Mon, 14 Mar 2022 08:34:40 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity" [v2]
In-Reply-To: <bB6RB3yM-YNyZ-rWSZ6G5zvXMaJGiQ34MvftQK0Ruww=.24dee710-8533-41d4-9b8b-12be6c83bf21@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
 <jo8ETqamI_NuREYJ7Fgf5szxNidIWX5-43SK0T6X4DY=.592ad8c0-3f48-4791-b488-3ed660b1e356@github.com>
 <bB6RB3yM-YNyZ-rWSZ6G5zvXMaJGiQ34MvftQK0Ruww=.24dee710-8533-41d4-9b8b-12be6c83bf21@github.com>
Message-ID: <3RrzOdqAGvNLzvV0BlpC_Fbv_bquznXD99rgai_sgjk=.17228dee-226c-4684-be69-af927c6aa9ad@github.com>

On Mon, 14 Mar 2022 00:15:20 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improvement based on review
>
> src/hotspot/share/runtime/stubRoutines.cpp line 219:
> 
>> 217:     TraceTime timer("StubRoutines generation 1", TRACETIME_LOG(Info, startuptime));
>> 218:     // Add extra space for large CodeEntryAlignment
>> 219:     int max_stubs = 10;
> 
> Thanks for your update.
> 
> There are about 30 stubs (max number of stubs) to be generated in `generate_initial()` for x86_64.
> Why not `max_stubs = 30` ?

I instrumented the align() call in my private build to count how many used align(CodeEntryAlignment), and I counted only 7, then I rounded up to 10.  Maybe I should change the name to max_aligned_stubs to make it more clear?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7800

From jiefu at openjdk.java.net  Mon Mar 14 08:48:41 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 14 Mar 2022 08:48:41 GMT
Subject: RFR: 8283091: Support type conversion between different data sizes
 in SLP [v2]
In-Reply-To: <eKT6M7R9NTOMdWKTli4nOpNqjJ75QfJycYq7yo08qjA=.5ae1f119-de65-4d97-88c6-04c4626cc0ab@github.com>
References: <4qFrtxwRHZfnzJbdVl2z7l6XENvxR3N8Sruc2fraKkw=.1391f639-1514-4e50-899a-d56cdd4afa99@github.com>
 <eKT6M7R9NTOMdWKTli4nOpNqjJ75QfJycYq7yo08qjA=.5ae1f119-de65-4d97-88c6-04c4626cc0ab@github.com>
Message-ID: <gezl7u0FkmtQcagZZVX33Y54xFkTJGzFs0RTq3wEEok=.a0f1a390-6c2b-4f18-8d05-6ae3b0e1c875@github.com>

On Mon, 14 Mar 2022 08:33:26 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> After JDK-8275317, C2's SLP vectorizer has supported type conversion between the same data size. We can also support conversions between different data sizes like:
>> int <-> double
>> float <-> long
>> int <-> long
>> float <-> double
>> 
>> A typical test case:
>> 
>> int[] a;
>> double[] b;
>> for (int i = start; i < limit; i++) {
>>     b[i] = (double) a[i];
>> }
>> 
>> Our expected OptoAssembly code for one iteration is like below:
>> 
>> add R12, R2, R11, LShiftL #2
>> vector_load   V16,[R12, #16]
>> vectorcast_i2d  V16, V16  # convert I to D vector
>> add R11, R1, R11, LShiftL #3	# ptr
>> add R13, R11, #16	# ptr
>> vector_store [R13], V16
>> 
>> To enable the vectorization, the patch solves the following problems in the SLP.
>> 
>> There are three main operations in the case above, LoadI, ConvI2D and StoreD. Assuming that the vector length is 128 bits, how many scalar nodes should be packed together to a vector? If we decide it separately for each operation node, like what we did before the patch in SuperWord::combine_packs(), a 128-bit vector will support 4 LoadI or 2 ConvI2D or 2 StoreD nodes. However, if we put these packed nodes in a vector node sequence, like loading 4 elements to a vector, then typecasting 2 elements and lastly storing these 2 elements, they become invalid. As a result, we should look through the whole def-use chain
>> and then pick up the minimum of these element sizes, like function SuperWord::max_vector_size_in_ud_chain() do in the superword.cpp. In this case, we pack 2 LoadI, 2 ConvI2D and 2 StoreD nodes, and then generate valid vector node sequence, like loading 2 elements, converting the 2 elements to another type and storing the 2 elements with new type.
>> 
>> After this, LoadI nodes don't make full use of the whole vector and only occupy part of it. So we adapt the code in SuperWord::get_vw_bytes_special() to the situation.
>> 
>> In SLP, we calculate a kind of alignment as position trace for each scalar node in the whole vector. In this case, the alignments for 2 LoadI nodes are 0, 4 while the alignment for 2 ConvI2D nodes are 0, 8. Sometimes, 4 for LoadI and 8 for ConvI2D work the same, both of which mark that this node is the second node in the whole vector, while the difference between 4 and 8 are just because of their own data sizes. In this situation, we should try to remove the impact caused by different data size in SLP. For example, in the stage of SuperWord::extend_packlist(), while determining if it's potential to pack a pair of def nodes in the function SuperWord::follow_use_defs(), we remove the side effect of different data size by transforming the target alignment from the use node. Because we believe that, assuming that the vector length is 512 bits, if the ConvI2D use nodes have alignments of 16-24 and their def nodes, LoadI, have alignments of 8-12, these two LoadI nodes should be packed a
 s a pair as well.
>> 
>> Similarly, when determining if the vectorization is profitable, type conversion between different data size takes a type of one size and produces a type of another size, hence the special checks on alignment and size should be applied, like what we do in SuperWord::is_vector_use().
>> 
>> After solving these problems, we successfully implemented the vectorization of type conversion between different data sizes.
>> 
>> Here is the test data on NEON:
>> 
>> Before the patch:
>> Benchmark              (length)  Mode  Cnt    Score   Error  Units
>>   VectorLoop.convertD2F       523  avgt   15  216.431 ? 0.131  ns/op
>>   VectorLoop.convertD2I       523  avgt   15  220.522 ? 0.311  ns/op
>>   VectorLoop.convertF2D       523  avgt   15  217.034 ? 0.292  ns/op
>>   VectorLoop.convertF2L       523  avgt   15  231.634 ? 1.881  ns/op
>>   VectorLoop.convertI2D       523  avgt   15  229.538 ? 0.095  ns/op
>>   VectorLoop.convertI2L       523  avgt   15  214.822 ? 0.131  ns/op
>>   VectorLoop.convertL2F       523  avgt   15  230.188 ? 0.217  ns/op
>>   VectorLoop.convertL2I       523  avgt   15  162.234 ? 0.235  ns/op
>> 
>> After the patch:
>> Benchmark              (length)  Mode  Cnt    Score    Error  Units
>>   VectorLoop.convertD2F       523  avgt   15  124.352 ?  1.079  ns/op
>>   VectorLoop.convertD2I       523  avgt   15  557.388 ?  8.166  ns/op
>>   VectorLoop.convertF2D       523  avgt   15  118.082 ?  4.026  ns/op
>>   VectorLoop.convertF2L       523  avgt   15  225.810 ? 11.180  ns/op
>>   VectorLoop.convertI2D       523  avgt   15  166.247 ?  0.120  ns/op
>>   VectorLoop.convertI2L       523  avgt   15  119.699 ?  2.925  ns/op
>>   VectorLoop.convertL2F       523  avgt   15  220.847 ?  0.053  ns/op
>>   VectorLoop.convertL2I       523  avgt   15  122.339 ?  2.738  ns/op
>> 
>> perf data on X86:
>> Before the patch:
>> Benchmark              (length)  Mode  Cnt    Score   Error  Units
>>   VectorLoop.convertD2F       523  avgt   15  279.466 ? 0.069  ns/op
>>   VectorLoop.convertD2I       523  avgt   15  551.009 ? 7.459  ns/op
>>   VectorLoop.convertF2D       523  avgt   15  276.066 ? 0.117  ns/op
>>   VectorLoop.convertF2L       523  avgt   15  545.108 ? 5.697  ns/op
>>   VectorLoop.convertI2D       523  avgt   15  745.303 ? 0.185  ns/op
>>   VectorLoop.convertI2L       523  avgt   15  260.878 ? 0.044  ns/op
>>   VectorLoop.convertL2F       523  avgt   15  502.016 ? 0.172  ns/op
>>   VectorLoop.convertL2I       523  avgt   15  261.654 ? 3.326  ns/op
>> 
>> After the patch:
>> Benchmark              (length)  Mode  Cnt    Score   Error  Units
>>   VectorLoop.convertD2F       523  avgt   15  106.975 ? 0.045  ns/op
>>   VectorLoop.convertD2I       523  avgt   15  546.866 ? 9.287  ns/op
>>   VectorLoop.convertF2D       523  avgt   15   82.414 ? 0.340  ns/op
>>   VectorLoop.convertF2L       523  avgt   15  542.235 ? 2.785  ns/op
>>   VectorLoop.convertI2D       523  avgt   15   92.966 ? 1.400  ns/op
>>   VectorLoop.convertI2L       523  avgt   15   79.960 ? 0.528  ns/op
>>   VectorLoop.convertL2F       523  avgt   15  504.712 ? 4.794  ns/op
>>   VectorLoop.convertL2I       523  avgt   15  129.753 ? 0.094  ns/op
>> 
>> perf data on AVX512:
>> Before the patch:
>> Benchmark              (length)  Mode  Cnt    Score   Error  Units
>>   VectorLoop.convertD2F       523  avgt   15  282.984 ? 4.022  ns/op
>>   VectorLoop.convertD2I       523  avgt   15  543.080 ? 3.873  ns/op
>>   VectorLoop.convertF2D       523  avgt   15  273.950 ? 0.131  ns/op
>>   VectorLoop.convertF2L       523  avgt   15  539.568 ? 2.747  ns/op
>>   VectorLoop.convertI2D       523  avgt   15  745.238 ? 0.069  ns/op
>>   VectorLoop.convertI2L       523  avgt   15  260.935 ? 0.169  ns/op
>>   VectorLoop.convertL2F       523  avgt   15  501.870 ? 0.359  ns/op
>>   VectorLoop.convertL2I       523  avgt   15  257.508 ? 0.174  ns/op
>> 
>> After the patch:
>> Benchmark              (length)  Mode  Cnt    Score   Error  Units
>>   VectorLoop.convertD2F       523  avgt   15   76.687 ? 0.530  ns/op
>>   VectorLoop.convertD2I       523  avgt   15  545.408 ? 4.657  ns/op
>>   VectorLoop.convertF2D       523  avgt   15  273.935 ? 0.099  ns/op
>>   VectorLoop.convertF2L       523  avgt   15  540.534 ? 3.032  ns/op
>>   VectorLoop.convertI2D       523  avgt   15  745.234 ? 0.053  ns/op
>>   VectorLoop.convertI2L       523  avgt   15  260.865 ? 0.104  ns/op
>>   VectorLoop.convertL2F       523  avgt   15   63.834 ? 4.777  ns/op
>>   VectorLoop.convertL2I       523  avgt   15   48.183 ? 0.990  ns/op
>
> Fei Gao has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8283091: Support type conversion between different data sizes in SLP
>   
>   After JDK-8275317, C2's SLP vectorizer has supported type conversion
>   between the same data size. We can also support conversions between
>   different data sizes like:
>   int <-> double
>   float <-> long
>   int <-> long
>   float <-> double
>   
>   A typical test case:
>   
>   int[] a;
>   double[] b;
>   for (int i = start; i < limit; i++) {
>       b[i] = (double) a[i];
>   }
>   
>   Our expected OptoAssembly code for one iteration is like below:
>   
>   add R12, R2, R11, LShiftL #2
>   vector_load   V16,[R12, #16]
>   vectorcast_i2d  V16, V16  # convert I to D vector
>   add R11, R1, R11, LShiftL #3	# ptr
>   add R13, R11, #16	# ptr
>   vector_store [R13], V16
>   
>   To enable the vectorization, the patch solves the following problems
>   in the SLP.
>   
>   There are three main operations in the case above, LoadI, ConvI2D and
>   StoreD. Assuming that the vector length is 128 bits, how many scalar
>   nodes should be packed together to a vector? If we decide it
>   separately for each operation node, like what we did before the patch
>   in SuperWord::combine_packs(), a 128-bit vector will support 4 LoadI
>   or 2 ConvI2D or 2 StoreD nodes. However, if we put these packed nodes
>   in a vector node sequence, like loading 4 elements to a vector, then
>   typecasting 2 elements and lastly storing these 2 elements, they become
>   invalid. As a result, we should look through the whole def-use chain
>   and then pick up the minimum of these element sizes, like function
>   SuperWord::max_vector_size_in_ud_chain() do in the superword.cpp.
>   In this case, we pack 2 LoadI, 2 ConvI2D and 2 StoreD nodes, and then
>   generate valid vector node sequence, like loading 2 elements,
>   converting the 2 elements to another type and storing the 2 elements
>   with new type.
>   
>   After this, LoadI nodes don't make full use of the whole vector and
>   only occupy part of it. So we adapt the code in
>   SuperWord::get_vw_bytes_special() to the situation.
>   
>   In SLP, we calculate a kind of alignment as position trace for each
>   scalar node in the whole vector. In this case, the alignments for 2
>   LoadI nodes are 0, 4 while the alignment for 2 ConvI2D nodes are 0, 8.
>   Sometimes, 4 for LoadI and 8 for ConvI2D work the same, both of which
>   mark that this node is the second node in the whole vector, while the
>   difference between 4 and 8 are just because of their own data sizes. In
>   this situation, we should try to remove the impact caused by different
>   data size in SLP. For example, in the stage of
>   SuperWord::extend_packlist(), while determining if it's potential to
>   pack a pair of def nodes in the function SuperWord::follow_use_defs(),
>   we remove the side effect of different data size by transforming the
>   target alignment from the use node. Because we believe that, assuming
>   that the vector length is 512 bits, if the ConvI2D use nodes have
>   alignments of 16-24 and their def nodes, LoadI, have alignments of 8-12,
>   these two LoadI nodes should be packed as a pair as well.
>   
>   Similarly, when determining if the vectorization is profitable, type
>   conversion between different data size takes a type of one size and
>   produces a type of another size, hence the special checks on alignment
>   and size should be applied, like what we do in SuperWord::is_vector_use.
>   
>   After solving these problems, we successfully implemented the
>   vectorization of type conversion between different data sizes.
>   
>   Here is the test data on NEON:
>   
>   Before the patch:
>   Benchmark              (length)  Mode  Cnt    Score   Error  Units
>     VectorLoop.convertD2F       523  avgt   15  216.431 ? 0.131  ns/op
>     VectorLoop.convertD2I       523  avgt   15  220.522 ? 0.311  ns/op
>     VectorLoop.convertF2D       523  avgt   15  217.034 ? 0.292  ns/op
>     VectorLoop.convertF2L       523  avgt   15  231.634 ? 1.881  ns/op
>     VectorLoop.convertI2D       523  avgt   15  229.538 ? 0.095  ns/op
>     VectorLoop.convertI2L       523  avgt   15  214.822 ? 0.131  ns/op
>     VectorLoop.convertL2F       523  avgt   15  230.188 ? 0.217  ns/op
>     VectorLoop.convertL2I       523  avgt   15  162.234 ? 0.235  ns/op
>   
>   After the patch:
>   Benchmark              (length)  Mode  Cnt    Score    Error  Units
>     VectorLoop.convertD2F       523  avgt   15  124.352 ?  1.079  ns/op
>     VectorLoop.convertD2I       523  avgt   15  557.388 ?  8.166  ns/op
>     VectorLoop.convertF2D       523  avgt   15  118.082 ?  4.026  ns/op
>     VectorLoop.convertF2L       523  avgt   15  225.810 ? 11.180  ns/op
>     VectorLoop.convertI2D       523  avgt   15  166.247 ?  0.120  ns/op
>     VectorLoop.convertI2L       523  avgt   15  119.699 ?  2.925  ns/op
>     VectorLoop.convertL2F       523  avgt   15  220.847 ?  0.053  ns/op
>     VectorLoop.convertL2I       523  avgt   15  122.339 ?  2.738  ns/op
>   
>   perf data on X86:
>   Before the patch:
>   Benchmark              (length)  Mode  Cnt    Score   Error  Units
>     VectorLoop.convertD2F       523  avgt   15  279.466 ? 0.069  ns/op
>     VectorLoop.convertD2I       523  avgt   15  551.009 ? 7.459  ns/op
>     VectorLoop.convertF2D       523  avgt   15  276.066 ? 0.117  ns/op
>     VectorLoop.convertF2L       523  avgt   15  545.108 ? 5.697  ns/op
>     VectorLoop.convertI2D       523  avgt   15  745.303 ? 0.185  ns/op
>     VectorLoop.convertI2L       523  avgt   15  260.878 ? 0.044  ns/op
>     VectorLoop.convertL2F       523  avgt   15  502.016 ? 0.172  ns/op
>     VectorLoop.convertL2I       523  avgt   15  261.654 ? 3.326  ns/op
>   
>   After the patch:
>   Benchmark              (length)  Mode  Cnt    Score   Error  Units
>     VectorLoop.convertD2F       523  avgt   15  106.975 ? 0.045  ns/op
>     VectorLoop.convertD2I       523  avgt   15  546.866 ? 9.287  ns/op
>     VectorLoop.convertF2D       523  avgt   15   82.414 ? 0.340  ns/op
>     VectorLoop.convertF2L       523  avgt   15  542.235 ? 2.785  ns/op
>     VectorLoop.convertI2D       523  avgt   15   92.966 ? 1.400  ns/op
>     VectorLoop.convertI2L       523  avgt   15   79.960 ? 0.528  ns/op
>     VectorLoop.convertL2F       523  avgt   15  504.712 ? 4.794  ns/op
>     VectorLoop.convertL2I       523  avgt   15  129.753 ? 0.094  ns/op
>   
>   perf data on AVX512:
>   Before the patch:
>   Benchmark              (length)  Mode  Cnt    Score   Error  Units
>     VectorLoop.convertD2F       523  avgt   15  282.984 ? 4.022  ns/op
>     VectorLoop.convertD2I       523  avgt   15  543.080 ? 3.873  ns/op
>     VectorLoop.convertF2D       523  avgt   15  273.950 ? 0.131  ns/op
>     VectorLoop.convertF2L       523  avgt   15  539.568 ? 2.747  ns/op
>     VectorLoop.convertI2D       523  avgt   15  745.238 ? 0.069  ns/op
>     VectorLoop.convertI2L       523  avgt   15  260.935 ? 0.169  ns/op
>     VectorLoop.convertL2F       523  avgt   15  501.870 ? 0.359  ns/op
>     VectorLoop.convertL2I       523  avgt   15  257.508 ? 0.174  ns/op
>   
>   After the patch:
>   Benchmark              (length)  Mode  Cnt    Score   Error  Units
>     VectorLoop.convertD2F       523  avgt   15   76.687 ? 0.530  ns/op
>     VectorLoop.convertD2I       523  avgt   15  545.408 ? 4.657  ns/op
>     VectorLoop.convertF2D       523  avgt   15  273.935 ? 0.099  ns/op
>     VectorLoop.convertF2L       523  avgt   15  540.534 ? 3.032  ns/op
>     VectorLoop.convertI2D       523  avgt   15  745.234 ? 0.053  ns/op
>     VectorLoop.convertI2L       523  avgt   15  260.865 ? 0.104  ns/op
>     VectorLoop.convertL2F       523  avgt   15   63.834 ? 4.777  ns/op
>     VectorLoop.convertL2I       523  avgt   15   48.183 ? 0.990  ns/op
>   
>   Change-Id: I93e60fd956547dad9204ceec90220145c58a72ef

Good job!

Did you forget the micro-benchmark VectorLoop.java?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7806

From jiefu at openjdk.java.net  Mon Mar 14 09:01:49 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 14 Mar 2022 09:01:49 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity" [v2]
In-Reply-To: <3RrzOdqAGvNLzvV0BlpC_Fbv_bquznXD99rgai_sgjk=.17228dee-226c-4684-be69-af927c6aa9ad@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
 <jo8ETqamI_NuREYJ7Fgf5szxNidIWX5-43SK0T6X4DY=.592ad8c0-3f48-4791-b488-3ed660b1e356@github.com>
 <bB6RB3yM-YNyZ-rWSZ6G5zvXMaJGiQ34MvftQK0Ruww=.24dee710-8533-41d4-9b8b-12be6c83bf21@github.com>
 <3RrzOdqAGvNLzvV0BlpC_Fbv_bquznXD99rgai_sgjk=.17228dee-226c-4684-be69-af927c6aa9ad@github.com>
Message-ID: <mawUvCa3c-HXM-HGE8cEN5VZx7Md23V2IzAJT3SCoB0=.c6c7f87e-06c4-4f8a-ab7e-184231ba71a8@github.com>

On Mon, 14 Mar 2022 08:31:46 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/share/runtime/stubRoutines.cpp line 219:
>> 
>>> 217:     TraceTime timer("StubRoutines generation 1", TRACETIME_LOG(Info, startuptime));
>>> 218:     // Add extra space for large CodeEntryAlignment
>>> 219:     int max_stubs = 10;
>> 
>> Thanks for your update.
>> 
>> There are about 30 stubs (max number of stubs) to be generated in `generate_initial()` for x86_64.
>> Why not `max_stubs = 30` ?
>
> I instrumented the align() call in my private build to count how many used align(CodeEntryAlignment), and I counted only 7, then I rounded up to 10.  Maybe I should change the name to max_aligned_stubs to make it more clear?

`max_aligned_stubs` is fine to me.
Please also update the copyright year.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7800

From fgao at openjdk.java.net  Mon Mar 14 09:03:52 2022
From: fgao at openjdk.java.net (Fei Gao)
Date: Mon, 14 Mar 2022 09:03:52 GMT
Subject: RFR: 8283091: Support type conversion between different data sizes
 in SLP [v2]
In-Reply-To: <gezl7u0FkmtQcagZZVX33Y54xFkTJGzFs0RTq3wEEok=.a0f1a390-6c2b-4f18-8d05-6ae3b0e1c875@github.com>
References: <4qFrtxwRHZfnzJbdVl2z7l6XENvxR3N8Sruc2fraKkw=.1391f639-1514-4e50-899a-d56cdd4afa99@github.com>
 <eKT6M7R9NTOMdWKTli4nOpNqjJ75QfJycYq7yo08qjA=.5ae1f119-de65-4d97-88c6-04c4626cc0ab@github.com>
 <gezl7u0FkmtQcagZZVX33Y54xFkTJGzFs0RTq3wEEok=.a0f1a390-6c2b-4f18-8d05-6ae3b0e1c875@github.com>
Message-ID: <-37Zcqz0MqxLqIUZPx9nQWib2xhdI5cQ2AGsSg7UjyE=.3ba5181e-4561-4bbb-ad9b-a15188f2a5a5@github.com>

On Mon, 14 Mar 2022 08:45:18 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Did you forget the micro-benchmark VectorLoop.java?

Thanks for your review. Sorry to miss it. Add it ASAP :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7806

From chagedorn at openjdk.java.net  Mon Mar 14 09:05:57 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 14 Mar 2022 09:05:57 GMT
Subject: RFR: 8272735: Add missing SubL node transformations
In-Reply-To: <eFzwVPibLwh_XoXsOlIJQ3qjARbwXJaIVQUOcVGrznA=.7cc15e6e-3c6a-4dba-9e90-6e216874e600@github.com>
References: <eFzwVPibLwh_XoXsOlIJQ3qjARbwXJaIVQUOcVGrznA=.7cc15e6e-3c6a-4dba-9e90-6e216874e600@github.com>
Message-ID: <jW8eUYGg2s-P6MNK0hy6Tge6cpw_YB0lRd2ZHhf2WAM=.041edb03-6c45-4cc5-a0ad-ad51f4e54704@github.com>

On Wed, 2 Mar 2022 21:28:13 GMT, Ahmed Muhsin <duke at openjdk.java.net> wrote:

> This change adds/enables missing subnode transformations for operations of type `long`.
> A few comments in the test file `SubINodeIdealizationTests.java` were modified to add clarity and to fix a typo.
> Hotspot:tier1 tests were run, this change does not introduce any new failures.

Looks good to me, too!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7669

From tschatzl at openjdk.java.net  Mon Mar 14 09:06:43 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 14 Mar 2022 09:06:43 GMT
Subject: RFR: 8283008: KRegister documentation out of date [v2]
In-Reply-To: <bsGAsb5fkWLYfDo_LbDZCuxsL0awJT59ffPqHzRu-2s=.9f014adc-0bf7-4441-ae53-8f4bf5e231cb@github.com>
References: <yOwEccFWgauV9iyfz0w5tkAvM-4CzsOaw1Yzxh8Snb0=.bfc3406a-1d82-4393-ac2d-4874761111d1@github.com>
 <bsGAsb5fkWLYfDo_LbDZCuxsL0awJT59ffPqHzRu-2s=.9f014adc-0bf7-4441-ae53-8f4bf5e231cb@github.com>
Message-ID: <qbxfdeb4ODqClZ6V9Y9D701QmgSUhRIFFiNOHJ6TOG0=.b209dcda-52e0-43d1-928c-6dada4dd5188@github.com>

On Fri, 11 Mar 2022 21:05:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this cleanup of `KRegister(Impl)` documentation, currently being a mix of copy&paste from `XMMRegister` and obsolete MMX support.
>> 
>> Testing: local compilation
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright

Thanks everyone for your reviews

-------------

PR: https://git.openjdk.java.net/jdk/pull/7784

From tschatzl at openjdk.java.net  Mon Mar 14 09:06:44 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 14 Mar 2022 09:06:44 GMT
Subject: Integrated: 8283008: KRegister documentation out of date
In-Reply-To: <yOwEccFWgauV9iyfz0w5tkAvM-4CzsOaw1Yzxh8Snb0=.bfc3406a-1d82-4393-ac2d-4874761111d1@github.com>
References: <yOwEccFWgauV9iyfz0w5tkAvM-4CzsOaw1Yzxh8Snb0=.bfc3406a-1d82-4393-ac2d-4874761111d1@github.com>
Message-ID: <I-MEFEQ4DfLX7PFHRs-6iH3i6mMijik3l7LcqEJW81s=.42e5c054-70fb-4d9f-bef5-5883c650bebc@github.com>

On Fri, 11 Mar 2022 08:17:07 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this cleanup of `KRegister(Impl)` documentation, currently being a mix of copy&paste from `XMMRegister` and obsolete MMX support.
> 
> Testing: local compilation
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: c0e3d107
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c0e3d107f67a1a333dbe58ae745200d85764c74e
Stats:     8 lines in 1 file changed: 0 ins; 4 del; 4 mod

8283008: KRegister documentation out of date

Reviewed-by: dlong, sviswanathan, jiefu, jbhateja

-------------

PR: https://git.openjdk.java.net/jdk/pull/7784

From duke at openjdk.java.net  Mon Mar 14 09:09:47 2022
From: duke at openjdk.java.net (Ahmed Muhsin)
Date: Mon, 14 Mar 2022 09:09:47 GMT
Subject: Integrated: 8272735: Add missing SubL node transformations
In-Reply-To: <eFzwVPibLwh_XoXsOlIJQ3qjARbwXJaIVQUOcVGrznA=.7cc15e6e-3c6a-4dba-9e90-6e216874e600@github.com>
References: <eFzwVPibLwh_XoXsOlIJQ3qjARbwXJaIVQUOcVGrznA=.7cc15e6e-3c6a-4dba-9e90-6e216874e600@github.com>
Message-ID: <YV0xeCsmRFd83GP6e_X7hzjywUT1L42hESkx0Pa7MdA=.72ab86d6-329a-4410-8c4e-fc696b02f5db@github.com>

On Wed, 2 Mar 2022 21:28:13 GMT, Ahmed Muhsin <duke at openjdk.java.net> wrote:

> This change adds/enables missing subnode transformations for operations of type `long`.
> A few comments in the test file `SubINodeIdealizationTests.java` were modified to add clarity and to fix a typo.
> Hotspot:tier1 tests were run, this change does not introduce any new failures.

This pull request has now been integrated.

Changeset: 5f3d4032
Author:    Ahmed Muhsin <ahmedmuhsin at microsoft.com>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5f3d4032f3a8854f7afde28698e66a7b6684aed7
Stats:     64 lines in 3 files changed: 29 ins; 0 del; 35 mod

8272735: Add missing SubL node transformations

Reviewed-by: thartmann, chagedorn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7669

From roland at openjdk.java.net  Mon Mar 14 09:16:52 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 14 Mar 2022 09:16:52 GMT
Subject: RFR: 8282592: C2: assert(false) failed: graph should be
 schedulable [v2]
In-Reply-To: <-oXZLZYrKlxysFQgwKntZUr7dqC6G_WBEzi-ngqwqws=.c1ab815a-9065-4aba-9948-b3df225d0d3e@github.com>
References: <-oXZLZYrKlxysFQgwKntZUr7dqC6G_WBEzi-ngqwqws=.c1ab815a-9065-4aba-9948-b3df225d0d3e@github.com>
Message-ID: <rYKeXamlwlpn7dIGy99R_1KUbZaBhUkjINHzR7iDm94=.825ccf55-d66c-40ae-bbf2-2e444e71b234@github.com>

> This is another case of overunrolling that causes the type of the main
> loop's iv to conflict with a ConvI2L of an array access. Skeleton
> predicates were added to solve this family of issues. A predicate that
> should catch that the main loop is unreachable is indeed added but the
> predicate's condition doesn't constant fold.
> 
> What happens is that the main loop's iv phi initial value is a CastII
> (added by PhaseIdealLoop::cast_incr_before_loop()). That CastII is
> input to the predicates above the main loop and of the main loop's iv
> phi. Once loop opts are over, the type of the CastII is updated by
> CastIINode::Value() (the logic that looks at the test that guards the
> CastII). The type update causes the main loop iv phi's type to be
> updated and a ConvI2L to be become top. The predicate that should
> catch the overunrolling has the shape:
> 
> (CmpU (AddI#1 (CastII (AddI#2 (Phi ..) ConI#1)) ConI#2) ConI#3)
> 
> In the case of the test case:
> 
> ConI#3 = 10
> ConI#2 = 7
> ConI#1 = 1
> 
> CastII has type = int:<=max-8
> Phi has type = int:>=8
> 
> As a result:
> AddI#2 has type int
> AddI#1 has type int:min+7..max-1
> 
> The Phi is the pre loop Phi.
> 
> The fix I propose is that predicates when they are updated should skip
> over the CastII, that is in this case:
> 
> (CmpU (AddI#1 (AddI#2 (Phi ..) ConI#1) ConI#2) ConI#3)
> 
> which is reshaped to:
> 
> (CmpU (AddI#1' (Phi ..) ConI#1') ConI#3)
> 
> In this case:
> 
> ConI#1 = 4 (because the predicate constant fold in earlier passes of
> unrolling)
> 
> As a result AddI#1' still has type int But CmpUNode has special logic
> to deal with the (CmpU (AddI ...)) shape and it can determine that
> this one always fails.
> 
> The role of the CastII is to enforce the dependency between nodes in
> the loop and the the loop entry test so it's not required for
> predicates.
> 
> With that change, compiler/loopopts/TestOverunrolling.java fails
> because a predicate doesn't constant fold anymore. The reason in that
> case, is that PhaseIdealLoop::reorg_offsets() adds an Opaque2 between
> the pre loop iv phi and the predicate that hides the type of the iv
> phi. Without the change, the CastII captures the type of the iv phi
> and the Opaque2 node is added between the CastII and the pre loop iv
> phi. To solve that problem, I propose that
> PhaseIdealLoop::reorg_offsets() always add a CastII after the Opaque2
> so the type of the iv phi is not lost.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - test run failure
 - Merge branch 'master' into JDK-8282592
 - test & fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7758/files
  - new: https://git.openjdk.java.net/jdk/pull/7758/files/ef7344d1..f0ca52d7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7758&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7758&range=00-01

  Stats: 7412 lines in 314 files changed: 3737 ins; 1955 del; 1720 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7758.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7758/head:pull/7758

PR: https://git.openjdk.java.net/jdk/pull/7758

From roland at openjdk.java.net  Mon Mar 14 09:16:52 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 14 Mar 2022 09:16:52 GMT
Subject: RFR: 8282592: C2: assert(false) failed: graph should be
 schedulable
In-Reply-To: <omQutZHngo3WF_ouuPK_fhCFpqOVr8EKbB4Z-aXt0Cg=.f78b828a-eb3e-49c0-afe4-4716b317f7ea@github.com>
References: <-oXZLZYrKlxysFQgwKntZUr7dqC6G_WBEzi-ngqwqws=.c1ab815a-9065-4aba-9948-b3df225d0d3e@github.com>
 <omQutZHngo3WF_ouuPK_fhCFpqOVr8EKbB4Z-aXt0Cg=.f78b828a-eb3e-49c0-afe4-4716b317f7ea@github.com>
Message-ID: <Xbk7NERuzI5HetvAGEzIygKFamXnRNUQbi8CSirrVfQ=.cdc1ca02-0f75-4003-b242-04738b9e4b73@github.com>

On Fri, 11 Mar 2022 08:06:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Gave this a quick run through testing and `compiler/c2/irTests/TestSkeletonPredicates.java` failed with `-XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation`:

Thanks for running tests. I pushed a new commit that should fix the test failure.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7758

From aph at openjdk.java.net  Mon Mar 14 09:32:50 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 14 Mar 2022 09:32:50 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v15]
In-Reply-To: <ClrjytnyyLKM7-F3AJyWRsmfy5uQBmt6yia4yq8kk3g=.be46074b-0bf8-4b97-a7d4-fc2559b60d64@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <Iv1sKvCahNhEMUynJAFeJBvI_i9Llg1IFGuMufxHKEU=.31394133-6f11-4cdd-92a3-2d387f948936@github.com>
 <DumsZCzq7RGmmWNBnTSHpNL91DbZ93sib12cl-0dhKs=.620444b6-4692-4614-a8cd-132f0d335115@github.com>
 <ClrjytnyyLKM7-F3AJyWRsmfy5uQBmt6yia4yq8kk3g=.be46074b-0bf8-4b97-a7d4-fc2559b60d64@github.com>
Message-ID: <OaO1fJJcvhYamdUHJDUiPOWQRdsMMr_RxzGeRUdizeg=.3fc94bc0-ef2c-4312-ac8f-9564631de741@github.com>

On Sun, 13 Mar 2022 04:27:25 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4024:
>> 
>>> 4022:  * the result is equal to the value of Integer.MAX_VALUE.
>>> 4023:  */
>>> 4024: void C2_MacroAssembler::vector_cast_float_special_cases_avx(XMMRegister dst, XMMRegister src, XMMRegister xtmp1,
>> 
>> This special handling is really large, could we use a stub routine for it?
>
> Good suggestion, but as of now we are not using vector calling conventions for stubs.

I don't understand this comment. If the stub is only to be used by you, then you can determine your own calling convention.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From chagedorn at openjdk.java.net  Mon Mar 14 09:32:49 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 14 Mar 2022 09:32:49 GMT
Subject: RFR: 8282592: C2: assert(false) failed: graph should be
 schedulable [v2]
In-Reply-To: <rYKeXamlwlpn7dIGy99R_1KUbZaBhUkjINHzR7iDm94=.825ccf55-d66c-40ae-bbf2-2e444e71b234@github.com>
References: <-oXZLZYrKlxysFQgwKntZUr7dqC6G_WBEzi-ngqwqws=.c1ab815a-9065-4aba-9948-b3df225d0d3e@github.com>
 <rYKeXamlwlpn7dIGy99R_1KUbZaBhUkjINHzR7iDm94=.825ccf55-d66c-40ae-bbf2-2e444e71b234@github.com>
Message-ID: <LGLCqhzXADpTuThOPaMc9sp_AQ2dMeAwo5fjmGnxDS0=.823569da-59c9-427b-806b-97afd59fb854@github.com>

On Mon, 14 Mar 2022 09:16:52 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This is another case of overunrolling that causes the type of the main
>> loop's iv to conflict with a ConvI2L of an array access. Skeleton
>> predicates were added to solve this family of issues. A predicate that
>> should catch that the main loop is unreachable is indeed added but the
>> predicate's condition doesn't constant fold.
>> 
>> What happens is that the main loop's iv phi initial value is a CastII
>> (added by PhaseIdealLoop::cast_incr_before_loop()). That CastII is
>> input to the predicates above the main loop and of the main loop's iv
>> phi. Once loop opts are over, the type of the CastII is updated by
>> CastIINode::Value() (the logic that looks at the test that guards the
>> CastII). The type update causes the main loop iv phi's type to be
>> updated and a ConvI2L to be become top. The predicate that should
>> catch the overunrolling has the shape:
>> 
>> (CmpU (AddI#1 (CastII (AddI#2 (Phi ..) ConI#1)) ConI#2) ConI#3)
>> 
>> In the case of the test case:
>> 
>> ConI#3 = 10
>> ConI#2 = 7
>> ConI#1 = 1
>> 
>> CastII has type = int:<=max-8
>> Phi has type = int:>=8
>> 
>> As a result:
>> AddI#2 has type int
>> AddI#1 has type int:min+7..max-1
>> 
>> The Phi is the pre loop Phi.
>> 
>> The fix I propose is that predicates when they are updated should skip
>> over the CastII, that is in this case:
>> 
>> (CmpU (AddI#1 (AddI#2 (Phi ..) ConI#1) ConI#2) ConI#3)
>> 
>> which is reshaped to:
>> 
>> (CmpU (AddI#1' (Phi ..) ConI#1') ConI#3)
>> 
>> In this case:
>> 
>> ConI#1 = 4 (because the predicate constant fold in earlier passes of
>> unrolling)
>> 
>> As a result AddI#1' still has type int But CmpUNode has special logic
>> to deal with the (CmpU (AddI ...)) shape and it can determine that
>> this one always fails.
>> 
>> The role of the CastII is to enforce the dependency between nodes in
>> the loop and the the loop entry test so it's not required for
>> predicates.
>> 
>> With that change, compiler/loopopts/TestOverunrolling.java fails
>> because a predicate doesn't constant fold anymore. The reason in that
>> case, is that PhaseIdealLoop::reorg_offsets() adds an Opaque2 between
>> the pre loop iv phi and the predicate that hides the type of the iv
>> phi. Without the change, the CastII captures the type of the iv phi
>> and the Opaque2 node is added between the CastII and the pre loop iv
>> phi. To solve that problem, I propose that
>> PhaseIdealLoop::reorg_offsets() always add a CastII after the Opaque2
>> so the type of the iv phi is not lost.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - test run failure
>  - Merge branch 'master' into JDK-8282592
>  - test & fix

I've submitted some testing again.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7758

From chagedorn at openjdk.java.net  Mon Mar 14 10:11:46 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 14 Mar 2022 10:11:46 GMT
Subject: RFR: 8281322: C2: always construct strip mined loop initially
 (even if strip mining is disabled) [v4]
In-Reply-To: <Eia1OglOOzTW2plgeEpnnSVvzR0R5ar2tTz8F3VYOnw=.6bf16fe5-694f-4a61-9300-1a661242db85@github.com>
References: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
 <Eia1OglOOzTW2plgeEpnnSVvzR0R5ar2tTz8F3VYOnw=.6bf16fe5-694f-4a61-9300-1a661242db85@github.com>
Message-ID: <sOUGjHPFrXNDaDRs-vaufFY9P5LSs7aEdjxtyXw1mvk=.4edc02de-00a0-4ee5-b1ec-b93dbb66c2fb@github.com>

On Mon, 7 Mar 2022 17:18:39 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Some of the long range check transformations take advantage of the
>> safepoint captured by loop strip mining to extract jvm state (in order
>> to add back empty predicates to the inner loop of a loop nest). As a
>> consequence, irTests/TestLongRangeChecks.java fails with strip mining
>> off and users might experience performance anomalies where changing
>> GCs affect purely computational code.
>> 
>> The strip mined loop nest creation is a 2 step process:
>> 
>> 1- when a CountedLoop is created, an OuterStripMinedLoop is also added
>>   but it's not fully constructed
>> 
>> 2- at macro expansion time, the OuterStripMinedLoop is turned into an
>>   actual loop by adding Phis and a proper exit condition
>> 
>> I propose always doing 1- whether loop strip mining is enabled or
>> not. This causes the safepoint to always be captured. Loop strip ming
>> is not expected to get in the way of loop transformations so this
>> change in itself should be performance neutral. Then at 2-, if loop
>> strip mining is not enabled, the OuterStripMinedLoop can be removed
>> and the safepoint moved back into the loop in case
>> LoopStripMiningIter=1 or simply removed too.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   build fix

Apart from some minor code style things, the update looks good to me!

src/hotspot/share/opto/loopnode.cpp line 2567:

> 2565: }
> 2566: 
> 2567: void OuterStripMinedLoopNode::fix_sunk_stores(CountedLoopEndNode* inner_cle, LoopNode* target, PhaseIterGVN* igvn,

I suggest to rename `target` to `inner_cl` as we are also using `inner_cle` already. Maybe you can also add some more comments for the intermediate steps (even though most of the code was just moved in this change).

src/hotspot/share/opto/loopnode.cpp line 2579:

> 2577:         int alias_idx = igvn->C->get_alias_index(u->adr_type());
> 2578:         Node* first = u;
> 2579:         for(;;) {

Missing space after `for`.

src/hotspot/share/opto/loopnode.cpp line 2588:

> 2586:         }
> 2587:         Node* last = u;
> 2588:         for(;;) {

Missing space after `for`.

src/hotspot/share/opto/loopnode.cpp line 2651:

> 2649: #endif
> 2650:         if (phi == NULL) {
> 2651:           // If the an entire chains was sunk, the

`If the an entire chains` -> `If an entire chain`

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7364

From thartmann at openjdk.java.net  Mon Mar 14 10:38:57 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 14 Mar 2022 10:38:57 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v17]
In-Reply-To: <zyFWnsymbgIL0sdxE9QXNWQ4lnoWrjd__As3bNUV88s=.ff7fefe5-59d6-4b1a-967f-e84bfc30d5ef@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <zyFWnsymbgIL0sdxE9QXNWQ4lnoWrjd__As3bNUV88s=.ff7fefe5-59d6-4b1a-967f-e84bfc30d5ef@github.com>
Message-ID: <1J7RFTiEF7VfaEg4EF29Hwd9UUU0D1MM1xh6waG3ulY=.251d7fd9-0d1d-4288-9a55-6feca4b0ec6a@github.com>

On Sun, 13 Mar 2022 06:36:15 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
>> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279508: Windows build failure fix.

`compiler/c2/cr6340864/TestFloatVect.java` and `TestDoubleVect.java` fail on Windows:


# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000001971b940123, pid=56524, tid=57368
#
# JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-03-14-0834080.tobias.hartmann.jdk2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-03-14-0834080.tobias.hartmann.jdk2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
# Problematic frame:
# J 205 c2 compiler.c2.cr6340864.TestFloatVect.test_round([I[F)V (24 bytes) @ 0x000001971b940123 [0x000001971b93ffe0+0x0000000000000143]

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From jbhateja at openjdk.java.net  Mon Mar 14 12:11:49 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 14 Mar 2022 12:11:49 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v15]
In-Reply-To: <OaO1fJJcvhYamdUHJDUiPOWQRdsMMr_RxzGeRUdizeg=.3fc94bc0-ef2c-4312-ac8f-9564631de741@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <Iv1sKvCahNhEMUynJAFeJBvI_i9Llg1IFGuMufxHKEU=.31394133-6f11-4cdd-92a3-2d387f948936@github.com>
 <DumsZCzq7RGmmWNBnTSHpNL91DbZ93sib12cl-0dhKs=.620444b6-4692-4614-a8cd-132f0d335115@github.com>
 <ClrjytnyyLKM7-F3AJyWRsmfy5uQBmt6yia4yq8kk3g=.be46074b-0bf8-4b97-a7d4-fc2559b60d64@github.com>
 <OaO1fJJcvhYamdUHJDUiPOWQRdsMMr_RxzGeRUdizeg=.3fc94bc0-ef2c-4312-ac8f-9564631de741@github.com>
Message-ID: <8IP7JMUqOWwCVaV3-hf42ovowPNRAEDQRrkzLf-z2yg=.5f4f5350-711b-411d-bcb5-45911fd901d7@github.com>

On Mon, 14 Mar 2022 09:29:28 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Good suggestion, but as of now we are not using vector calling conventions for stubs.
>
> I don't understand this comment. If the stub is only to be used by you, then you can determine your own calling convention.

We are passing mixture of scalar, vector and opmask register to special handling function, only way we can pass them reliably to callee stub without having an elaborate mixed calling convention will be by bounding the machine operands.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From roland at openjdk.java.net  Mon Mar 14 13:05:10 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 14 Mar 2022 13:05:10 GMT
Subject: RFR: 8281322: C2: always construct strip mined loop initially
 (even if strip mining is disabled) [v5]
In-Reply-To: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
References: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
Message-ID: <gTpxW90UuCOy12xwv1RubYSIXqGEdPshzsMJcMMi6lw=.abea74a2-8f2f-4b9b-bbcb-56b213acc7b2@github.com>

> Some of the long range check transformations take advantage of the
> safepoint captured by loop strip mining to extract jvm state (in order
> to add back empty predicates to the inner loop of a loop nest). As a
> consequence, irTests/TestLongRangeChecks.java fails with strip mining
> off and users might experience performance anomalies where changing
> GCs affect purely computational code.
> 
> The strip mined loop nest creation is a 2 step process:
> 
> 1- when a CountedLoop is created, an OuterStripMinedLoop is also added
>   but it's not fully constructed
> 
> 2- at macro expansion time, the OuterStripMinedLoop is turned into an
>   actual loop by adding Phis and a proper exit condition
> 
> I propose always doing 1- whether loop strip mining is enabled or
> not. This causes the safepoint to always be captured. Loop strip ming
> is not expected to get in the way of loop transformations so this
> change in itself should be performance neutral. Then at 2-, if loop
> strip mining is not enabled, the OuterStripMinedLoop can be removed
> and the safepoint moved back into the loop in case
> LoopStripMiningIter=1 or simply removed too.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - review
 - Merge branch 'master' into JDK-8281322
 - build fix
 - Merge branch 'master' into JDK-8281322
 - more
 - Merge branch 'master' into JDK-8281322
 - more
 - cleanup
 - merge fix
 - Merge branch 'master' into JDK-8281322
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/fde31498...8e257d4c

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7364/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7364&range=04
  Stats: 481 lines in 4 files changed: 291 ins; 185 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7364.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7364/head:pull/7364

PR: https://git.openjdk.java.net/jdk/pull/7364

From roland at openjdk.java.net  Mon Mar 14 13:05:12 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 14 Mar 2022 13:05:12 GMT
Subject: RFR: 8281322: C2: always construct strip mined loop initially
 (even if strip mining is disabled) [v4]
In-Reply-To: <sOUGjHPFrXNDaDRs-vaufFY9P5LSs7aEdjxtyXw1mvk=.4edc02de-00a0-4ee5-b1ec-b93dbb66c2fb@github.com>
References: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
 <Eia1OglOOzTW2plgeEpnnSVvzR0R5ar2tTz8F3VYOnw=.6bf16fe5-694f-4a61-9300-1a661242db85@github.com>
 <sOUGjHPFrXNDaDRs-vaufFY9P5LSs7aEdjxtyXw1mvk=.4edc02de-00a0-4ee5-b1ec-b93dbb66c2fb@github.com>
Message-ID: <NxCoG4UUPIwGExqfMNu99DiD-g-GW1dzPTZSVTZ0vtw=.20c20038-2b89-4bc4-b55d-29e3fd77cb86@github.com>

On Mon, 14 Mar 2022 10:08:17 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> Apart from some minor code style things, the update looks good to me!

Thanks. The new commit should take care of your comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7364

From aoqi at openjdk.java.net  Mon Mar 14 13:18:02 2022
From: aoqi at openjdk.java.net (Ao Qi)
Date: Mon, 14 Mar 2022 13:18:02 GMT
Subject: RFR: 8283103: compiler/vectorapi/TestMaskedMacroLogicVector.java
 failed due to incorrect os.simpleArch on some platforms
Message-ID: <CjftfHfXuWLRaNkh5cKNxlCYYDJpimyQSr5R_3q_1TE=.a8eca94a-8c22-4523-94d9-4cb62b1b706c@github.com>

`os.simpleArch` is not set correctly on some platforms, for example on loongarch64 and mips64 ([CODETOOLS-7903120](https://bugs.openjdk.java.net/browse/CODETOOLS-7903120)). This issue aims to let the test work on these platforms.

-------------

Commit messages:
 - 8283103: compiler/vectorapi/TestMaskedMacroLogicVector.java failed due to incorrect os.simpleArch on some platforms

Changes: https://git.openjdk.java.net/jdk/pull/7809/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7809&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283103
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7809.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7809/head:pull/7809

PR: https://git.openjdk.java.net/jdk/pull/7809

From aoqi at openjdk.java.net  Mon Mar 14 13:33:40 2022
From: aoqi at openjdk.java.net (Ao Qi)
Date: Mon, 14 Mar 2022 13:33:40 GMT
Subject: RFR: 8283103: compiler/vectorapi/TestMaskedMacroLogicVector.java
 failed due to incorrect os.simpleArch on some platforms
In-Reply-To: <CjftfHfXuWLRaNkh5cKNxlCYYDJpimyQSr5R_3q_1TE=.a8eca94a-8c22-4523-94d9-4cb62b1b706c@github.com>
References: <CjftfHfXuWLRaNkh5cKNxlCYYDJpimyQSr5R_3q_1TE=.a8eca94a-8c22-4523-94d9-4cb62b1b706c@github.com>
Message-ID: <tF0d8qIVlLgAgkfbtP9F_CCTBtAgow-6A_HIMXNbY74=.cd775a89-a9aa-4f12-bc24-c644109b137a@github.com>

On Mon, 14 Mar 2022 13:10:55 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> `os.simpleArch` is not set correctly on some platforms, for example on loongarch64 and mips64 ([CODETOOLS-7903120](https://bugs.openjdk.java.net/browse/CODETOOLS-7903120)). This issue aims to let the test work on these platforms.

Sorry. The current patch is incorrect, I will do more investigation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7809

From aoqi at openjdk.java.net  Mon Mar 14 13:38:19 2022
From: aoqi at openjdk.java.net (Ao Qi)
Date: Mon, 14 Mar 2022 13:38:19 GMT
Subject: RFR: 8283103: compiler/vectorapi/TestMaskedMacroLogicVector.java
 failed due to incorrect os.simpleArch on some platforms [v2]
In-Reply-To: <CjftfHfXuWLRaNkh5cKNxlCYYDJpimyQSr5R_3q_1TE=.a8eca94a-8c22-4523-94d9-4cb62b1b706c@github.com>
References: <CjftfHfXuWLRaNkh5cKNxlCYYDJpimyQSr5R_3q_1TE=.a8eca94a-8c22-4523-94d9-4cb62b1b706c@github.com>
Message-ID: <JkN_rHWJAtMr797VZFYi4MtC7pv4Te0cAK_V3vFlWdc=.7320b329-09c6-4400-b2ac-8239a6498ab4@github.com>

> `os.simpleArch` is not set correctly on some platforms, for example on loongarch64 and mips64 ([CODETOOLS-7903120](https://bugs.openjdk.java.net/browse/CODETOOLS-7903120)). This issue aims to let the test work on these platforms.

Ao Qi has updated the pull request incrementally with one additional commit since the last revision:

  use vm.cpu.features

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7809/files
  - new: https://git.openjdk.java.net/jdk/pull/7809/files/30409bb1..bb4387ba

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7809&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7809&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7809.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7809/head:pull/7809

PR: https://git.openjdk.java.net/jdk/pull/7809

From chagedorn at openjdk.java.net  Mon Mar 14 14:01:53 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 14 Mar 2022 14:01:53 GMT
Subject: RFR: 8281322: C2: always construct strip mined loop initially
 (even if strip mining is disabled) [v5]
In-Reply-To: <gTpxW90UuCOy12xwv1RubYSIXqGEdPshzsMJcMMi6lw=.abea74a2-8f2f-4b9b-bbcb-56b213acc7b2@github.com>
References: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
 <gTpxW90UuCOy12xwv1RubYSIXqGEdPshzsMJcMMi6lw=.abea74a2-8f2f-4b9b-bbcb-56b213acc7b2@github.com>
Message-ID: <iXjeDssUMsMPJaRNeYvxSlXc3Pen9d6Dgv383RxKgS8=.ca5a21ce-30fb-45a1-8732-6855e70153b8@github.com>

On Mon, 14 Mar 2022 13:05:10 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Some of the long range check transformations take advantage of the
>> safepoint captured by loop strip mining to extract jvm state (in order
>> to add back empty predicates to the inner loop of a loop nest). As a
>> consequence, irTests/TestLongRangeChecks.java fails with strip mining
>> off and users might experience performance anomalies where changing
>> GCs affect purely computational code.
>> 
>> The strip mined loop nest creation is a 2 step process:
>> 
>> 1- when a CountedLoop is created, an OuterStripMinedLoop is also added
>>   but it's not fully constructed
>> 
>> 2- at macro expansion time, the OuterStripMinedLoop is turned into an
>>   actual loop by adding Phis and a proper exit condition
>> 
>> I propose always doing 1- whether loop strip mining is enabled or
>> not. This causes the safepoint to always be captured. Loop strip ming
>> is not expected to get in the way of loop transformations so this
>> change in itself should be performance neutral. Then at 2-, if loop
>> strip mining is not enabled, the OuterStripMinedLoop can be removed
>> and the safepoint moved back into the loop in case
>> LoopStripMiningIter=1 or simply removed too.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - review
>  - Merge branch 'master' into JDK-8281322
>  - build fix
>  - Merge branch 'master' into JDK-8281322
>  - more
>  - Merge branch 'master' into JDK-8281322
>  - more
>  - cleanup
>  - merge fix
>  - Merge branch 'master' into JDK-8281322
>  - ... and 7 more: https://git.openjdk.java.net/jdk/compare/fde31498...8e257d4c

Thanks for the updates, looks good!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7364

From roland at openjdk.java.net  Mon Mar 14 14:01:53 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 14 Mar 2022 14:01:53 GMT
Subject: RFR: 8281322: C2: always construct strip mined loop initially
 (even if strip mining is disabled)
In-Reply-To: <U5mhGwub7FLr-KdEUBnW4nhMucQneRs_i-cAtJQS1AE=.bd326571-d143-4f81-802b-0cf236676848@github.com>
References: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
 <U5mhGwub7FLr-KdEUBnW4nhMucQneRs_i-cAtJQS1AE=.bd326571-d143-4f81-802b-0cf236676848@github.com>
Message-ID: <rJvh1xhTEDmWY5LQ-cDIzhQgyCEpMd_rTsDXQxTAzzA=.10fe2905-7f59-47e3-a792-8bde062d36e1@github.com>

On Fri, 11 Feb 2022 10:05:44 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Some of the long range check transformations take advantage of the
>> safepoint captured by loop strip mining to extract jvm state (in order
>> to add back empty predicates to the inner loop of a loop nest). As a
>> consequence, irTests/TestLongRangeChecks.java fails with strip mining
>> off and users might experience performance anomalies where changing
>> GCs affect purely computational code.
>> 
>> The strip mined loop nest creation is a 2 step process:
>> 
>> 1- when a CountedLoop is created, an OuterStripMinedLoop is also added
>>   but it's not fully constructed
>> 
>> 2- at macro expansion time, the OuterStripMinedLoop is turned into an
>>   actual loop by adding Phis and a proper exit condition
>> 
>> I propose always doing 1- whether loop strip mining is enabled or
>> not. This causes the safepoint to always be captured. Loop strip ming
>> is not expected to get in the way of loop transformations so this
>> change in itself should be performance neutral. Then at 2-, if loop
>> strip mining is not enabled, the OuterStripMinedLoop can be removed
>> and the safepoint moved back into the loop in case
>> LoopStripMiningIter=1 or simply removed too.
>
> For the record: Christian's testing found issues (he reported them to Roland already).
> 
> I think it would be good to change the bug title to something more descriptive.

@TobiHartmann @chhagedorn thanks for the reviews

-------------

PR: https://git.openjdk.java.net/jdk/pull/7364

From roland at openjdk.java.net  Mon Mar 14 14:01:55 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 14 Mar 2022 14:01:55 GMT
Subject: Integrated: 8281322: C2: always construct strip mined loop initially
 (even if strip mining is disabled)
In-Reply-To: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
References: <_Z1-aiZ0vKRmkdhXyq-FP0KQXq4xTuDBVWwRtzFfy4Y=.8991d95a-0de2-4b63-86ef-3d8c701fdfa4@github.com>
Message-ID: <IXy0Nv52aMc5vT7qPweQqlGD_e7WCLAVy5m_h_9CRAA=.a82b7cd2-17ed-4752-bfae-fd27d7d26d1b@github.com>

On Mon, 7 Feb 2022 08:53:41 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Some of the long range check transformations take advantage of the
> safepoint captured by loop strip mining to extract jvm state (in order
> to add back empty predicates to the inner loop of a loop nest). As a
> consequence, irTests/TestLongRangeChecks.java fails with strip mining
> off and users might experience performance anomalies where changing
> GCs affect purely computational code.
> 
> The strip mined loop nest creation is a 2 step process:
> 
> 1- when a CountedLoop is created, an OuterStripMinedLoop is also added
>   but it's not fully constructed
> 
> 2- at macro expansion time, the OuterStripMinedLoop is turned into an
>   actual loop by adding Phis and a proper exit condition
> 
> I propose always doing 1- whether loop strip mining is enabled or
> not. This causes the safepoint to always be captured. Loop strip ming
> is not expected to get in the way of loop transformations so this
> change in itself should be performance neutral. Then at 2-, if loop
> strip mining is not enabled, the OuterStripMinedLoop can be removed
> and the safepoint moved back into the loop in case
> LoopStripMiningIter=1 or simply removed too.

This pull request has now been integrated.

Changeset: ea9eeea8
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ea9eeea8ffea6ed32a270051c6986f4f059943c0
Stats:     481 lines in 4 files changed: 291 ins; 185 del; 5 mod

8281322: C2: always construct strip mined loop initially (even if strip mining is disabled)

Reviewed-by: chagedorn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7364

From dnsimon at openjdk.java.net  Mon Mar 14 14:05:50 2022
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Mon, 14 Mar 2022 14:05:50 GMT
Subject: RFR: 8283056: show abstract machine code for all VM crashes
In-Reply-To: <jIWzucRIDkTcO64uelotQb77Rtx1t_IQ72toaAzNjkc=.7ac11ba3-4595-4be8-8c4d-e5733ef01ab1@github.com>
References: <kKS2Tk_nZOc6NXbUOuluZ6IGvrUrZY9IRh5tT7BSb70=.4ad088ee-ba8d-4ab6-9132-bae951036bba@github.com>
 <yHSC3bjUUS--PwyQyUrZ8QW9iVcipFbuc3lDOyLCf2o=.cf7847fa-fd79-4705-82ec-324825a9fd25@github.com>
 <jIWzucRIDkTcO64uelotQb77Rtx1t_IQ72toaAzNjkc=.7ac11ba3-4595-4be8-8c4d-e5733ef01ab1@github.com>
Message-ID: <H8fivIakZZZT_KivpkXKLFXWweILyZNeiBzUKcusiOg=.74aa795e-b079-4073-8a61-9403d61beec5@github.com>

On Mon, 14 Mar 2022 06:03:43 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> What about using -XX:CICrashAt and other flags that trigger asserts

`CICrashAt` triggers an assertion during compilation where as I need an assertion or guarantee in VM code called from JIT compiled code. To be completely reliable, this needs a runtime entry point to `assert`, `guarantee` or `fatal` that can be called from compiled code. JVMCI has such an entry point for `fatal` (`JVMCIRuntime::vm_message`) but without Graal in the JDK, it's hard to write a test that uses it. I've done such testing manually so am confident that it works.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7791

From duke at openjdk.java.net  Mon Mar 14 16:39:01 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Mon, 14 Mar 2022 16:39:01 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) + con
Message-ID: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>

Hello,

`x + (con - y)  -> (x - y) + con` is a widely seen pattern; however it is missing in current implementation, which prevents some obvious constant folding from happening, such as `x + (1 - y) + 2` will be not optimized at all, rather than into `x - y + 3`.

This pull request adds this transformation.

-------------

Commit messages:
 - Merge master.
 - include transformation from (con - y) + x into (x - y) + con and x + (con - y) into (x - y) + con.

Changes: https://git.openjdk.java.net/jdk/pull/7795/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7795&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283094
  Stats: 214 lines in 4 files changed: 214 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7795/head:pull/7795

PR: https://git.openjdk.java.net/jdk/pull/7795

From duke at openjdk.java.net  Mon Mar 14 16:39:02 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 14 Mar 2022 16:39:02 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con
In-Reply-To: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
Message-ID: <MRdZSFcQFXaTh1k3x0y_grTFweY7ClildBdyQ7Mwi7U=.8efcf85b-73e4-45fc-be1b-d9591ad7078c@github.com>

On Fri, 11 Mar 2022 23:40:19 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

> Hello,
> 
> `x + (con - y)  -> (x - y) + con` is a widely seen pattern; however it is missing in current implementation, which prevents some obvious constant folding from happening, such as `x + (1 - y) + 2` will be not optimized at all, rather than into `x - y + 3`.
> 
> This pull request adds this transformation.

I think I have a better idea for this. During idealisation, we will transform every subtraction into an addition with the negation of the second operand, pushing the negation down the computation graph. This will simplify numerous rules we have with subtractions. Addition presents nice commutative and associative properties so the graph transformation during idealisation with be much easier. Before matching, we may have another strength reduction phase which will push the negations up the computation graph, transform the computations to be as compact as possible.

This problem seems a lot like the problem we face in #7700 when eagerly strength reducing operations hurt our ability to perform other transformations by complicating the elements inside the graph. I believe this solution would simplify our arithmetic transformations and allow better numeric calculations. Similar to what has been discussed in #7395 , a more general solution would be much more valuable than trying to match every possible combinations.

Thank you very much.

That is what I mean by saying that careless strength reduction restricts our ability to perform more efficient transformations. What I propose is we delay your mentioned transformation after idealisation has settled on the whole graph.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7795

From jwaters at openjdk.java.net  Mon Mar 14 16:39:04 2022
From: jwaters at openjdk.java.net (Julian Waters)
Date: Mon, 14 Mar 2022 16:39:04 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con
In-Reply-To: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
Message-ID: <CWomneGbWwCik2qvPPxeQAhq_plyxHjSN2n8KilMJKw=.47adc4e9-4be1-4c6d-9bfc-34d421b53696@github.com>

On Fri, 11 Mar 2022 23:40:19 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

> Hello,
> 
> `x + (con - y)  -> (x - y) + con` is a widely seen pattern; however it is missing in current implementation, which prevents some obvious constant folding from happening, such as `x + (1 - y) + 2` will be not optimized at all, rather than into `x - y + 3`.
> 
> This pull request adds this transformation.

I share the same opinion that John has from the linked https://github.com/openjdk/jdk/pull/7395, to me it would be better if we would combine all these operations into a single method that can then decide on the specific optimization after analysis. This would also have the added bonus that related optimizations in the future could then leverage this framework and have an easier time implementing what they'd like to do. This may or may not require changes to C1 and the Interpreter to gather all the extra profiling information needed, I can't be the judge of that given my relative inexperience with C2.

The only thing I'm unsure about is whether all the previous optimizations before this are all scattered across C2 or whether they all share variations of the same calculation, because we could take advantage of existing code if it's the latter. @merykitty would it be feasible to search for all of them in the C2 codebase?

Should I create a JBS issue for this PR?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7795

From duke at openjdk.java.net  Mon Mar 14 16:39:05 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Mon, 14 Mar 2022 16:39:05 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con
In-Reply-To: <MRdZSFcQFXaTh1k3x0y_grTFweY7ClildBdyQ7Mwi7U=.8efcf85b-73e4-45fc-be1b-d9591ad7078c@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
 <MRdZSFcQFXaTh1k3x0y_grTFweY7ClildBdyQ7Mwi7U=.8efcf85b-73e4-45fc-be1b-d9591ad7078c@github.com>
Message-ID: <HF7LE-Kg8MBjmKGZPb4iqec9vuK0M5AZmVyztvE2PdA=.c8d28951-fa03-4572-8ab4-880bed71de1d@github.com>

On Sat, 12 Mar 2022 07:44:09 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> `x + (con - y)  -> (x - y) + con` is a widely seen pattern; however it is missing in current implementation, which prevents some obvious constant folding from happening, such as `x + (1 - y) + 2` will be not optimized at all, rather than into `x - y + 3`.
>> 
>> This pull request adds this transformation.
>
> I think I have a better idea for this. During idealisation, we will transform every subtraction into an addition with the negation of the second operand, pushing the negation down the computation graph. This will simplify numerous rules we have with subtractions. Addition presents nice commutative and associative properties so the graph transformation during idealisation with be much easier. Before matching, we may have another strength reduction phase which will push the negations up the computation graph, transform the computations to be as compact as possible.
> 
> This problem seems a lot like the problem we face in #7700 when eagerly strength reducing operations hurt our ability to perform other transformations by complicating the elements inside the graph. I believe this solution would simplify our arithmetic transformations and allow better numeric calculations. Similar to what has been discussed in #7395 , a more general solution would be much more valuable than trying to match every possible combinations.
> 
> Thank you very much.

@merykitty Thank you for your quick response. I agree a general solution is better and I also think addition is generally easier to optimize than subtraction. However considering this case, I noticed there are some existing transformation that does not follow this: for example https://github.com/openjdk/jdk/blob/5c408c1410e15087f735a815b7edc716d514b1b3/src/hotspot/share/opto/addnode.cpp#L307, which seems doing exactly the opposite thing.

Does the transformation hold all the time?
>During idealisation, we will transform every subtraction into an addition with the negation of the second operand, pushing the negation down the computation graph.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7795

From duke at openjdk.java.net  Mon Mar 14 18:25:05 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 14 Mar 2022 18:25:05 GMT
Subject: RFR: 8283122: [AIX, s390] UnsafeCopyMemory 'Mismatched' Tests Fail on
 Big Endian Systems
Message-ID: <cdQZg8cHGBnBlCcDG53z2-xzibPwq4zu2SFyOkXYsbU=.99cb9d2f-77a7-450b-9ea7-f5c16fc7a165@github.com>

This is a testbug present on big endian systems. UnsafeCopyMemory.java contains a few tests with 'mismatched' source and destination size. These tests use Unsafe.copyMemory to copy 4 bytes between longs and ints. The location of the bytes to be copied (if the copy comes from a long), or the offset into which the bytes should be copied (if the copy is into a long) are different on big and little endian systems.

Copying from a long to int on a little endian system, the bytes to be copied are those present at the long's address.


src: _ _ _ _ | _ _ _ _
     ^ ~ ~ ^ LE copy
dst: _ _ _ _


On BE systems, the bytes are offset by 4.


src: _ _ _ _ | _ _ _ _
               ^ ~ ~ ^ BE copy
dst: _ _ _ _


The situation for copying into a long from an int is analogous.

This PR adds the required offset for the 'mismatched copy' tests. With this change, UnsafeCopyMemory.java now passes on AIX and s390.

-------------

Commit messages:
 - Fixes endianess-related testbug in UnsafeCopyMemory.java

Changes: https://git.openjdk.java.net/jdk/pull/7811/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7811&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283122
  Stats: 12 lines in 1 file changed: 10 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7811.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7811/head:pull/7811

PR: https://git.openjdk.java.net/jdk/pull/7811

From duke at openjdk.java.net  Mon Mar 14 20:24:08 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Mon, 14 Mar 2022 20:24:08 GMT
Subject: RFR: 8283122: [AIX, s390] UnsafeCopyMemory 'Mismatched' Tests Fail
 on Big Endian Systems [v2]
In-Reply-To: <cdQZg8cHGBnBlCcDG53z2-xzibPwq4zu2SFyOkXYsbU=.99cb9d2f-77a7-450b-9ea7-f5c16fc7a165@github.com>
References: <cdQZg8cHGBnBlCcDG53z2-xzibPwq4zu2SFyOkXYsbU=.99cb9d2f-77a7-450b-9ea7-f5c16fc7a165@github.com>
Message-ID: <FRFoPa-p7cWb82EHao1SdrYBFeZKWidZBcFbWk3wmtE=.4f2639c3-9f99-4ea3-8a91-c0155fc7b15a@github.com>

> This is a testbug present on big endian systems. UnsafeCopyMemory.java contains a few tests with 'mismatched' source and destination size. These tests use Unsafe.copyMemory to copy 4 bytes between longs and ints. The location of the bytes to be copied (if the copy comes from a long), or the offset into which the bytes should be copied (if the copy is into a long) are different on big and little endian systems.
> 
> Copying from a long to int on a little endian system, the bytes to be copied are those present at the long's address.
> 
> 
> src: _ _ _ _ | _ _ _ _
>      ^ ~ ~ ^ LE copy
> dst: _ _ _ _
> 
> 
> On BE systems, the bytes are offset by 4.
> 
> 
> src: _ _ _ _ | _ _ _ _
>                ^ ~ ~ ^ BE copy
> dst: _ _ _ _
> 
> 
> The situation for copying into a long from an int is analogous.
> 
> This PR adds the required offset for the 'mismatched copy' tests. With this change, UnsafeCopyMemory.java now passes on AIX and s390.

Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  Fixes endianess-related testbug in UnsafeCopyMemory.java

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7811/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7811&range=01
  Stats: 12 lines in 1 file changed: 10 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7811.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7811/head:pull/7811

PR: https://git.openjdk.java.net/jdk/pull/7811

From manc at openjdk.java.net  Mon Mar 14 22:27:29 2022
From: manc at openjdk.java.net (Man Cao)
Date: Mon, 14 Mar 2022 22:27:29 GMT
Subject: RFR: 8282507: Add LICENSE file for hsdis [v2]
In-Reply-To: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
References: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
Message-ID: <5MyWrnj3HJn4PMSxWXAUif2iD-EZex66QsQodlpAEbg=.6fb6a285-3d80-4e4c-b5ad-0b5589ba04d9@github.com>

> Hi all,
> 
> Could anyone help review the addition of LICENSE file to hsdis directory?
> 
> -Man

Man Cao has updated the pull request incrementally with one additional commit since the last revision:

  Rename license file to hsdis-license.txt

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7649/files
  - new: https://git.openjdk.java.net/jdk/pull/7649/files/d2a940fd..ebe23827

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7649&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7649&range=00-01

  Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7649.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7649/head:pull/7649

PR: https://git.openjdk.java.net/jdk/pull/7649

From manc at openjdk.java.net  Mon Mar 14 22:54:46 2022
From: manc at openjdk.java.net (Man Cao)
Date: Mon, 14 Mar 2022 22:54:46 GMT
Subject: RFR: 8282507: Add a separate license file for hsdis [v2]
In-Reply-To: <5MyWrnj3HJn4PMSxWXAUif2iD-EZex66QsQodlpAEbg=.6fb6a285-3d80-4e4c-b5ad-0b5589ba04d9@github.com>
References: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
 <5MyWrnj3HJn4PMSxWXAUif2iD-EZex66QsQodlpAEbg=.6fb6a285-3d80-4e4c-b5ad-0b5589ba04d9@github.com>
Message-ID: <w2TnEZkwaYAQr8D0reXxh1SD3u72CTjHnG1V0SkbxyQ=.b7ad2fea-ceb5-4535-a70d-4c86c2c12c68@github.com>

On Mon, 14 Mar 2022 22:27:29 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone help review the addition of LICENSE file to hsdis directory?
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename license file to hsdis-license.txt

Thank you for helping navigate through this situation! I surely do not want to drag you into the complex legal approval process. Also same here, as an engineer and not a lawyer, my comments are only based on my observations and understandings, and have no legal guarantee.

Renaming to "hsdis-license.txt" works perfectly fine for our script and tool. I renamed the file and updated RFE and PR. Let me know if we can submit this. If you still need to go through legal approval, then I'll abandon this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7649

From sviswanathan at openjdk.java.net  Tue Mar 15 00:18:47 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 15 Mar 2022 00:18:47 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v12]
In-Reply-To: <ipzQF1uR_cuz1f7hI8RZ1HhokXaf6VGYGhx58h2VVQQ=.78863db8-b67f-4835-af92-e32c1a524353@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <ipzQF1uR_cuz1f7hI8RZ1HhokXaf6VGYGhx58h2VVQQ=.78863db8-b67f-4835-af92-e32c1a524353@github.com>
Message-ID: <Q4bArNqD-6L2JzknwfjqTK3Vd8oP7reAQL3ureC0wCc=.f6661092-26cd-4890-9afb-68e80aa95b45@github.com>

On Sat, 12 Mar 2022 04:52:41 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into leaIns
>  - reviews
>  - remove unreached rules
>  - remove 0x67 prefix
>  - address reviews
>  - remove irrelevent changes
>  - reviews
>  - address reviews
>  - add benchmark
>  - add predicate
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/3a0ad3f4...e0fd81f6

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7560

From sviswanathan at openjdk.java.net  Tue Mar 15 00:18:47 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 15 Mar 2022 00:18:47 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v10]
In-Reply-To: <St_Eey566HKUKt0_RKDIve5z3WKnAOwDbiBopp8_nSU=.8eb66e07-e117-4b11-8bd5-8c6d86ee5484@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <cdQ7cLMPxxW0p-nK1DdHcQTrfouGC2kvXjSiDxHiMTw=.753e3892-e538-4890-a9f0-dd493d5fbf78@github.com>
 <St_Eey566HKUKt0_RKDIve5z3WKnAOwDbiBopp8_nSU=.8eb66e07-e117-4b11-8bd5-8c6d86ee5484@github.com>
Message-ID: <DuNfU8AqV0owpynmNVAAwtQ7MjytTh6Hjci6eji6dCQ=.f94dc6ad-3f60-4d15-b8d5-a801a51830cd@github.com>

On Thu, 10 Mar 2022 13:25:32 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unreached rules
>
> It would be good if someone from Intel (@sviswa7, @jatin-bhateja) could look at this as well.

@TobiHartmann Could you please run this through your tests?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From dlong at openjdk.java.net  Tue Mar 15 00:26:14 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 15 Mar 2022 00:26:14 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity" [v3]
In-Reply-To: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
Message-ID: <rNWmcAZ05DXjShQlSoWffd-GPSxe-bj7YEX-UKj9p4c=.d1a26a69-7b21-4f20-8254-e7784f2d537e@github.com>

> This change adds extra stub space for large values of CodeEntryAlignment, and it changes the test to try large values of CodeEntryAlignment.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  rename max_stubs --> max_aligned_stubs, update copyright year

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7800/files
  - new: https://git.openjdk.java.net/jdk/pull/7800/files/e72382ef..89f9c6c4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7800&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7800&range=01-02

  Stats: 6 lines in 2 files changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7800.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7800/head:pull/7800

PR: https://git.openjdk.java.net/jdk/pull/7800

From jiefu at openjdk.java.net  Tue Mar 15 01:15:45 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 15 Mar 2022 01:15:45 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity" [v3]
In-Reply-To: <rNWmcAZ05DXjShQlSoWffd-GPSxe-bj7YEX-UKj9p4c=.d1a26a69-7b21-4f20-8254-e7784f2d537e@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
 <rNWmcAZ05DXjShQlSoWffd-GPSxe-bj7YEX-UKj9p4c=.d1a26a69-7b21-4f20-8254-e7784f2d537e@github.com>
Message-ID: <zp_PFBMkkLEH8hwwSfhJzWNzKXAolLlPS3Snj_Hgt-U=.15b23250-cb08-48de-9e47-681038826827@github.com>

On Tue, 15 Mar 2022 00:26:14 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This change adds extra stub space for large values of CodeEntryAlignment, and it changes the test to try large values of CodeEntryAlignment.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename max_stubs --> max_aligned_stubs, update copyright year

Marked as reviewed by jiefu (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7800

From xgong at openjdk.java.net  Tue Mar 15 01:18:46 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 15 Mar 2022 01:18:46 GMT
Subject: RFR: 8282162: [vector] Optimize vector negation API
In-Reply-To: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
Message-ID: <eIu6TxkGWuCoHVGsuFZ1iJZOzVWrTcdxITrJfXgNGhI=.3ea03409-a9e5-4a0b-8cf3-ff76322e027b@github.com>

On Fri, 11 Mar 2022 06:29:22 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE.
> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern.
> 
> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture:
>   - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation.
>   - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`.
> 
> So with this patch, the following transformations are applied:
> 
> For non-masked negation with NEON:
> 
>   movi    v16.4s, #0x0
>   sub v17.4s, v16.4s, v17.4s       ==> neg v17.4s, v17.4s
> 
> and with SVE:
> 
>   mov z16.s, #0
>   sub z18.s, z16.s, z17.s          ==> neg z16.s, p7/m, z16.s
> 
> For masked negation with NEON:
> 
>   movi    v17.4s, #0x1
>   mvn v19.16b, v18.16b
>   mov v20.16b, v16.16b             ==>  neg v18.4s, v17.4s
>   bsl v20.16b, v19.16b, v18.16b         bsl v19.16b, v18.16b, v17.16b
>   add v19.4s, v20.4s, v17.4s
>   mov v18.16b, v16.16b
>   bsl v18.16b, v19.16b, v20.16b
> 
> and with SVE:
> 
>   mov z16.s, #-1
>   mov z17.s, #1                    ==> neg z16.s, p0/m, z16.s
>   eor z18.s, p0/m, z18.s, z16.s
>   add z18.s, p0/m, z18.s, z17.s
> 
> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed):
> 
> NEON:
> Benchmark                Gain
> Byte128Vector.NEG        1.029
> Byte128Vector.NEGMasked  1.757
> Short128Vector.NEG       1.041
> Short128Vector.NEGMasked 1.659
> Int128Vector.NEG         1.005
> Int128Vector.NEGMasked   1.513
> Long128Vector.NEG        1.003
> Long128Vector.NEGMasked  1.878
> 
> SVE with 512-bits:
> Benchmark                Gain
> ByteMaxVector.NEG        1.10
> ByteMaxVector.NEGMasked  1.165
> ShortMaxVector.NEG       1.056
> ShortMaxVector.NEGMasked 1.195
> IntMaxVector.NEG         1.002
> IntMaxVector.NEGMasked   1.239
> LongMaxVector.NEG        1.031
> LongMaxVector.NEGMasked  1.191
> 
> X86 (non AVX-512):
> Benchmark                Gain
> ByteMaxVector.NEGMasked  1.254
> ShortMaxVector.NEGMasked 1.359
> IntMaxVector.NEGMasked   1.431
> LongMaxVector.NEGMasked  1.989
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896

Hi, could anyone please take a look at this PR? Thanks so much!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From xgong at openjdk.java.net  Tue Mar 15 01:24:36 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 15 Mar 2022 01:24:36 GMT
Subject: RFR: 8282431: AArch64: Add optimized rules for masked vector
 multiply-add/sub for SVE [v2]
In-Reply-To: <SW3zLs9MPHtWkj6c9SdEFOUaCjAIQ6wpAoTF6gaY80I=.89ff44d1-db70-4c82-ad88-02e1e49bff63@github.com>
References: <bRRrWEoEmJk24aLM-eRglGGIttZ2eAIBexmskoh4tdw=.34cca7f0-92b5-4e02-9019-036a29dfc066@github.com>
 <SW3zLs9MPHtWkj6c9SdEFOUaCjAIQ6wpAoTF6gaY80I=.89ff44d1-db70-4c82-ad88-02e1e49bff63@github.com>
Message-ID: <-wewaX6KkjspudIZJDr5QtWKBKnbdfTS93XDCvbGB4A=.59094529-7df8-4964-a552-1be3315d8ece@github.com>

On Thu, 10 Mar 2022 07:55:15 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> We have the optimized match rules for vector `"fmls,fnmla,fnmls,mla,mls"` for ARM SVE. Similarly we can also add the rules for the relative masked operations to generate the optimized predicated instructions.
>> 
>> With this patch the following masked vector multiply-add for a byte vector:
>> 
>>   mul z18.b, p7/m, z18.b, z17.b
>>   add z17.b, p0/m, z17.b, z18.b
>> 
>> could be optimized to: 
>> 
>>    mla z19.b, p0/m, z18.b, z17.b
>> 
>>  And so does the multiply-sub operations. Also the following masked fused multiply-substract for a float vector:
>> 
>>   fneg    z18.s, p7/m, z18.s
>>   fmad    z17.s, p0/m, z18.s, z16.s
>> 
>> could be optimized to: 
>> 
>>   fmsb z17.s, p0/m, z18.s, z16.s"
>> 
>>  And the same to the relative negated fused operations.
>> 
>> This patch also fixes the potential issues for the usage of `NegVF/D` in match rules. The explicit check of non-predicated vector for `NegVF/D` must be added to the match rule predicate if the `NegVF/D` is assumed to be non-masked. Otherwise, the jvm might crash if a masked` NegVF/D` with two operands is matched into a rule which assumes the `NegVF/D` in subtree has one operand.
>> 
>> Also add the jtreg tests for all the touched vector operations.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the ir framework for the test

Hi, could anyone please help to take a look at this PR? Thanks so much!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7737

From darcy at openjdk.java.net  Tue Mar 15 02:42:40 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 15 Mar 2022 02:42:40 GMT
Subject: RFR: 8282162: [vector] Optimize vector negation API
In-Reply-To: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
Message-ID: <-E5E_NBci6gsGyOV5nWuTUNKLVnjiw2IiWjjgv2vFz0=.ebe7c447-ede9-4437-815c-a2004f9d6ce1@github.com>

On Fri, 11 Mar 2022 06:29:22 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE.
> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern.
> 
> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture:
>   - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation.
>   - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`.
> 
> So with this patch, the following transformations are applied:
> 
> For non-masked negation with NEON:
> 
>   movi    v16.4s, #0x0
>   sub v17.4s, v16.4s, v17.4s       ==> neg v17.4s, v17.4s
> 
> and with SVE:
> 
>   mov z16.s, #0
>   sub z18.s, z16.s, z17.s          ==> neg z16.s, p7/m, z16.s
> 
> For masked negation with NEON:
> 
>   movi    v17.4s, #0x1
>   mvn v19.16b, v18.16b
>   mov v20.16b, v16.16b             ==>  neg v18.4s, v17.4s
>   bsl v20.16b, v19.16b, v18.16b         bsl v19.16b, v18.16b, v17.16b
>   add v19.4s, v20.4s, v17.4s
>   mov v18.16b, v16.16b
>   bsl v18.16b, v19.16b, v20.16b
> 
> and with SVE:
> 
>   mov z16.s, #-1
>   mov z17.s, #1                    ==> neg z16.s, p0/m, z16.s
>   eor z18.s, p0/m, z18.s, z16.s
>   add z18.s, p0/m, z18.s, z17.s
> 
> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed):
> 
> NEON:
> Benchmark                Gain
> Byte128Vector.NEG        1.029
> Byte128Vector.NEGMasked  1.757
> Short128Vector.NEG       1.041
> Short128Vector.NEGMasked 1.659
> Int128Vector.NEG         1.005
> Int128Vector.NEGMasked   1.513
> Long128Vector.NEG        1.003
> Long128Vector.NEGMasked  1.878
> 
> SVE with 512-bits:
> Benchmark                Gain
> ByteMaxVector.NEG        1.10
> ByteMaxVector.NEGMasked  1.165
> ShortMaxVector.NEG       1.056
> ShortMaxVector.NEGMasked 1.195
> IntMaxVector.NEG         1.002
> IntMaxVector.NEGMasked   1.239
> LongMaxVector.NEG        1.031
> LongMaxVector.NEGMasked  1.191
> 
> X86 (non AVX-512):
> Benchmark                Gain
> ByteMaxVector.NEGMasked  1.254
> ShortMaxVector.NEGMasked 1.359
> IntMaxVector.NEGMasked   1.431
> LongMaxVector.NEGMasked  1.989
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896

Note that in terms of Java semantics, negation of floating point values needs to be implemented as subtraction from negative zero rather than positive zero:

double negate(double arg) {return -0.0 - arg; }

This is to handle signed zeros correctly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From dlong at openjdk.java.net  Tue Mar 15 02:57:40 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 15 Mar 2022 02:57:40 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity" [v3]
In-Reply-To: <zp_PFBMkkLEH8hwwSfhJzWNzKXAolLlPS3Snj_Hgt-U=.15b23250-cb08-48de-9e47-681038826827@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
 <rNWmcAZ05DXjShQlSoWffd-GPSxe-bj7YEX-UKj9p4c=.d1a26a69-7b21-4f20-8254-e7784f2d537e@github.com>
 <zp_PFBMkkLEH8hwwSfhJzWNzKXAolLlPS3Snj_Hgt-U=.15b23250-cb08-48de-9e47-681038826827@github.com>
Message-ID: <GrIy3mSSEciOY9C45hnHqiz_ikM7rnmeuchu-vmU7KY=.bf97e29f-8add-42d1-9374-871d2a443cd6@github.com>

On Tue, 15 Mar 2022 01:12:01 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename max_stubs --> max_aligned_stubs, update copyright year
>
> Marked as reviewed by jiefu (Reviewer).

Thanks @DamonFool and @hakib1.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7800

From dlong at openjdk.java.net  Tue Mar 15 02:57:40 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 15 Mar 2022 02:57:40 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity" [v3]
In-Reply-To: <-H86iYx9-94GUkEwMoVkznxVz1MzMUux_7EE5m9S4uE=.b57eb99d-0762-4f4b-9c84-77319e4ba06b@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
 <-H86iYx9-94GUkEwMoVkznxVz1MzMUux_7EE5m9S4uE=.b57eb99d-0762-4f4b-9c84-77319e4ba06b@github.com>
Message-ID: <-NYkHzgbUhl771GY8hBEp8XQvBxvxrNkiOeinPE2Pl8=.12cb8a7e-82de-44bd-abce-9d7432c90e78@github.com>

On Sun, 13 Mar 2022 16:56:41 GMT, hakib1 <duke at openjdk.java.net> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename max_stubs --> max_aligned_stubs, update copyright year
>
> Marked as reviewed by hakib1 at github.com (no known OpenJDK username).

@hakib1, do you have an openjdk username?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7800

From xgong at openjdk.java.net  Tue Mar 15 02:50:43 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 15 Mar 2022 02:50:43 GMT
Subject: RFR: 8282162: [vector] Optimize vector negation API
In-Reply-To: <-E5E_NBci6gsGyOV5nWuTUNKLVnjiw2IiWjjgv2vFz0=.ebe7c447-ede9-4437-815c-a2004f9d6ce1@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
 <-E5E_NBci6gsGyOV5nWuTUNKLVnjiw2IiWjjgv2vFz0=.ebe7c447-ede9-4437-815c-a2004f9d6ce1@github.com>
Message-ID: <UIbbi5W7BMv_b9IuzYdCQOCzSNfJuHEvOOuqqRyhHUE=.cc631985-5ef3-4d93-a6d6-c73db7903412@github.com>

On Tue, 15 Mar 2022 02:39:42 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Note that in terms of Java semantics, negation of floating point values needs to be implemented as subtraction from negative zero rather than positive zero:
> 
> double negate(double arg) {return -0.0 - arg; }
> 
> This is to handle signed zeros correctly.

Hi @jddarcy ,thanks for looking at this PR and thanks for the notes on the floating point negation! Yeah, this really makes sense to me. Kindly note that this patch didn't touch the negation of the floating point values. For Vector API, the vector floating point negation has been intrinsified to `NegVF/D` node by compiler that we directly generate the negation instructions for them. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From dlong at openjdk.java.net  Tue Mar 15 03:01:43 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 15 Mar 2022 03:01:43 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity" [v3]
In-Reply-To: <rNWmcAZ05DXjShQlSoWffd-GPSxe-bj7YEX-UKj9p4c=.d1a26a69-7b21-4f20-8254-e7784f2d537e@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
 <rNWmcAZ05DXjShQlSoWffd-GPSxe-bj7YEX-UKj9p4c=.d1a26a69-7b21-4f20-8254-e7784f2d537e@github.com>
Message-ID: <2PQIVkju1Afg84mJHIUwmaSFIFDiK9RjDxdwev6UZww=.907b556f-a4eb-42ff-8d12-af54453ede3b@github.com>

On Tue, 15 Mar 2022 00:26:14 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This change adds extra stub space for large values of CodeEntryAlignment, and it changes the test to try large values of CodeEntryAlignment.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename max_stubs --> max_aligned_stubs, update copyright year

@shipilev, can I get a review from you?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7800

From iveresov at openjdk.java.net  Tue Mar 15 03:48:46 2022
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Tue, 15 Mar 2022 03:48:46 GMT
Subject: RFR: 8279317:
 compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java assumes immutable
 code [v3]
In-Reply-To: <IG2zcgNdQPI1tFok-80Zu9QXyn4sv5UvUa_3DmuTnno=.19ca20d1-6688-4d01-9d24-a604170c909b@github.com>
References: <0p4QBsFdOEKPXTYliqwV4vhZ7e9uIv4V-853Q8U9kV0=.49b2d69e-14a1-4917-b899-02b3a7a7d504@github.com>
 <IG2zcgNdQPI1tFok-80Zu9QXyn4sv5UvUa_3DmuTnno=.19ca20d1-6688-4d01-9d24-a604170c909b@github.com>
Message-ID: <J1Ck5Y2Srh2CeSFRu3EcnrXNDvZeiu9ro4XwFPVET6o=.7e248ad8-9226-423e-bfec-4f4d669efac8@github.com>

On Sat, 12 Mar 2022 12:03:16 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This test was failing in loom because of nmethod entry barriers, but there are other reasons why it shouldn't assume immutable code, such as embedded oops and NativeJump::patch_verified_entry().
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix Windows failures

Marked as reviewed by iveresov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7781

From aoqi at openjdk.java.net  Tue Mar 15 05:59:46 2022
From: aoqi at openjdk.java.net (Ao Qi)
Date: Tue, 15 Mar 2022 05:59:46 GMT
Subject: RFR: 8283103: compiler/vectorapi/TestMaskedMacroLogicVector.java
 failed due to incorrect os.simpleArch on some platforms [v2]
In-Reply-To: <JkN_rHWJAtMr797VZFYi4MtC7pv4Te0cAK_V3vFlWdc=.7320b329-09c6-4400-b2ac-8239a6498ab4@github.com>
References: <CjftfHfXuWLRaNkh5cKNxlCYYDJpimyQSr5R_3q_1TE=.a8eca94a-8c22-4523-94d9-4cb62b1b706c@github.com>
 <JkN_rHWJAtMr797VZFYi4MtC7pv4Te0cAK_V3vFlWdc=.7320b329-09c6-4400-b2ac-8239a6498ab4@github.com>
Message-ID: <wtWtwBYlPEoB2d8dwvLreyNKaPFhuQ8ATXhEowaTy48=.ce7efea4-c727-4464-8e4b-faa0da710203@github.com>

On Mon, 14 Mar 2022 13:38:19 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> `os.simpleArch` is not set correctly on some platforms, for example on loongarch64 and mips64 ([CODETOOLS-7903120](https://bugs.openjdk.java.net/browse/CODETOOLS-7903120)). This issue aims to let the test work on these platforms.
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use vm.cpu.features

RFR, thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7809

From njian at openjdk.java.net  Tue Mar 15 06:34:39 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Tue, 15 Mar 2022 06:34:39 GMT
Subject: RFR: 8282431: AArch64: Add optimized rules for masked vector
 multiply-add/sub for SVE [v2]
In-Reply-To: <SW3zLs9MPHtWkj6c9SdEFOUaCjAIQ6wpAoTF6gaY80I=.89ff44d1-db70-4c82-ad88-02e1e49bff63@github.com>
References: <bRRrWEoEmJk24aLM-eRglGGIttZ2eAIBexmskoh4tdw=.34cca7f0-92b5-4e02-9019-036a29dfc066@github.com>
 <SW3zLs9MPHtWkj6c9SdEFOUaCjAIQ6wpAoTF6gaY80I=.89ff44d1-db70-4c82-ad88-02e1e49bff63@github.com>
Message-ID: <ycvjONdMfx0TdskFFiSkPqlqKPqNw2Rwk8xhfoBMMOk=.d6bbc5f8-a697-47d3-bf6c-9e422491bf7d@github.com>

On Thu, 10 Mar 2022 07:55:15 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> We have the optimized match rules for vector `"fmls,fnmla,fnmls,mla,mls"` for ARM SVE. Similarly we can also add the rules for the relative masked operations to generate the optimized predicated instructions.
>> 
>> With this patch the following masked vector multiply-add for a byte vector:
>> 
>>   mul z18.b, p7/m, z18.b, z17.b
>>   add z17.b, p0/m, z17.b, z18.b
>> 
>> could be optimized to: 
>> 
>>    mla z19.b, p0/m, z18.b, z17.b
>> 
>>  And so does the multiply-sub operations. Also the following masked fused multiply-substract for a float vector:
>> 
>>   fneg    z18.s, p7/m, z18.s
>>   fmad    z17.s, p0/m, z18.s, z16.s
>> 
>> could be optimized to: 
>> 
>>   fmsb z17.s, p0/m, z18.s, z16.s"
>> 
>>  And the same to the relative negated fused operations.
>> 
>> This patch also fixes the potential issues for the usage of `NegVF/D` in match rules. The explicit check of non-predicated vector for `NegVF/D` must be added to the match rule predicate if the `NegVF/D` is assumed to be non-masked. Otherwise, the jvm might crash if a masked` NegVF/D` with two operands is matched into a rule which assumes the `NegVF/D` in subtree has one operand.
>> 
>> Also add the jtreg tests for all the touched vector operations.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the ir framework for the test

Marked as reviewed by njian (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7737

From dlong at openjdk.java.net  Tue Mar 15 07:27:40 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 15 Mar 2022 07:27:40 GMT
Subject: RFR: 8279317:
 compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java assumes immutable
 code [v3]
In-Reply-To: <IG2zcgNdQPI1tFok-80Zu9QXyn4sv5UvUa_3DmuTnno=.19ca20d1-6688-4d01-9d24-a604170c909b@github.com>
References: <0p4QBsFdOEKPXTYliqwV4vhZ7e9uIv4V-853Q8U9kV0=.49b2d69e-14a1-4917-b899-02b3a7a7d504@github.com>
 <IG2zcgNdQPI1tFok-80Zu9QXyn4sv5UvUa_3DmuTnno=.19ca20d1-6688-4d01-9d24-a604170c909b@github.com>
Message-ID: <jqqRCJ_hYYdbHtVPdHikYin69uioDKu8mkr2y8eIJxA=.81208ae0-53c8-4172-ab28-02c81657b557@github.com>

On Sat, 12 Mar 2022 12:03:16 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This test was failing in loom because of nmethod entry barriers, but there are other reasons why it shouldn't assume immutable code, such as embedded oops and NativeJump::patch_verified_entry().
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix Windows failures

Thanks Igor.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7781

From dlong at openjdk.java.net  Tue Mar 15 07:27:40 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 15 Mar 2022 07:27:40 GMT
Subject: Integrated: 8279317:
 compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java assumes immutable
 code
In-Reply-To: <0p4QBsFdOEKPXTYliqwV4vhZ7e9uIv4V-853Q8U9kV0=.49b2d69e-14a1-4917-b899-02b3a7a7d504@github.com>
References: <0p4QBsFdOEKPXTYliqwV4vhZ7e9uIv4V-853Q8U9kV0=.49b2d69e-14a1-4917-b899-02b3a7a7d504@github.com>
Message-ID: <kwblSG9ZuEbprWfwmPbCgmdH7FsOFgp394Eeazhl1-w=.602000a6-1de4-43b1-b869-dae83d5db0fa@github.com>

On Fri, 11 Mar 2022 04:14:00 GMT, Dean Long <dlong at openjdk.org> wrote:

> This test was failing in loom because of nmethod entry barriers, but there are other reasons why it shouldn't assume immutable code, such as embedded oops and NativeJump::patch_verified_entry().

This pull request has now been integrated.

Changeset: 34d4ffce
Author:    Dean Long <dlong at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/34d4ffcea5d71560c549655967de863342b48984
Stats:     31 lines in 1 file changed: 19 ins; 0 del; 12 mod

8279317: compiler/jvmci/compilerToVM/DisassembleCodeBlobTest.java assumes immutable code

Reviewed-by: dnsimon, iveresov

-------------

PR: https://git.openjdk.java.net/jdk/pull/7781

From fgao at openjdk.java.net  Tue Mar 15 08:09:27 2022
From: fgao at openjdk.java.net (Fei Gao)
Date: Tue, 15 Mar 2022 08:09:27 GMT
Subject: RFR: 8283091: Support type conversion between different data sizes
 in SLP [v3]
In-Reply-To: <4qFrtxwRHZfnzJbdVl2z7l6XENvxR3N8Sruc2fraKkw=.1391f639-1514-4e50-899a-d56cdd4afa99@github.com>
References: <4qFrtxwRHZfnzJbdVl2z7l6XENvxR3N8Sruc2fraKkw=.1391f639-1514-4e50-899a-d56cdd4afa99@github.com>
Message-ID: <nbsp68JympAQ3Dnrr8vCnMvCybc3hAhax96CnsOO0fc=.ccb20d24-a2b1-4f4d-8d42-5dbd861d1007@github.com>

> After JDK-8275317, C2's SLP vectorizer has supported type conversion between the same data size. We can also support conversions between different data sizes like:
> int <-> double
> float <-> long
> int <-> long
> float <-> double
> 
> A typical test case:
> 
> int[] a;
> double[] b;
> for (int i = start; i < limit; i++) {
>     b[i] = (double) a[i];
> }
> 
> Our expected OptoAssembly code for one iteration is like below:
> 
> add R12, R2, R11, LShiftL #2
> vector_load   V16,[R12, #16]
> vectorcast_i2d  V16, V16  # convert I to D vector
> add R11, R1, R11, LShiftL #3	# ptr
> add R13, R11, #16	# ptr
> vector_store [R13], V16
> 
> To enable the vectorization, the patch solves the following problems in the SLP.
> 
> There are three main operations in the case above, LoadI, ConvI2D and StoreD. Assuming that the vector length is 128 bits, how many scalar nodes should be packed together to a vector? If we decide it separately for each operation node, like what we did before the patch in SuperWord::combine_packs(), a 128-bit vector will support 4 LoadI or 2 ConvI2D or 2 StoreD nodes. However, if we put these packed nodes in a vector node sequence, like loading 4 elements to a vector, then typecasting 2 elements and lastly storing these 2 elements, they become invalid. As a result, we should look through the whole def-use chain
> and then pick up the minimum of these element sizes, like function SuperWord::max_vector_size_in_ud_chain() do in the superword.cpp. In this case, we pack 2 LoadI, 2 ConvI2D and 2 StoreD nodes, and then generate valid vector node sequence, like loading 2 elements, converting the 2 elements to another type and storing the 2 elements with new type.
> 
> After this, LoadI nodes don't make full use of the whole vector and only occupy part of it. So we adapt the code in SuperWord::get_vw_bytes_special() to the situation.
> 
> In SLP, we calculate a kind of alignment as position trace for each scalar node in the whole vector. In this case, the alignments for 2 LoadI nodes are 0, 4 while the alignment for 2 ConvI2D nodes are 0, 8. Sometimes, 4 for LoadI and 8 for ConvI2D work the same, both of which mark that this node is the second node in the whole vector, while the difference between 4 and 8 are just because of their own data sizes. In this situation, we should try to remove the impact caused by different data size in SLP. For example, in the stage of SuperWord::extend_packlist(), while determining if it's potential to pack a pair of def nodes in the function SuperWord::follow_use_defs(), we remove the side effect of different data size by transforming the target alignment from the use node. Because we believe that, assuming that the vector length is 512 bits, if the ConvI2D use nodes have alignments of 16-24 and their def nodes, LoadI, have alignments of 8-12, these two LoadI nodes should be packed as
  a pair as well.
> 
> Similarly, when determining if the vectorization is profitable, type conversion between different data size takes a type of one size and produces a type of another size, hence the special checks on alignment and size should be applied, like what we do in SuperWord::is_vector_use().
> 
> After solving these problems, we successfully implemented the vectorization of type conversion between different data sizes.
> 
> Here is the test data on NEON:
> 
> Before the patch:
> Benchmark              (length)  Mode  Cnt    Score   Error  Units
>   VectorLoop.convertD2F       523  avgt   15  216.431 ? 0.131  ns/op
>   VectorLoop.convertD2I       523  avgt   15  220.522 ? 0.311  ns/op
>   VectorLoop.convertF2D       523  avgt   15  217.034 ? 0.292  ns/op
>   VectorLoop.convertF2L       523  avgt   15  231.634 ? 1.881  ns/op
>   VectorLoop.convertI2D       523  avgt   15  229.538 ? 0.095  ns/op
>   VectorLoop.convertI2L       523  avgt   15  214.822 ? 0.131  ns/op
>   VectorLoop.convertL2F       523  avgt   15  230.188 ? 0.217  ns/op
>   VectorLoop.convertL2I       523  avgt   15  162.234 ? 0.235  ns/op
> 
> After the patch:
> Benchmark              (length)  Mode  Cnt    Score    Error  Units
>   VectorLoop.convertD2F       523  avgt   15  124.352 ?  1.079  ns/op
>   VectorLoop.convertD2I       523  avgt   15  557.388 ?  8.166  ns/op
>   VectorLoop.convertF2D       523  avgt   15  118.082 ?  4.026  ns/op
>   VectorLoop.convertF2L       523  avgt   15  225.810 ? 11.180  ns/op
>   VectorLoop.convertI2D       523  avgt   15  166.247 ?  0.120  ns/op
>   VectorLoop.convertI2L       523  avgt   15  119.699 ?  2.925  ns/op
>   VectorLoop.convertL2F       523  avgt   15  220.847 ?  0.053  ns/op
>   VectorLoop.convertL2I       523  avgt   15  122.339 ?  2.738  ns/op
> 
> perf data on X86:
> Before the patch:
> Benchmark              (length)  Mode  Cnt    Score   Error  Units
>   VectorLoop.convertD2F       523  avgt   15  279.466 ? 0.069  ns/op
>   VectorLoop.convertD2I       523  avgt   15  551.009 ? 7.459  ns/op
>   VectorLoop.convertF2D       523  avgt   15  276.066 ? 0.117  ns/op
>   VectorLoop.convertF2L       523  avgt   15  545.108 ? 5.697  ns/op
>   VectorLoop.convertI2D       523  avgt   15  745.303 ? 0.185  ns/op
>   VectorLoop.convertI2L       523  avgt   15  260.878 ? 0.044  ns/op
>   VectorLoop.convertL2F       523  avgt   15  502.016 ? 0.172  ns/op
>   VectorLoop.convertL2I       523  avgt   15  261.654 ? 3.326  ns/op
> 
> After the patch:
> Benchmark              (length)  Mode  Cnt    Score   Error  Units
>   VectorLoop.convertD2F       523  avgt   15  106.975 ? 0.045  ns/op
>   VectorLoop.convertD2I       523  avgt   15  546.866 ? 9.287  ns/op
>   VectorLoop.convertF2D       523  avgt   15   82.414 ? 0.340  ns/op
>   VectorLoop.convertF2L       523  avgt   15  542.235 ? 2.785  ns/op
>   VectorLoop.convertI2D       523  avgt   15   92.966 ? 1.400  ns/op
>   VectorLoop.convertI2L       523  avgt   15   79.960 ? 0.528  ns/op
>   VectorLoop.convertL2F       523  avgt   15  504.712 ? 4.794  ns/op
>   VectorLoop.convertL2I       523  avgt   15  129.753 ? 0.094  ns/op
> 
> perf data on AVX512:
> Before the patch:
> Benchmark              (length)  Mode  Cnt    Score   Error  Units
>   VectorLoop.convertD2F       523  avgt   15  282.984 ? 4.022  ns/op
>   VectorLoop.convertD2I       523  avgt   15  543.080 ? 3.873  ns/op
>   VectorLoop.convertF2D       523  avgt   15  273.950 ? 0.131  ns/op
>   VectorLoop.convertF2L       523  avgt   15  539.568 ? 2.747  ns/op
>   VectorLoop.convertI2D       523  avgt   15  745.238 ? 0.069  ns/op
>   VectorLoop.convertI2L       523  avgt   15  260.935 ? 0.169  ns/op
>   VectorLoop.convertL2F       523  avgt   15  501.870 ? 0.359  ns/op
>   VectorLoop.convertL2I       523  avgt   15  257.508 ? 0.174  ns/op
> 
> After the patch:
> Benchmark              (length)  Mode  Cnt    Score   Error  Units
>   VectorLoop.convertD2F       523  avgt   15   76.687 ? 0.530  ns/op
>   VectorLoop.convertD2I       523  avgt   15  545.408 ? 4.657  ns/op
>   VectorLoop.convertF2D       523  avgt   15  273.935 ? 0.099  ns/op
>   VectorLoop.convertF2L       523  avgt   15  540.534 ? 3.032  ns/op
>   VectorLoop.convertI2D       523  avgt   15  745.234 ? 0.053  ns/op
>   VectorLoop.convertI2L       523  avgt   15  260.865 ? 0.104  ns/op
>   VectorLoop.convertL2F       523  avgt   15   63.834 ? 4.777  ns/op
>   VectorLoop.convertL2I       523  avgt   15   48.183 ? 0.990  ns/op

Fei Gao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Add micro-benchmark cases
   
   Change-Id: I3c741255804ce410c8b6dcbdec974fa2c9051fd8
 - Merge branch 'master' into fg8283091
   
   Change-Id: I674581135fd0844accc65520574fcef161eededa
 - 8283091: Support type conversion between different data sizes in SLP
   
   After JDK-8275317, C2's SLP vectorizer has supported type conversion
   between the same data size. We can also support conversions between
   different data sizes like:
   int <-> double
   float <-> long
   int <-> long
   float <-> double
   
   A typical test case:
   
   int[] a;
   double[] b;
   for (int i = start; i < limit; i++) {
       b[i] = (double) a[i];
   }
   
   Our expected OptoAssembly code for one iteration is like below:
   
   add R12, R2, R11, LShiftL #2
   vector_load   V16,[R12, #16]
   vectorcast_i2d  V16, V16  # convert I to D vector
   add R11, R1, R11, LShiftL #3	# ptr
   add R13, R11, #16	# ptr
   vector_store [R13], V16
   
   To enable the vectorization, the patch solves the following problems
   in the SLP.
   
   There are three main operations in the case above, LoadI, ConvI2D and
   StoreD. Assuming that the vector length is 128 bits, how many scalar
   nodes should be packed together to a vector? If we decide it
   separately for each operation node, like what we did before the patch
   in SuperWord::combine_packs(), a 128-bit vector will support 4 LoadI
   or 2 ConvI2D or 2 StoreD nodes. However, if we put these packed nodes
   in a vector node sequence, like loading 4 elements to a vector, then
   typecasting 2 elements and lastly storing these 2 elements, they become
   invalid. As a result, we should look through the whole def-use chain
   and then pick up the minimum of these element sizes, like function
   SuperWord::max_vector_size_in_ud_chain() do in the superword.cpp.
   In this case, we pack 2 LoadI, 2 ConvI2D and 2 StoreD nodes, and then
   generate valid vector node sequence, like loading 2 elements,
   converting the 2 elements to another type and storing the 2 elements
   with new type.
   
   After this, LoadI nodes don't make full use of the whole vector and
   only occupy part of it. So we adapt the code in
   SuperWord::get_vw_bytes_special() to the situation.
   
   In SLP, we calculate a kind of alignment as position trace for each
   scalar node in the whole vector. In this case, the alignments for 2
   LoadI nodes are 0, 4 while the alignment for 2 ConvI2D nodes are 0, 8.
   Sometimes, 4 for LoadI and 8 for ConvI2D work the same, both of which
   mark that this node is the second node in the whole vector, while the
   difference between 4 and 8 are just because of their own data sizes. In
   this situation, we should try to remove the impact caused by different
   data size in SLP. For example, in the stage of
   SuperWord::extend_packlist(), while determining if it's potential to
   pack a pair of def nodes in the function SuperWord::follow_use_defs(),
   we remove the side effect of different data size by transforming the
   target alignment from the use node. Because we believe that, assuming
   that the vector length is 512 bits, if the ConvI2D use nodes have
   alignments of 16-24 and their def nodes, LoadI, have alignments of 8-12,
   these two LoadI nodes should be packed as a pair as well.
   
   Similarly, when determining if the vectorization is profitable, type
   conversion between different data size takes a type of one size and
   produces a type of another size, hence the special checks on alignment
   and size should be applied, like what we do in SuperWord::is_vector_use.
   
   After solving these problems, we successfully implemented the
   vectorization of type conversion between different data sizes.
   
   Here is the test data on NEON:
   
   Before the patch:
   Benchmark              (length)  Mode  Cnt    Score   Error  Units
     VectorLoop.convertD2F       523  avgt   15  216.431 ? 0.131  ns/op
     VectorLoop.convertD2I       523  avgt   15  220.522 ? 0.311  ns/op
     VectorLoop.convertF2D       523  avgt   15  217.034 ? 0.292  ns/op
     VectorLoop.convertF2L       523  avgt   15  231.634 ? 1.881  ns/op
     VectorLoop.convertI2D       523  avgt   15  229.538 ? 0.095  ns/op
     VectorLoop.convertI2L       523  avgt   15  214.822 ? 0.131  ns/op
     VectorLoop.convertL2F       523  avgt   15  230.188 ? 0.217  ns/op
     VectorLoop.convertL2I       523  avgt   15  162.234 ? 0.235  ns/op
   
   After the patch:
   Benchmark              (length)  Mode  Cnt    Score    Error  Units
     VectorLoop.convertD2F       523  avgt   15  124.352 ?  1.079  ns/op
     VectorLoop.convertD2I       523  avgt   15  557.388 ?  8.166  ns/op
     VectorLoop.convertF2D       523  avgt   15  118.082 ?  4.026  ns/op
     VectorLoop.convertF2L       523  avgt   15  225.810 ? 11.180  ns/op
     VectorLoop.convertI2D       523  avgt   15  166.247 ?  0.120  ns/op
     VectorLoop.convertI2L       523  avgt   15  119.699 ?  2.925  ns/op
     VectorLoop.convertL2F       523  avgt   15  220.847 ?  0.053  ns/op
     VectorLoop.convertL2I       523  avgt   15  122.339 ?  2.738  ns/op
   
   perf data on X86:
   Before the patch:
   Benchmark              (length)  Mode  Cnt    Score   Error  Units
     VectorLoop.convertD2F       523  avgt   15  279.466 ? 0.069  ns/op
     VectorLoop.convertD2I       523  avgt   15  551.009 ? 7.459  ns/op
     VectorLoop.convertF2D       523  avgt   15  276.066 ? 0.117  ns/op
     VectorLoop.convertF2L       523  avgt   15  545.108 ? 5.697  ns/op
     VectorLoop.convertI2D       523  avgt   15  745.303 ? 0.185  ns/op
     VectorLoop.convertI2L       523  avgt   15  260.878 ? 0.044  ns/op
     VectorLoop.convertL2F       523  avgt   15  502.016 ? 0.172  ns/op
     VectorLoop.convertL2I       523  avgt   15  261.654 ? 3.326  ns/op
   
   After the patch:
   Benchmark              (length)  Mode  Cnt    Score   Error  Units
     VectorLoop.convertD2F       523  avgt   15  106.975 ? 0.045  ns/op
     VectorLoop.convertD2I       523  avgt   15  546.866 ? 9.287  ns/op
     VectorLoop.convertF2D       523  avgt   15   82.414 ? 0.340  ns/op
     VectorLoop.convertF2L       523  avgt   15  542.235 ? 2.785  ns/op
     VectorLoop.convertI2D       523  avgt   15   92.966 ? 1.400  ns/op
     VectorLoop.convertI2L       523  avgt   15   79.960 ? 0.528  ns/op
     VectorLoop.convertL2F       523  avgt   15  504.712 ? 4.794  ns/op
     VectorLoop.convertL2I       523  avgt   15  129.753 ? 0.094  ns/op
   
   perf data on AVX512:
   Before the patch:
   Benchmark              (length)  Mode  Cnt    Score   Error  Units
     VectorLoop.convertD2F       523  avgt   15  282.984 ? 4.022  ns/op
     VectorLoop.convertD2I       523  avgt   15  543.080 ? 3.873  ns/op
     VectorLoop.convertF2D       523  avgt   15  273.950 ? 0.131  ns/op
     VectorLoop.convertF2L       523  avgt   15  539.568 ? 2.747  ns/op
     VectorLoop.convertI2D       523  avgt   15  745.238 ? 0.069  ns/op
     VectorLoop.convertI2L       523  avgt   15  260.935 ? 0.169  ns/op
     VectorLoop.convertL2F       523  avgt   15  501.870 ? 0.359  ns/op
     VectorLoop.convertL2I       523  avgt   15  257.508 ? 0.174  ns/op
   
   After the patch:
   Benchmark              (length)  Mode  Cnt    Score   Error  Units
     VectorLoop.convertD2F       523  avgt   15   76.687 ? 0.530  ns/op
     VectorLoop.convertD2I       523  avgt   15  545.408 ? 4.657  ns/op
     VectorLoop.convertF2D       523  avgt   15  273.935 ? 0.099  ns/op
     VectorLoop.convertF2L       523  avgt   15  540.534 ? 3.032  ns/op
     VectorLoop.convertI2D       523  avgt   15  745.234 ? 0.053  ns/op
     VectorLoop.convertI2L       523  avgt   15  260.865 ? 0.104  ns/op
     VectorLoop.convertL2F       523  avgt   15   63.834 ? 4.777  ns/op
     VectorLoop.convertL2I       523  avgt   15   48.183 ? 0.990  ns/op
   
   Change-Id: I93e60fd956547dad9204ceec90220145c58a72ef

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7806/files
  - new: https://git.openjdk.java.net/jdk/pull/7806/files/c2c13739..bf3fc418

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7806&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7806&range=01-02

  Stats: 3826 lines in 121 files changed: 1616 ins; 1724 del; 486 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7806.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7806/head:pull/7806

PR: https://git.openjdk.java.net/jdk/pull/7806

From fgao at openjdk.java.net  Tue Mar 15 08:23:42 2022
From: fgao at openjdk.java.net (Fei Gao)
Date: Tue, 15 Mar 2022 08:23:42 GMT
Subject: RFR: 8283091: Support type conversion between different data sizes
 in SLP [v2]
In-Reply-To: <-37Zcqz0MqxLqIUZPx9nQWib2xhdI5cQ2AGsSg7UjyE=.3ba5181e-4561-4bbb-ad9b-a15188f2a5a5@github.com>
References: <4qFrtxwRHZfnzJbdVl2z7l6XENvxR3N8Sruc2fraKkw=.1391f639-1514-4e50-899a-d56cdd4afa99@github.com>
 <eKT6M7R9NTOMdWKTli4nOpNqjJ75QfJycYq7yo08qjA=.5ae1f119-de65-4d97-88c6-04c4626cc0ab@github.com>
 <gezl7u0FkmtQcagZZVX33Y54xFkTJGzFs0RTq3wEEok=.a0f1a390-6c2b-4f18-8d05-6ae3b0e1c875@github.com>
 <-37Zcqz0MqxLqIUZPx9nQWib2xhdI5cQ2AGsSg7UjyE=.3ba5181e-4561-4bbb-ad9b-a15188f2a5a5@github.com>
Message-ID: <HzTj3BfhUluaX2X1udB54R-lY9h30coxbZ2ftirWJh8=.97256943-e283-4060-8a51-1404b4d46496@github.com>

On Mon, 14 Mar 2022 09:00:13 GMT, Fei Gao <fgao at openjdk.org> wrote:

> Did you forget the micro-benchmark VectorLoop.java?

Thanks. Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7806

From thartmann at openjdk.java.net  Tue Mar 15 08:33:52 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Mar 2022 08:33:52 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v12]
In-Reply-To: <ipzQF1uR_cuz1f7hI8RZ1HhokXaf6VGYGhx58h2VVQQ=.78863db8-b67f-4835-af92-e32c1a524353@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <ipzQF1uR_cuz1f7hI8RZ1HhokXaf6VGYGhx58h2VVQQ=.78863db8-b67f-4835-af92-e32c1a524353@github.com>
Message-ID: <Lxt9FlfcbYWXBuvqNrv4fF7Dfxmp8yUpbT_0KOvNN_4=.4ed5754b-0d81-4dd3-9d4b-a1b2cca3c5f5@github.com>

On Sat, 12 Mar 2022 04:52:41 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into leaIns
>  - reviews
>  - remove unreached rules
>  - remove 0x67 prefix
>  - address reviews
>  - remove irrelevent changes
>  - reviews
>  - address reviews
>  - add benchmark
>  - add predicate
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/1775d337...e0fd81f6

Sure, will run testing and report back once it finished.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From thartmann at openjdk.java.net  Tue Mar 15 09:28:51 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Mar 2022 09:28:51 GMT
Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v6]
In-Reply-To: <4f4q-PLj6psH50mRQCVLAX8bMjzF4XWzAornt_t4PNE=.4331b19d-469b-4e0d-8a1f-d1eeb5aaf9ed@github.com>
References: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
 <4f4q-PLj6psH50mRQCVLAX8bMjzF4XWzAornt_t4PNE=.4331b19d-469b-4e0d-8a1f-d1eeb5aaf9ed@github.com>
Message-ID: <2LdpZiNnH5XrPqD_O3yHxVKNz-f4BsxFoswECEL09uo=.e11cdc0e-5fba-4e00-851e-c8ada9182c24@github.com>

On Mon, 14 Mar 2022 06:13:30 GMT, Pengfei Li <pli at openjdk.org> wrote:

>> ### Background
>> 
>> Post loop vectorization is a C2 compiler optimization in an experimental
>> VM feature called PostLoopMultiversioning. It transforms the range-check
>> eliminated post loop to a 1-iteration vectorized loop with vector mask.
>> This optimization was contributed by Intel in 2016 to support x86 AVX512
>> masked vector instructions. However, it was disabled soon after an issue
>> was found. Due to insufficient maintenance in these years, multiple bugs
>> have been accumulated inside. But we (Arm) still think this is a useful
>> framework for vector mask support in C2 auto-vectorized loops, for both
>> x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
>> post loop vectorization.
>> 
>> ### Changes in this patch
>> 
>> This patch reworks post loop vectorization. The most significant change
>> is removing vector mask support in C2 x86 backend and re-implementing
>> it in the mid-end. With this, we can re-enable post loop vectorization
>> for platforms other than x86.
>> 
>> Previous implementation hard-codes x86 k1 register as a reserved AVX512
>> opmask register and defines two routines (setvectmask/restorevectmask)
>> to set and restore the value of k1. But after [JDK-8211251](https://bugs.openjdk.java.net/browse/JDK-8211251) which encodes
>> AVX512 instructions as unmasked by default, generated vector masks are
>> no longer used in AVX512 vector instructions. To fix incorrect codegen
>> and add vector mask support for more platforms, we turn to add a vector
>> mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
>> to generate a mask and replace all Load/Store nodes in the post loop
>> into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
>> IR form is exactly the same to those which are used in VectorAPI mask
>> support. For now, we only add mask inputs for Load/Store nodes because
>> we don't have reduction operations supported in post loop vectorization.
>> After this change, the x86 k1 register is no longer reserved and can be
>> allocated when PostLoopMultiversioning is enabled.
>> 
>> Besides this change, we have fixed a compiler crash and five incorrect
>> result issues with post loop vectorization.
>> 
>> **I) C2 crashes with segmentation fault in strip-mined loops**
>> 
>> Previous implementation was done before C2 loop strip-mining was merged
>> into JDK master so it didn't take strip-mined loops into consideration.
>> In C2's strip mined loops, post loop is not the sibling of the main loop
>> in ideal loop tree. Instead, it's the sibling of the main loop's parent.
>> This patch fixed a SIGSEGV issue caused by NULL pointer when locating
>> post loop from strip-mined main loop.
>> 
>> **II) Incorrect result issues with post loop vectorization**
>> 
>> We have also fixed five incorrect vectorization issues. Some of them are
>> hidden deep and can only be reproduced with corner cases. These issues
>> have a common cause that it assumes the post loop can be vectorized if
>> the vectorization in corresponding main loop is successful. But in many
>> cases this assumption is wrong. Below are details.
>> 
>> - **[Issue-1] Incorrect vectorization for partial vectorizable loops**
>> 
>> This issue can be reproduced by below loop where only some operations in
>> the loop body are vectorizable.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     res[i] = a[i] * b[i];
>>     k = 3 * k + 1;
>>   }
>> 
>> In the main loop, superword can work well if parts of the operations in
>> loop body are not vectorizable since those parts can be unrolled only.
>> But for post loops, we don't create vectors through combining scalar IRs
>> generated from loop unrolling. Instead, we are doing scalars to vectors
>> replacement for all operations in the loop body. Hence, all operations
>> should be either vectorized together or not vectorized at all. To fix
>> this kind of cases, we add an extra field "_slp_vector_pack_count" in
>> CountedLoopNode to record the eventual count of vector packs in the main
>> loop. This value is then passed to post loop and compared with post loop
>> pack count. Vectorization will be bailed out in post loop if it creates
>> more vector packs than in the main loop.
>> 
>> - **[Issue-2] Incorrect result in loops with growing-down vectors**
>> 
>> This issue appears with growing-down vectors, that is, vectors that grow
>> to smaller memory address as the loop iterates. It can be reproduced by
>> below counting-up loop with negative scale value in array index.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     a[MAX - i] = b[MAX - i];
>>   }
>> 
>> Cause of this issue is that for a growing-down vector, generated vector
>> mask value has reversed vector-lane order so it masks incorrect vector
>> lanes. Note that if negative scale value appears in counting-down loops,
>> the vector will be growing up. With this rule, we fix the issue by only
>> allowing positive array index scales in counting-up loops and negative
>> array index scales in counting-down loops. This check is done with the
>> help of SWPointer by comparing scale values in each memory access in the
>> loop with loop stride value.
>> 
>> - **[Issue-3] Incorrect result in manually unrolled loops**
>> 
>> This issue can be reproduced by below manually unrolled loop.
>> 
>>   for (int i = 0; i < 10000; i += 2) {
>>     c[i] = a[i] + b[i];
>>     c[i + 1] = a[i + 1] * b[i + 1];
>>   }
>> 
>> In this loop, operations in the 2nd statement duplicate those in the 1st
>> statement with a small memory address offset. Vectorization in the main
>> loop works well in this case because C2 does further unrolling and pack
>> combination. But we cannot vectorize the post loop through replacement
>> from scalars to vectors because it creates duplicated vector operations.
>> To fix this, we restrict post loop vectorization to loops with stride
>> values of 1 or -1.
>> 
>> - **[Issue-4] Incorrect result in loops with mixed vector element sizes**
>> 
>> This issue is found after we enable post loop vectorization for AArch64.
>> It's reproducible by multiple array operations with different element
>> sizes inside a loop. On x86, there is no issue because the values of x86
>> AVX512 opmasks only depend on which vector lanes are active. But AArch64
>> is different - the values of SVE predicates also depend on lane size of
>> the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
>> sizes, we should use different vector masks. For now, we just support
>> loops with only one vector element size, i.e., "int + float" vectors in
>> a single loop is ok but "int + double" vectors in a single loop is not
>> vectorizable. This fix also enables subword vectors support to make all
>> primitive type array operations vectorizable.
>> 
>> - **[Issue-5] Incorrect result in loops with potential data dependence**
>> 
>> This issue can be reproduced by below corner case on AArch64 only.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     a[i] = x;
>>     a[i + OFFSET] = y;
>>   }
>> 
>> In this case, two stores in the loop have data dependence if the OFFSET
>> value is smaller than the vector length. So we cannot do vectorization
>> through replacing scalars to vectors. But the main loop vectorization
>> in this case is successful on AArch64 because AArch64 has partial vector
>> load/store support. It splits vector fill with different values in lanes
>> to several smaller-sized fills. In this patch, we add additional data
>> dependence check for this kind of cases. The check is also done with the
>> help of SWPointer class. In this check, we require that every two memory
>> accesses (with at least one store) of the same element type (or subword
>> size) in the loop has the same array index expression.
>> 
>> ### Tests
>> 
>> So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
>> experimental VM option "PostLoopMultiversioning" turned on. We found no
>> issue in all tests. We notice that those existing cases are not enough
>> because some of above issues are not spotted by them. We would like to
>> add some new cases but we found existing vectorization tests are a bit
>> cumbersome - golden results must be pre-calculated and hard-coded in the
>> test code for correctness verification. Thus, in this patch, we propose
>> a new vectorization testing framework.
>> 
>> Our new framework brings a simpler way to add new cases. For a new test
>> case, we only need to create a new method annotated with "@Test". The
>> test runner will invoke each annotated method twice automatically. First
>> time it runs in the interpreter and second time it's forced compiled by
>> C2. Then the two return results are compared. So in this framework each
>> test method should return a primitive value or an array of primitives.
>> In this way, no extra verification code for vectorization correctness is
>> required. This test runner is still jtreg-based and takes advantages of
>> the jtreg WhiteBox API, which enables test methods running at specific
>> compilation levels. Each test class inside is also jtreg-based. It just
>> need to inherit from the test runner class and run with two additional
>> options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
>> 
>> ### Summary & Future work
>> 
>> In this patch, we reworked post loop vectorization. We made it platform
>> independent and fixed several issues inside. We also implemented a new
>> vectorization testing framework with many test cases inside. Meanwhile,
>> we did some code cleanups.
>> 
>> This patch only touches C2 code guarded with PostLoopMultiversioning,
>> except a few data structure changes. So, there's no behavior change when
>> experimental VM option PostLoopMultiversioning is off. Also, to reduce
>> risks, we still propose to keep post loop vectorization experimental for
>> now. But if it receives positive feedback, we would like to change it to
>> non-experimental in the future.
>
> Pengfei Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update a few comments

I'll run some testing and take a look at the changes later this week.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6828

From thartmann at openjdk.java.net  Tue Mar 15 09:31:38 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Mar 2022 09:31:38 GMT
Subject: RFR: 8283056: show abstract machine code for all VM crashes
In-Reply-To: <kKS2Tk_nZOc6NXbUOuluZ6IGvrUrZY9IRh5tT7BSb70=.4ad088ee-ba8d-4ab6-9132-bae951036bba@github.com>
References: <kKS2Tk_nZOc6NXbUOuluZ6IGvrUrZY9IRh5tT7BSb70=.4ad088ee-ba8d-4ab6-9132-bae951036bba@github.com>
Message-ID: <WVGnpIW03rx2UY56bM5dMuzt5zrrh3vVXbIqyT9C_Wc=.0601f7e6-d525-4a9e-861c-69b905e13e38@github.com>

On Fri, 11 Mar 2022 20:48:06 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> [JDK-8272586](https://bugs.openjdk.java.net/browse/JDK-8272586) added abstract assembly to hs-err for methods on the stack of the crashing thread. However, it only does this if the crash is due to an unhandled signal. It can also be useful to see assembly for crashes due to failing VM assertions or guarantees. This PR implements this improvement.

Okay, makes sense. The change looks reasonable to me but someone from the runtime folks should have a look as well.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7791

From thartmann at openjdk.java.net  Tue Mar 15 09:36:43 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Mar 2022 09:36:43 GMT
Subject: RFR: 8283122: [AIX, s390] UnsafeCopyMemory 'Mismatched' Tests Fail
 on Big Endian Systems [v2]
In-Reply-To: <FRFoPa-p7cWb82EHao1SdrYBFeZKWidZBcFbWk3wmtE=.4f2639c3-9f99-4ea3-8a91-c0155fc7b15a@github.com>
References: <cdQZg8cHGBnBlCcDG53z2-xzibPwq4zu2SFyOkXYsbU=.99cb9d2f-77a7-450b-9ea7-f5c16fc7a165@github.com>
 <FRFoPa-p7cWb82EHao1SdrYBFeZKWidZBcFbWk3wmtE=.4f2639c3-9f99-4ea3-8a91-c0155fc7b15a@github.com>
Message-ID: <bLfl50SeMvCF0hKWmZcMCIUb4dk_A8z1b4rZMdSh3bM=.10c73a24-7e9a-4422-a93a-d7c19491ea4e@github.com>

On Mon, 14 Mar 2022 20:24:08 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> This is a testbug present on big endian systems. UnsafeCopyMemory.java contains a few tests with 'mismatched' source and destination size. These tests use Unsafe.copyMemory to copy 4 bytes between longs and ints. The location of the bytes to be copied (if the copy comes from a long), or the offset into which the bytes should be copied (if the copy is into a long) are different on big and little endian systems.
>> 
>> Copying from a long to int on a little endian system, the bytes to be copied are those present at the long's address.
>> 
>> 
>> src: _ _ _ _ | _ _ _ _
>>      ^ ~ ~ ^ LE copy
>> dst: _ _ _ _
>> 
>> 
>> On BE systems, the bytes are offset by 4.
>> 
>> 
>> src: _ _ _ _ | _ _ _ _
>>                ^ ~ ~ ^ BE copy
>> dst: _ _ _ _
>> 
>> 
>> The situation for copying into a long from an int is analogous.
>> 
>> This PR adds the required offset for the 'mismatched copy' tests. With this change, UnsafeCopyMemory.java now passes on AIX and s390.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Fixes endianess-related testbug in UnsafeCopyMemory.java

Looks good to me otherwise.

test/hotspot/jtreg/compiler/unsafe/UnsafeCopyMemory.java line 28:

> 26:  * @key stress randomness
> 27:  * @library /test/lib
> 28:  * @bug 8283122

We usually don't link test bugs but the `@bug` label should be used to link (VM) bugs that have been found by that test.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7811

From thartmann at openjdk.java.net  Tue Mar 15 09:38:49 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Mar 2022 09:38:49 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity" [v3]
In-Reply-To: <rNWmcAZ05DXjShQlSoWffd-GPSxe-bj7YEX-UKj9p4c=.d1a26a69-7b21-4f20-8254-e7784f2d537e@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
 <rNWmcAZ05DXjShQlSoWffd-GPSxe-bj7YEX-UKj9p4c=.d1a26a69-7b21-4f20-8254-e7784f2d537e@github.com>
Message-ID: <Q6_tGgv4EIWVVCER5fBNjN0AeJ_PvE7klSD6OZpqI-M=.c841c696-37bc-48c2-90dd-039cd5a38bcc@github.com>

On Tue, 15 Mar 2022 00:26:14 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This change adds extra stub space for large values of CodeEntryAlignment, and it changes the test to try large values of CodeEntryAlignment.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename max_stubs --> max_aligned_stubs, update copyright year

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7800

From adinn at openjdk.java.net  Tue Mar 15 09:43:51 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Tue, 15 Mar 2022 09:43:51 GMT
Subject: RFR: 8280510: AArch64: Vectorize operations with loop induction
 variable
In-Reply-To: <w_vldryKEmdOE2X3ksGAVlDHr9ijiS6SozKO7nUNwIM=.cd4f7874-b3be-4719-ba90-19234588a2aa@github.com>
References: <w_vldryKEmdOE2X3ksGAVlDHr9ijiS6SozKO7nUNwIM=.cd4f7874-b3be-4719-ba90-19234588a2aa@github.com>
Message-ID: <OM_Ls384wkJpW16dumDazx1xrcw1kv205wjvjnAtA9Q=.737c7cf9-b9e7-4376-baf1-74102e48c418@github.com>

On Wed, 16 Feb 2022 08:26:14 GMT, Pengfei Li <pli at openjdk.org> wrote:

> AArch64 has SVE instruction of populating incrementing indices into an
> SVE vector register. With this we can vectorize some operations in loop
> with the induction variable operand, such as below.
> 
>   for (int i = 0; i < count; i++) {
>     b[i] = a[i] * i;
>   }
> 
> This patch enables the vectorization of operations with loop induction
> variable by extending current scope of C2 superword vectorizable packs.
> Before this patch, any scalar input node in a vectorizable pack must be
> an out-of-loop invariant. This patch takes the induction variable input
> as consideration. It allows the input to be the iv phi node or phi plus
> its index offset, and creates a `PopulateIndexNode` to generate a vector
> filled with incrementing indices. On AArch64 SVE, final generated code
> for above loop expression is like below.
> 
>   add     x12, x16, x10
>   add     x12, x12, #0x10
>   ld1w    {z16.s}, p7/z, [x12]
>   index   z17.s, w1, #1
>   mul     z17.s, p7/m, z17.s, z16.s
>   add     x10, x17, x10
>   add     x10, x10, #0x10
>   st1w    {z17.s}, p7, [x10]
> 
> As there is no populating index instruction on AArch64 NEON or other
> platforms like x86, a function named `is_populate_index_supported()` is
> created in the VectorNode class for the backend support check.
> 
> Jtreg hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1
> are tested and no issue is found. Hotspot jtreg has existing tests in
> `compiler/c2/cr7192963/Test*Vect.java` covering this kind of use cases so
> no new jtreg is created within this patch. A new JMH is created in this
> patch and tested on a 512-bit SVE machine. Below test result shows the
> performance can be significantly improved in some cases.
> 
>   Benchmark                       Performance
>   IndexVector.exprWithIndex1            ~7.7x
>   IndexVector.exprWithIndex2           ~13.3x
>   IndexVector.indexArrayFill            ~5.7x

src/hotspot/share/opto/superword.cpp line 1327:

> 1325:         if (!s1_in->as_Phi()->is_tripcount(T_INT)) return false;
> 1326:       } else {
> 1327:         if (s1_in->Opcode() != s1_in->Opcode()) return false;

This last line ought to be `s1_in->Opcode() != s2_in->Opcode` but you have replaced `s2` with `s1`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7491

From stuefe at openjdk.java.net  Tue Mar 15 09:49:45 2022
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 15 Mar 2022 09:49:45 GMT
Subject: RFR: 8283122: [AIX, s390] UnsafeCopyMemory 'Mismatched' Tests Fail
 on Big Endian Systems [v2]
In-Reply-To: <FRFoPa-p7cWb82EHao1SdrYBFeZKWidZBcFbWk3wmtE=.4f2639c3-9f99-4ea3-8a91-c0155fc7b15a@github.com>
References: <cdQZg8cHGBnBlCcDG53z2-xzibPwq4zu2SFyOkXYsbU=.99cb9d2f-77a7-450b-9ea7-f5c16fc7a165@github.com>
 <FRFoPa-p7cWb82EHao1SdrYBFeZKWidZBcFbWk3wmtE=.4f2639c3-9f99-4ea3-8a91-c0155fc7b15a@github.com>
Message-ID: <oMm5bFziem_tZcCjXtuf0v_919JK0jrWG3TktWba5Y8=.bb7f4745-9cee-4da6-afd1-031a7189c5e2@github.com>

On Mon, 14 Mar 2022 20:24:08 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> This is a testbug present on big endian systems. UnsafeCopyMemory.java contains a few tests with 'mismatched' source and destination size. These tests use Unsafe.copyMemory to copy 4 bytes between longs and ints. The location of the bytes to be copied (if the copy comes from a long), or the offset into which the bytes should be copied (if the copy is into a long) are different on big and little endian systems.
>> 
>> Copying from a long to int on a little endian system, the bytes to be copied are those present at the long's address.
>> 
>> 
>> src: _ _ _ _ | _ _ _ _
>>      ^ ~ ~ ^ LE copy
>> dst: _ _ _ _
>> 
>> 
>> On BE systems, the bytes are offset by 4.
>> 
>> 
>> src: _ _ _ _ | _ _ _ _
>>                ^ ~ ~ ^ BE copy
>> dst: _ _ _ _
>> 
>> 
>> The situation for copying into a long from an int is analogous.
>> 
>> This PR adds the required offset for the 'mismatched copy' tests. With this change, UnsafeCopyMemory.java now passes on AIX and s390.
>
> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Fixes endianess-related testbug in UnsafeCopyMemory.java

LGTM

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7811

From shade at openjdk.java.net  Tue Mar 15 09:52:38 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 15 Mar 2022 09:52:38 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity" [v3]
In-Reply-To: <rNWmcAZ05DXjShQlSoWffd-GPSxe-bj7YEX-UKj9p4c=.d1a26a69-7b21-4f20-8254-e7784f2d537e@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
 <rNWmcAZ05DXjShQlSoWffd-GPSxe-bj7YEX-UKj9p4c=.d1a26a69-7b21-4f20-8254-e7784f2d537e@github.com>
Message-ID: <0BC3ZlAWw6Lw3--ikTpTru1NuCCG8b5jZPTc5ME8yzs=.bcc609bd-6f29-46c2-8c1a-f751ac5d126e@github.com>

On Tue, 15 Mar 2022 00:26:14 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This change adds extra stub space for large values of CodeEntryAlignment, and it changes the test to try large values of CodeEntryAlignment.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename max_stubs --> max_aligned_stubs, update copyright year

Looks good, thanks for taking care of this.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7800

From adinn at openjdk.java.net  Tue Mar 15 09:56:44 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Tue, 15 Mar 2022 09:56:44 GMT
Subject: RFR: 8280510: AArch64: Vectorize operations with loop induction
 variable
In-Reply-To: <w_vldryKEmdOE2X3ksGAVlDHr9ijiS6SozKO7nUNwIM=.cd4f7874-b3be-4719-ba90-19234588a2aa@github.com>
References: <w_vldryKEmdOE2X3ksGAVlDHr9ijiS6SozKO7nUNwIM=.cd4f7874-b3be-4719-ba90-19234588a2aa@github.com>
Message-ID: <QaYR9x53-K3dIZ19m9w1s0-3IyzV7nI_Pt9Ym_17zzo=.a862f97b-de86-400a-90de-5dc3a1829c1d@github.com>

On Wed, 16 Feb 2022 08:26:14 GMT, Pengfei Li <pli at openjdk.org> wrote:

> AArch64 has SVE instruction of populating incrementing indices into an
> SVE vector register. With this we can vectorize some operations in loop
> with the induction variable operand, such as below.
> 
>   for (int i = 0; i < count; i++) {
>     b[i] = a[i] * i;
>   }
> 
> This patch enables the vectorization of operations with loop induction
> variable by extending current scope of C2 superword vectorizable packs.
> Before this patch, any scalar input node in a vectorizable pack must be
> an out-of-loop invariant. This patch takes the induction variable input
> as consideration. It allows the input to be the iv phi node or phi plus
> its index offset, and creates a `PopulateIndexNode` to generate a vector
> filled with incrementing indices. On AArch64 SVE, final generated code
> for above loop expression is like below.
> 
>   add     x12, x16, x10
>   add     x12, x12, #0x10
>   ld1w    {z16.s}, p7/z, [x12]
>   index   z17.s, w1, #1
>   mul     z17.s, p7/m, z17.s, z16.s
>   add     x10, x17, x10
>   add     x10, x10, #0x10
>   st1w    {z17.s}, p7, [x10]
> 
> As there is no populating index instruction on AArch64 NEON or other
> platforms like x86, a function named `is_populate_index_supported()` is
> created in the VectorNode class for the backend support check.
> 
> Jtreg hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1
> are tested and no issue is found. Hotspot jtreg has existing tests in
> `compiler/c2/cr7192963/Test*Vect.java` covering this kind of use cases so
> no new jtreg is created within this patch. A new JMH is created in this
> patch and tested on a 512-bit SVE machine. Below test result shows the
> performance can be significantly improved in some cases.
> 
>   Benchmark                       Performance
>   IndexVector.exprWithIndex1            ~7.7x
>   IndexVector.exprWithIndex2           ~13.3x
>   IndexVector.indexArrayFill            ~5.7x

The code looks ok to me modulo the cut-and-paste error I highlighted.

Have you any way of ensuring that the generated code is correct (other than the fact that it runs quicker).

Also have you checked this does not invalidate any other SVE tests. I would expect some failures thanks to the cut-and-paste error.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7491

From adinn at openjdk.java.net  Tue Mar 15 09:59:41 2022
From: adinn at openjdk.java.net (Andrew Dinn)
Date: Tue, 15 Mar 2022 09:59:41 GMT
Subject: RFR: 8280510: AArch64: Vectorize operations with loop induction
 variable
In-Reply-To: <w_vldryKEmdOE2X3ksGAVlDHr9ijiS6SozKO7nUNwIM=.cd4f7874-b3be-4719-ba90-19234588a2aa@github.com>
References: <w_vldryKEmdOE2X3ksGAVlDHr9ijiS6SozKO7nUNwIM=.cd4f7874-b3be-4719-ba90-19234588a2aa@github.com>
Message-ID: <_2biiDtiVZ5nX6LLDU58HZL0DsJZFdZ-CXH6ZukE2bo=.0736d896-60bb-42be-8270-f42a49ebe100@github.com>

On Wed, 16 Feb 2022 08:26:14 GMT, Pengfei Li <pli at openjdk.org> wrote:

> AArch64 has SVE instruction of populating incrementing indices into an
> SVE vector register. With this we can vectorize some operations in loop
> with the induction variable operand, such as below.
> 
>   for (int i = 0; i < count; i++) {
>     b[i] = a[i] * i;
>   }
> 
> This patch enables the vectorization of operations with loop induction
> variable by extending current scope of C2 superword vectorizable packs.
> Before this patch, any scalar input node in a vectorizable pack must be
> an out-of-loop invariant. This patch takes the induction variable input
> as consideration. It allows the input to be the iv phi node or phi plus
> its index offset, and creates a `PopulateIndexNode` to generate a vector
> filled with incrementing indices. On AArch64 SVE, final generated code
> for above loop expression is like below.
> 
>   add     x12, x16, x10
>   add     x12, x12, #0x10
>   ld1w    {z16.s}, p7/z, [x12]
>   index   z17.s, w1, #1
>   mul     z17.s, p7/m, z17.s, z16.s
>   add     x10, x17, x10
>   add     x10, x10, #0x10
>   st1w    {z17.s}, p7, [x10]
> 
> As there is no populating index instruction on AArch64 NEON or other
> platforms like x86, a function named `is_populate_index_supported()` is
> created in the VectorNode class for the backend support check.
> 
> Jtreg hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1
> are tested and no issue is found. Hotspot jtreg has existing tests in
> `compiler/c2/cr7192963/Test*Vect.java` covering this kind of use cases so
> no new jtreg is created within this patch. A new JMH is created in this
> patch and tested on a 512-bit SVE machine. Below test result shows the
> performance can be significantly improved in some cases.
> 
>   Benchmark                       Performance
>   IndexVector.exprWithIndex1            ~7.7x
>   IndexVector.exprWithIndex2           ~13.3x
>   IndexVector.indexArrayFill            ~5.7x

It would be a good idea if someone who knows the superword code better than me could comment on this extension to the range of cases covered by superword transformation. This looks like a very useful extension to the range of cases that can be optimized using superword analysis. However, I am not familiar enough with the code to know if this is the best way to proceed or if some other alternative has been considered and might provide a better alternative, especially wrt architectures other than aarch64.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7491

From ihse at openjdk.java.net  Tue Mar 15 10:04:53 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Mar 2022 10:04:53 GMT
Subject: RFR: 8282507: Add a separate license file for hsdis [v2]
In-Reply-To: <5MyWrnj3HJn4PMSxWXAUif2iD-EZex66QsQodlpAEbg=.6fb6a285-3d80-4e4c-b5ad-0b5589ba04d9@github.com>
References: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
 <5MyWrnj3HJn4PMSxWXAUif2iD-EZex66QsQodlpAEbg=.6fb6a285-3d80-4e4c-b5ad-0b5589ba04d9@github.com>
Message-ID: <cl7S3cpGkdSLmL9Srb3t_33J19jL-zyS5_6DI3FQQCs=.b7e73249-ceb7-468f-9099-7f6c307f633d@github.com>

On Mon, 14 Mar 2022 22:27:29 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone help review the addition of LICENSE file to hsdis directory?
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename license file to hsdis-license.txt

Marked as reviewed by ihse (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7649

From jiefu at openjdk.java.net  Tue Mar 15 11:07:47 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 15 Mar 2022 11:07:47 GMT
Subject: RFR: 8283103: compiler/vectorapi/TestMaskedMacroLogicVector.java
 failed due to incorrect os.simpleArch on some platforms [v2]
In-Reply-To: <JkN_rHWJAtMr797VZFYi4MtC7pv4Te0cAK_V3vFlWdc=.7320b329-09c6-4400-b2ac-8239a6498ab4@github.com>
References: <CjftfHfXuWLRaNkh5cKNxlCYYDJpimyQSr5R_3q_1TE=.a8eca94a-8c22-4523-94d9-4cb62b1b706c@github.com>
 <JkN_rHWJAtMr797VZFYi4MtC7pv4Te0cAK_V3vFlWdc=.7320b329-09c6-4400-b2ac-8239a6498ab4@github.com>
Message-ID: <0FcWQ8wua8F5Q4jqBiSvu7oTnSL7YFtG7pl_wRcgXiU=.7c959ca0-c7d4-4ffb-b599-255f627bcfba@github.com>

On Mon, 14 Mar 2022 13:38:19 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> `os.simpleArch` is not set correctly on some platforms, for example on loongarch64 and mips64 ([CODETOOLS-7903120](https://bugs.openjdk.java.net/browse/CODETOOLS-7903120)). This issue aims to let the test work on these platforms.
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use vm.cpu.features

test/hotspot/jtreg/compiler/vectorapi/TestMaskedMacroLogicVector.java line 31:

> 29:  * @modules jdk.incubator.vector
> 30:  * @requires vm.compiler2.enabled
> 31:  * @requires vm.cpu.features ~= ".*avx.*"

The original test seems to be tested only on x86_64, right?
So did you test the fix on x86_32?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7809

From rcastanedalo at openjdk.java.net  Tue Mar 15 11:54:38 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Tue, 15 Mar 2022 11:54:38 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view
Message-ID: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>

This change adds a new view to the Ideal Graph Visualizer showing a classic control-flow graph (CFG) where nodes are serialized within basic blocks and arcs across basic blocks represent control flow:

![cfg](https://user-images.githubusercontent.com/8792647/158367227-1ccfb9e0-bba1-4a80-963e-3e8c5f23c1c4.png)

The CFG provides a higher-level, more compact view of the graph than the existing views, where it can be hard to find the overall structure for all but the smallest graphs:

![sea-vs-cfg](https://user-images.githubusercontent.com/8792647/158366842-f32b1b22-f7ed-4404-bb43-9d5c58a98ec4.png)

![clusters-vs-cfg](https://user-images.githubusercontent.com/8792647/158366861-64561cfa-2553-4c9e-ad59-25acce6b4961.png)

If a schedule is available in the input graph (because it corresponds to the _Global code motion_ phase or later), the CFG, including the serialization of nodes within basic blocks, is derived from it. Otherwise, the CFG is approximated by the C2-specific `ServerCompilerScheduler` class. Dependencies among nodes are shown textually, by extending the label of each node with a list of its inputs:

<p align="center">
    <img width="35%" src="https://user-images.githubusercontent.com/8792647/158367428-5aa222e9-6a5c-4e78-871f-853e5b918599.png">
</p>

The exact information shown about each input can be configured in Tools -> Options -> Tiny Node Text.

The new CFG view is available at the same level as the existing "sea of nodes" (default) and "clustered sea-of-nodes" views. The view can be selected from the main toolbar:

![toolbar](https://user-images.githubusercontent.com/8792647/158367502-ac8d8a29-5f35-4604-acc3-9d563c60e917.png)

The default view shown when opening a new graph can be configured in Tools -> Options -> Default View.

The same functionality available for the existing views also applies to the new CFG:

- node extraction:

![node-extraction](https://user-images.githubusercontent.com/8792647/158371016-f7988eb6-368f-4805-ac7a-2b5611d16d7a.png)

- pop-up information on edges:

![popup](https://user-images.githubusercontent.com/8792647/158367664-495189d5-384c-4b86-a62b-08863420c531.png)

- filtering:

![filtering](https://user-images.githubusercontent.com/8792647/158367690-47b95bcd-7e8e-466e-b71b-f3e7d04c60ac.png)

- quick node and basic block search:

![quick-search](https://user-images.githubusercontent.com/8792647/158367717-8bc90027-8ce7-4071-be04-1d67de6c91dd.png)

- and exporting.

The list of custom filters is extended with three new block-hiding filters:

- `Hide root block`: remove root block and hide all back-edges from exiting blocks that clutter the CFG.

- `Hide uncommon trap blocks`: remove blocks with uncommon traps to simplify following the "hot paths" in the CFG.

- `Hide exception blocks`: remove blocks that create and throw exceptions to also simplify following the "hot paths" in the CFG.

When using the CFG view, it is important to keep in mind that, in graphs corresponding to phases earlier than _Global code motion_, the presented CFG is just one of many possible projections of the sea-of-nodes representation, and that this projection is computed by an approximation of what C2 would do if it scheduled the graph at that stage. The approximation has some known limitations ([JDK-8280568](https://bugs.openjdk.java.net/browse/JDK-8280568), [JDK-8282053](https://bugs.openjdk.java.net/browse/JDK-8282053)). Future work should address these and warn the user when the approximated CFG is known to be inaccurate.

### Testing

#### Functionality

- Tested the above functionality manually on a small selection of graphs.

- Tested automatically that scheduling (approximating C2's GCM and LCM algorithms) and viewing thousands of graphs in the three views does not trigger any assertion failure (by instrumenting IGV to schedule and view graphs as they are loaded and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).

#### Performance

- Measured the scheduling and view creation time for each of the three views on a selection of 22 large graphs (between 2515 and 7329 nodes). On average:

- The change introduces a slight overhead when creating the existing views (2% and 5% for the clustered and non-clustered sea-of-nodes views). This overhead is due to the introduction of abstractions and data structures required by the CFG view.

- The new CFG view is considerably faster to create than the existing ones (4.2x and 2.5x faster than the clustered and non-clustered sea-of-nodes views), as it can be expected, since only basic blocks have to be laid out. Furthermore, the CFG view scales better as the size of the graph increases.

- The change slows down scheduling by 27%. This overhead corresponds to the additional work of approximating C2's LCM, and it is essential for the CFG view. Fortunately, scheduling takes only a fraction of the time needed to create a view (typically no more than a third), and it only needs to run once for each graph, whereas views have to be re-created on node extraction, filtering, etc.

The performance results are [attached](https://github.com/openjdk/jdk/files/8252786/performance-evaluation.ods) (note that each measurement in the sheet corresponds to the median of ten runs).

-------------

Commit messages:
 - Optimize local scheduling: precompute ranks, reuse node data structures
 - Remove also block edges when clearing blocks
 - Add block search functionality
 - Add custom information to CFG edge tooltips
 - Add block filters
 - Add basic control-flow graph view

Changes: https://git.openjdk.java.net/jdk/pull/7817/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7817&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282547
  Stats: 2308 lines in 68 files changed: 1880 ins; 202 del; 226 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7817.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7817/head:pull/7817

PR: https://git.openjdk.java.net/jdk/pull/7817

From duke at openjdk.java.net  Tue Mar 15 13:59:31 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Tue, 15 Mar 2022 13:59:31 GMT
Subject: RFR: 8283122: [AIX, s390] UnsafeCopyMemory 'Mismatched' Tests Fail
 on Big Endian Systems [v3]
In-Reply-To: <cdQZg8cHGBnBlCcDG53z2-xzibPwq4zu2SFyOkXYsbU=.99cb9d2f-77a7-450b-9ea7-f5c16fc7a165@github.com>
References: <cdQZg8cHGBnBlCcDG53z2-xzibPwq4zu2SFyOkXYsbU=.99cb9d2f-77a7-450b-9ea7-f5c16fc7a165@github.com>
Message-ID: <QSAKlsj5W9o2J8OXZtzKnf970iv-gGP-gwJrvdeyGfw=.89f6dba7-ec6b-44f1-a71d-9a60408b792a@github.com>

> This is a testbug present on big endian systems. UnsafeCopyMemory.java contains a few tests with 'mismatched' source and destination size. These tests use Unsafe.copyMemory to copy 4 bytes between longs and ints. The location of the bytes to be copied (if the copy comes from a long), or the offset into which the bytes should be copied (if the copy is into a long) are different on big and little endian systems.
> 
> Copying from a long to int on a little endian system, the bytes to be copied are those present at the long's address.
> 
> 
> src: _ _ _ _ | _ _ _ _
>      ^ ~ ~ ^ LE copy
> dst: _ _ _ _
> 
> 
> On BE systems, the bytes are offset by 4.
> 
> 
> src: _ _ _ _ | _ _ _ _
>                ^ ~ ~ ^ BE copy
> dst: _ _ _ _
> 
> 
> The situation for copying into a long from an int is analogous.
> 
> This PR adds the required offset for the 'mismatched copy' tests. With this change, UnsafeCopyMemory.java now passes on AIX and s390.

Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:

  Removes unneeded bug label

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7811/files
  - new: https://git.openjdk.java.net/jdk/pull/7811/files/8a592c01..30e22822

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7811&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7811&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7811.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7811/head:pull/7811

PR: https://git.openjdk.java.net/jdk/pull/7811

From duke at openjdk.java.net  Tue Mar 15 13:59:32 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Tue, 15 Mar 2022 13:59:32 GMT
Subject: RFR: 8283122: [AIX, s390] UnsafeCopyMemory 'Mismatched' Tests Fail
 on Big Endian Systems [v2]
In-Reply-To: <bLfl50SeMvCF0hKWmZcMCIUb4dk_A8z1b4rZMdSh3bM=.10c73a24-7e9a-4422-a93a-d7c19491ea4e@github.com>
References: <cdQZg8cHGBnBlCcDG53z2-xzibPwq4zu2SFyOkXYsbU=.99cb9d2f-77a7-450b-9ea7-f5c16fc7a165@github.com>
 <FRFoPa-p7cWb82EHao1SdrYBFeZKWidZBcFbWk3wmtE=.4f2639c3-9f99-4ea3-8a91-c0155fc7b15a@github.com>
 <bLfl50SeMvCF0hKWmZcMCIUb4dk_A8z1b4rZMdSh3bM=.10c73a24-7e9a-4422-a93a-d7c19491ea4e@github.com>
Message-ID: <X2pz7R1b8iW-XyBWQgYUwwpB2wX7PT3g5ZKoK_KLEi4=.42ee80f5-7a2e-476b-b5e7-8bed7b7e0e64@github.com>

On Tue, 15 Mar 2022 09:33:49 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   Fixes endianess-related testbug in UnsafeCopyMemory.java
>
> test/hotspot/jtreg/compiler/unsafe/UnsafeCopyMemory.java line 28:
> 
>> 26:  * @key stress randomness
>> 27:  * @library /test/lib
>> 28:  * @bug 8283122
> 
> We usually don't link test bugs but the `@bug` label should be used to link (VM) bugs that have been found by that test.

Good to know. Thanks for your review :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7811

From duke at openjdk.java.net  Tue Mar 15 14:55:42 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Tue, 15 Mar 2022 14:55:42 GMT
Subject: Integrated: 8283122: [AIX, s390] UnsafeCopyMemory 'Mismatched' Tests
 Fail on Big Endian Systems
In-Reply-To: <cdQZg8cHGBnBlCcDG53z2-xzibPwq4zu2SFyOkXYsbU=.99cb9d2f-77a7-450b-9ea7-f5c16fc7a165@github.com>
References: <cdQZg8cHGBnBlCcDG53z2-xzibPwq4zu2SFyOkXYsbU=.99cb9d2f-77a7-450b-9ea7-f5c16fc7a165@github.com>
Message-ID: <pQIq3kfkv2K53KBifrwEeP5m9ORZswGWj5gkfULtVNw=.782211c0-e0e0-481b-809d-53c466364442@github.com>

On Mon, 14 Mar 2022 18:19:46 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

> This is a testbug present on big endian systems. UnsafeCopyMemory.java contains a few tests with 'mismatched' source and destination size. These tests use Unsafe.copyMemory to copy 4 bytes between longs and ints. The location of the bytes to be copied (if the copy comes from a long), or the offset into which the bytes should be copied (if the copy is into a long) are different on big and little endian systems.
> 
> Copying from a long to int on a little endian system, the bytes to be copied are those present at the long's address.
> 
> 
> src: _ _ _ _ | _ _ _ _
>      ^ ~ ~ ^ LE copy
> dst: _ _ _ _
> 
> 
> On BE systems, the bytes are offset by 4.
> 
> 
> src: _ _ _ _ | _ _ _ _
>                ^ ~ ~ ^ BE copy
> dst: _ _ _ _
> 
> 
> The situation for copying into a long from an int is analogous.
> 
> This PR adds the required offset for the 'mismatched copy' tests. With this change, UnsafeCopyMemory.java now passes on AIX and s390.

This pull request has now been integrated.

Changeset: 4de72014
Author:    Tyler Steele <tyler.steele at ibm.com>
Committer: Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4de72014d3a33469399fec6f428f35c47c4cfbe0
Stats:     11 lines in 1 file changed: 9 ins; 0 del; 2 mod

8283122: [AIX, s390] UnsafeCopyMemory 'Mismatched' Tests Fail on Big Endian Systems

Reviewed-by: thartmann, stuefe

-------------

PR: https://git.openjdk.java.net/jdk/pull/7811

From roland at openjdk.java.net  Tue Mar 15 16:00:26 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 15 Mar 2022 16:00:26 GMT
Subject: RFR: 8283187: C2: loop candidate for superword not always unrolled
 fully if superword fails
Message-ID: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>

IdealLoopTree::policy_unroll_slp_analysis() restricts unrolling of
loops that are found to be candidate for superword but if superword
then fails, unrolling doesn't always resume. SuperWord::output() has
logic for that in one of the failure paths but some other paths are
not covered (for instance in the case of the test case). I propose
that superword explictly returns whether it succeeded or not and that
in case of failure, for a main loop, unrolling be attempted again.

-------------

Commit messages:
 - whitespaces
 - fix & test

Changes: https://git.openjdk.java.net/jdk/pull/7822/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7822&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283187
  Stats: 122 lines in 5 files changed: 77 ins; 6 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7822/head:pull/7822

PR: https://git.openjdk.java.net/jdk/pull/7822

From roland at openjdk.java.net  Tue Mar 15 16:09:10 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 15 Mar 2022 16:09:10 GMT
Subject: RFR: 8281429: PhiNode::Value() is too conservative for tripcount of
 CountedLoop
Message-ID: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>

The type for the iv phi of a counted loop is computed from the types
of the phi on loop entry and the type of the limit from the exit
test. Because the exit test is applied to the iv after increment, the
type of the iv phi is at least one less than the limit (for a positive
stride, one more for a negative stride).

Also, for a stride whose absolute value is not 1 and constant init and
limit values, it's possible to compute accurately the iv phi type.

This change caused a few failures and I had to make a few adjustments
to loop opts code as well.

-------------

Commit messages:
 - fix & test

Changes: https://git.openjdk.java.net/jdk/pull/7823/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7823&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281429
  Stats: 152 lines in 5 files changed: 144 ins; 2 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7823.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7823/head:pull/7823

PR: https://git.openjdk.java.net/jdk/pull/7823

From thartmann at openjdk.java.net  Tue Mar 15 16:15:01 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Mar 2022 16:15:01 GMT
Subject: RFR: 8283189: Bad copyright header in UnsafeCopyMemory.java
Message-ID: <v0sKvko5WcIVhb4uwViExWmjIa3RMFCiBxU0Ut-0jBI=.de931de1-b153-4685-a2df-31aea071a87f@github.com>

Please review this trivial fix that adds a missing comma after the copyright date.

Thanks,
Tobias

-------------

Commit messages:
 - 8283189: Bad copyright header in UnsafeCopyMemory.java

Changes: https://git.openjdk.java.net/jdk/pull/7824/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7824&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283189
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7824.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7824/head:pull/7824

PR: https://git.openjdk.java.net/jdk/pull/7824

From chagedorn at openjdk.java.net  Tue Mar 15 16:15:02 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 15 Mar 2022 16:15:02 GMT
Subject: RFR: 8283189: Bad copyright header in UnsafeCopyMemory.java
In-Reply-To: <v0sKvko5WcIVhb4uwViExWmjIa3RMFCiBxU0Ut-0jBI=.de931de1-b153-4685-a2df-31aea071a87f@github.com>
References: <v0sKvko5WcIVhb4uwViExWmjIa3RMFCiBxU0Ut-0jBI=.de931de1-b153-4685-a2df-31aea071a87f@github.com>
Message-ID: <cs337rmu2vgTzklqfSQ2JDuxt8IcbZNp637V_CcBCJU=.cd7310ce-ffb6-4a31-a12c-92f8c8c2dca4@github.com>

On Tue, 15 Mar 2022 16:06:15 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Please review this trivial fix that adds a missing comma after the copyright date.
> 
> Thanks,
> Tobias

Looks good and trivial!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7824

From thartmann at openjdk.java.net  Tue Mar 15 16:15:03 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Mar 2022 16:15:03 GMT
Subject: RFR: 8283189: Bad copyright header in UnsafeCopyMemory.java
In-Reply-To: <v0sKvko5WcIVhb4uwViExWmjIa3RMFCiBxU0Ut-0jBI=.de931de1-b153-4685-a2df-31aea071a87f@github.com>
References: <v0sKvko5WcIVhb4uwViExWmjIa3RMFCiBxU0Ut-0jBI=.de931de1-b153-4685-a2df-31aea071a87f@github.com>
Message-ID: <DPbdqh3fZ6sY-i77A0zINgNFqw7GF_ptZFVq52be5zo=.16710fe9-00bc-45fc-8d62-34931559b3ea@github.com>

On Tue, 15 Mar 2022 16:06:15 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Please review this trivial fix that adds a missing comma after the copyright date.
> 
> Thanks,
> Tobias

Thanks Christian. Will push after quick sanity testing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7824

From dcubed at openjdk.java.net  Tue Mar 15 16:21:48 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 15 Mar 2022 16:21:48 GMT
Subject: RFR: 8283189: Bad copyright header in UnsafeCopyMemory.java
In-Reply-To: <v0sKvko5WcIVhb4uwViExWmjIa3RMFCiBxU0Ut-0jBI=.de931de1-b153-4685-a2df-31aea071a87f@github.com>
References: <v0sKvko5WcIVhb4uwViExWmjIa3RMFCiBxU0Ut-0jBI=.de931de1-b153-4685-a2df-31aea071a87f@github.com>
Message-ID: <QYWcaNqcOkC0BZkJ9_AyBRdAhez2LlhHT07DvLKG2bU=.350c6c90-1710-4033-b41f-aaa83903a10a@github.com>

On Tue, 15 Mar 2022 16:06:15 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Please review this trivial fix that adds a missing comma after the copyright date.
> 
> Thanks,
> Tobias

Marked as reviewed by dcubed (Reviewer).

I've tested the same change on my MBP13 and validate-source now passes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7824

From kcr at openjdk.java.net  Tue Mar 15 16:24:43 2022
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 15 Mar 2022 16:24:43 GMT
Subject: RFR: 8283122: [AIX, s390] UnsafeCopyMemory 'Mismatched' Tests Fail
 on Big Endian Systems [v3]
In-Reply-To: <N963uZCvjI2ErGL9QaOJejU0fSBgheywM7YHdqH4CAo=.23dfc78a-09e9-49e2-b8a6-4797fca34698@github.com>
References: <cdQZg8cHGBnBlCcDG53z2-xzibPwq4zu2SFyOkXYsbU=.99cb9d2f-77a7-450b-9ea7-f5c16fc7a165@github.com>
 <QSAKlsj5W9o2J8OXZtzKnf970iv-gGP-gwJrvdeyGfw=.89f6dba7-ec6b-44f1-a71d-9a60408b792a@github.com>
 <N963uZCvjI2ErGL9QaOJejU0fSBgheywM7YHdqH4CAo=.23dfc78a-09e9-49e2-b8a6-4797fca34698@github.com>
Message-ID: <Nl__NYSvyMC7CKSKV3zh3CavH_Zp2YACW5hWS59fZ2E=.86158261-8c71-4db5-85d6-2401b56070c9@github.com>

On Tue, 15 Mar 2022 16:18:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removes unneeded bug label
>
> test/hotspot/jtreg/compiler/unsafe/UnsafeCopyMemory.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, 2022 Oracle and/or its affiliates. All rights reserved.
> 
> The copyright is missing a "," after 2022.
> Please file a new PR to fix.

This was filed as [JDK-8283189](https://bugs.openjdk.java.net/browse/JDK-8283189) and is out for review at PR #7824

-------------

PR: https://git.openjdk.java.net/jdk/pull/7811

From rriggs at openjdk.java.net  Tue Mar 15 16:24:43 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 15 Mar 2022 16:24:43 GMT
Subject: RFR: 8283122: [AIX, s390] UnsafeCopyMemory 'Mismatched' Tests Fail
 on Big Endian Systems [v3]
In-Reply-To: <QSAKlsj5W9o2J8OXZtzKnf970iv-gGP-gwJrvdeyGfw=.89f6dba7-ec6b-44f1-a71d-9a60408b792a@github.com>
References: <cdQZg8cHGBnBlCcDG53z2-xzibPwq4zu2SFyOkXYsbU=.99cb9d2f-77a7-450b-9ea7-f5c16fc7a165@github.com>
 <QSAKlsj5W9o2J8OXZtzKnf970iv-gGP-gwJrvdeyGfw=.89f6dba7-ec6b-44f1-a71d-9a60408b792a@github.com>
Message-ID: <N963uZCvjI2ErGL9QaOJejU0fSBgheywM7YHdqH4CAo=.23dfc78a-09e9-49e2-b8a6-4797fca34698@github.com>

On Tue, 15 Mar 2022 13:59:31 GMT, Tyler Steele <duke at openjdk.java.net> wrote:

>> This is a testbug present on big endian systems. UnsafeCopyMemory.java contains a few tests with 'mismatched' source and destination size. These tests use Unsafe.copyMemory to copy 4 bytes between longs and ints. The location of the bytes to be copied (if the copy comes from a long), or the offset into which the bytes should be copied (if the copy is into a long) are different on big and little endian systems.
>> 
>> Copying from a long to int on a little endian system, the bytes to be copied are those present at the long's address.
>> 
>> 
>> src: _ _ _ _ | _ _ _ _
>>      ^ ~ ~ ^ LE copy
>> dst: _ _ _ _
>> 
>> 
>> On BE systems, the bytes are offset by 4.
>> 
>> 
>> src: _ _ _ _ | _ _ _ _
>>                ^ ~ ~ ^ BE copy
>> dst: _ _ _ _
>> 
>> 
>> The situation for copying into a long from an int is analogous.
>> 
>> This PR adds the required offset for the 'mismatched copy' tests. With this change, UnsafeCopyMemory.java now passes on AIX and s390.
>
> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes unneeded bug label

test/hotspot/jtreg/compiler/unsafe/UnsafeCopyMemory.java line 2:

> 1: /*
> 2:  * Copyright (c) 2021, 2022 Oracle and/or its affiliates. All rights reserved.

The copyright is missing a "," after 2022.
Please file a new PR to fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7811

From duke at openjdk.java.net  Tue Mar 15 16:27:47 2022
From: duke at openjdk.java.net (Tyler Steele)
Date: Tue, 15 Mar 2022 16:27:47 GMT
Subject: RFR: 8283122: [AIX, s390] UnsafeCopyMemory 'Mismatched' Tests Fail
 on Big Endian Systems [v3]
In-Reply-To: <N963uZCvjI2ErGL9QaOJejU0fSBgheywM7YHdqH4CAo=.23dfc78a-09e9-49e2-b8a6-4797fca34698@github.com>
References: <cdQZg8cHGBnBlCcDG53z2-xzibPwq4zu2SFyOkXYsbU=.99cb9d2f-77a7-450b-9ea7-f5c16fc7a165@github.com>
 <QSAKlsj5W9o2J8OXZtzKnf970iv-gGP-gwJrvdeyGfw=.89f6dba7-ec6b-44f1-a71d-9a60408b792a@github.com>
 <N963uZCvjI2ErGL9QaOJejU0fSBgheywM7YHdqH4CAo=.23dfc78a-09e9-49e2-b8a6-4797fca34698@github.com>
Message-ID: <f0Aq7uvpoK1xT9Rjfd_PLyfLXejF9l1akgTC4R1g5Ao=.c44a13d1-420c-45e1-9e26-ef94fcafe294@github.com>

On Tue, 15 Mar 2022 16:18:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removes unneeded bug label
>
> test/hotspot/jtreg/compiler/unsafe/UnsafeCopyMemory.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2021, 2022 Oracle and/or its affiliates. All rights reserved.
> 
> The copyright is missing a "," after 2022.
> Please file a new PR to fix.

Those copyright lines will be my undoing! Thanks for catching this @RogerRiggs and thanks for fixing it @TobiHartmann.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7811

From thartmann at openjdk.java.net  Tue Mar 15 16:31:42 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Mar 2022 16:31:42 GMT
Subject: Integrated: 8283189: Bad copyright header in UnsafeCopyMemory.java
In-Reply-To: <v0sKvko5WcIVhb4uwViExWmjIa3RMFCiBxU0Ut-0jBI=.de931de1-b153-4685-a2df-31aea071a87f@github.com>
References: <v0sKvko5WcIVhb4uwViExWmjIa3RMFCiBxU0Ut-0jBI=.de931de1-b153-4685-a2df-31aea071a87f@github.com>
Message-ID: <r2g6yB78AuEUsk6JGygX1hmha8mzCxZu01szFEyifXs=.72183a62-9c8c-4184-80df-a24ff12fbd42@github.com>

On Tue, 15 Mar 2022 16:06:15 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Please review this trivial fix that adds a missing comma after the copyright date.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 12dca36c
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/12dca36c73583d0ed2e1f684b056100dc1f2ef55
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8283189: Bad copyright header in UnsafeCopyMemory.java

Reviewed-by: chagedorn, dcubed

-------------

PR: https://git.openjdk.java.net/jdk/pull/7824

From thartmann at openjdk.java.net  Tue Mar 15 16:31:42 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 15 Mar 2022 16:31:42 GMT
Subject: RFR: 8283189: Bad copyright header in UnsafeCopyMemory.java
In-Reply-To: <v0sKvko5WcIVhb4uwViExWmjIa3RMFCiBxU0Ut-0jBI=.de931de1-b153-4685-a2df-31aea071a87f@github.com>
References: <v0sKvko5WcIVhb4uwViExWmjIa3RMFCiBxU0Ut-0jBI=.de931de1-b153-4685-a2df-31aea071a87f@github.com>
Message-ID: <zHom-BhAQPdKIKF4uF8c0O5bJ7LijlEwbn-a1Zoi5Bk=.31e347e3-aef5-41ff-885a-d813285b2649@github.com>

On Tue, 15 Mar 2022 16:06:15 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Please review this trivial fix that adds a missing comma after the copyright date.
> 
> Thanks,
> Tobias

Thanks Daniel!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7824

From lucy at openjdk.java.net  Tue Mar 15 17:10:55 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 15 Mar 2022 17:10:55 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters [v3]
In-Reply-To: <nesf35P-utm5j-xosWGl1mnu1XPvBvfcCTyOALC-CCo=.e27238c3-0a48-4d2b-a788-f6ec2bdb96ca@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
 <nesf35P-utm5j-xosWGl1mnu1XPvBvfcCTyOALC-CCo=.e27238c3-0a48-4d2b-a788-f6ec2bdb96ca@github.com>
Message-ID: <HYIkjWOoMh62-YAGi02uR68NAX_IHqKLfcZ76_PyYlM=.a8803782-eaa4-4c09-83f8-d28ba9b8fdc5@github.com>

On Mon, 28 Feb 2022 17:10:26 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> May I please request reviews for this cleanup and unification change. It streamlines the address operand emitters for all instructions. As such, the modifications are widespread and may be cumbersome to review. Please ask questions if anything is unclear.
>> 
>> SAP does not maintain a full s390x build and test environment any longer. I would therefore very much appreciate if somebody would run a build and test cycle on s390x. 
>> 
>> As this is a s390x-only change, other platforms are not impacted.
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor comment adaptations and code formatting

This is a gentle reminder for anybody out there who is willing and able to provide a second review. This is a pure s390 change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7324

From manc at openjdk.java.net  Tue Mar 15 20:09:52 2022
From: manc at openjdk.java.net (Man Cao)
Date: Tue, 15 Mar 2022 20:09:52 GMT
Subject: Integrated: 8282507: Add a separate license file for hsdis
In-Reply-To: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
References: <1KA6kduxxfIuA9AaRYd31n8qDpmd5eE0CFJpNzBHHUs=.c9387f31-19f1-47dd-8a61-1746f100f1f6@github.com>
Message-ID: <GlOo2wmOrtZBiGeC9kg6CipAiU_htiBlPgXeX9Y4n3o=.4102ba92-101c-493e-a27d-0c6528c907b4@github.com>

On Tue, 1 Mar 2022 20:18:11 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone help review the addition of LICENSE file to hsdis directory?
> 
> -Man

This pull request has now been integrated.

Changeset: ac06bdb1
Author:    Man Cao <manc at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ac06bdb1239a97b7ea2fee8280da8ebc9728dc30
Stats:     35 lines in 1 file changed: 35 ins; 0 del; 0 mod

8282507: Add a separate license file for hsdis

Reviewed-by: ihse

-------------

PR: https://git.openjdk.java.net/jdk/pull/7649

From dlong at openjdk.java.net  Tue Mar 15 20:21:47 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 15 Mar 2022 20:21:47 GMT
Subject: RFR: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity" [v3]
In-Reply-To: <rNWmcAZ05DXjShQlSoWffd-GPSxe-bj7YEX-UKj9p4c=.d1a26a69-7b21-4f20-8254-e7784f2d537e@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
 <rNWmcAZ05DXjShQlSoWffd-GPSxe-bj7YEX-UKj9p4c=.d1a26a69-7b21-4f20-8254-e7784f2d537e@github.com>
Message-ID: <CNwY2TuMM6aw27_ClUX2AqSkbfP16zsJdGKg6hbowCc=.96407bb2-f559-41ca-b81d-4868ee1f3cd4@github.com>

On Tue, 15 Mar 2022 00:26:14 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This change adds extra stub space for large values of CodeEntryAlignment, and it changes the test to try large values of CodeEntryAlignment.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename max_stubs --> max_aligned_stubs, update copyright year

Thanks Aleksey and Tobias.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7800

From dlong at openjdk.java.net  Tue Mar 15 20:21:47 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 15 Mar 2022 20:21:47 GMT
Subject: Integrated: 8282355: compiler/arguments/TestCodeEntryAlignment.java
 failed "guarantee(sect->end() <= tend) failed: sanity"
In-Reply-To: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
References: <4O-MhQ9Ymt-FKCA64KaxCqz6T_joJp5shOSgNl0IYF8=.051d8d11-0f6a-40e7-9efa-b3b6f4803a3c@github.com>
Message-ID: <1la3OcwkNNBZX2Uv5m-covHN9VLf6qxfLfua-NSSgY0=.d5df9368-ba52-447b-8dd2-bf4a1309edf9@github.com>

On Sat, 12 Mar 2022 23:28:43 GMT, Dean Long <dlong at openjdk.org> wrote:

> This change adds extra stub space for large values of CodeEntryAlignment, and it changes the test to try large values of CodeEntryAlignment.

This pull request has now been integrated.

Changeset: 1465ea98
Author:    Dean Long <dlong at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1465ea98b7736b5960a8b546ccc366c3e3260bdd
Stats:     17 lines in 2 files changed: 14 ins; 0 del; 3 mod

8282355: compiler/arguments/TestCodeEntryAlignment.java failed "guarantee(sect->end() <= tend) failed: sanity"

Reviewed-by: jiefu, thartmann, shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/7800

From sviswanathan at openjdk.java.net  Tue Mar 15 23:13:44 2022
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Tue, 15 Mar 2022 23:13:44 GMT
Subject: RFR: 8282414: x86: Enhance the assembler to generate more compact
 instructions [v4]
In-Reply-To: <ypcKly_jm9OQUYxLQGqMv4tc0Z4XDv3Ur5O3N1O4-nU=.f285822f-749b-4f59-9d19-446c0fa835bf@github.com>
References: <a1TTMEGFGtczuNoBlg3G7FruGyHBtxuS_euIoxGUzaE=.a4b51199-d869-4ed9-bda3-b28bfcd2b4e5@github.com>
 <ypcKly_jm9OQUYxLQGqMv4tc0Z4XDv3Ur5O3N1O4-nU=.f285822f-749b-4f59-9d19-446c0fa835bf@github.com>
Message-ID: <D5_DO8lFzC0Ab8yy1BBmBWHlGdg_SlBo1Z26b3TYmUE=.56962321-774b-4fb5-b6b8-6f2d01034612@github.com>

On Sat, 26 Feb 2022 07:44:28 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi, this patch enhances the x86 assembler to emit more compact code for some popular instructions.
>> 
>> For common arithmetic instructions against immediates, if the immediate requires more than 1 byte to encode, we can still shave off 1 byte if the register operand is rax.
>> 
>> For test instruction, since the operation does not write the result, we can downgrade a long to an int and an int to a byte instruction if the immediate is positive and encodable using a smaller amount of bytes.
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7628

From jiefu at openjdk.java.net  Wed Mar 16 00:01:06 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 16 Mar 2022 00:01:06 GMT
Subject: RFR: 8283229: compiler/arguments/TestCodeEntryAlignment.java fails
 with release VMs
Message-ID: <PZWHLnBCoRwtJrK9XYIToSf4sqdJ8gZm6286q1H-hK0=.dc5b4d10-0dfc-46ad-874b-534ac4da3dd9@github.com>

Hi all,

compiler/arguments/TestCodeEntryAlignment.java fails with release VMs due to 'CodeCacheSegmentSize' is develop and is available only in debug version of VM.
The fix would only run with 'CodeCacheSegmentSize' for debug VMs.

Thanks.
Best regards,
Jie

-------------

Commit messages:
 - 8283229: compiler/arguments/TestCodeEntryAlignment.java fails with release VMs

Changes: https://git.openjdk.java.net/jdk/pull/7830/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7830&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283229
  Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7830.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7830/head:pull/7830

PR: https://git.openjdk.java.net/jdk/pull/7830

From duke at openjdk.java.net  Wed Mar 16 01:05:38 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 16 Mar 2022 01:05:38 GMT
Subject: RFR: 8282414: x86: Enhance the assembler to generate more compact
 instructions [v4]
In-Reply-To: <ypcKly_jm9OQUYxLQGqMv4tc0Z4XDv3Ur5O3N1O4-nU=.f285822f-749b-4f59-9d19-446c0fa835bf@github.com>
References: <a1TTMEGFGtczuNoBlg3G7FruGyHBtxuS_euIoxGUzaE=.a4b51199-d869-4ed9-bda3-b28bfcd2b4e5@github.com>
 <ypcKly_jm9OQUYxLQGqMv4tc0Z4XDv3Ur5O3N1O4-nU=.f285822f-749b-4f59-9d19-446c0fa835bf@github.com>
Message-ID: <XKWTVe-8cuyqxJ6K6LMlanYLCt5Ahc5LbXwlIL5M3CU=.88e8d219-001f-482a-885c-ab36fe021321@github.com>

On Sat, 26 Feb 2022 07:44:28 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi, this patch enhances the x86 assembler to emit more compact code for some popular instructions.
>> 
>> For common arithmetic instructions against immediates, if the immediate requires more than 1 byte to encode, we can still shave off 1 byte if the register operand is rax.
>> 
>> For test instruction, since the operation does not write the result, we can downgrade a long to an int and an int to a byte instruction if the immediate is positive and encodable using a smaller amount of bytes.
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment

Thank you very much for the testings and reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7628

From duke at openjdk.java.net  Wed Mar 16 01:13:43 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 16 Mar 2022 01:13:43 GMT
Subject: Integrated: 8282414: x86: Enhance the assembler to generate more
 compact instructions
In-Reply-To: <a1TTMEGFGtczuNoBlg3G7FruGyHBtxuS_euIoxGUzaE=.a4b51199-d869-4ed9-bda3-b28bfcd2b4e5@github.com>
References: <a1TTMEGFGtczuNoBlg3G7FruGyHBtxuS_euIoxGUzaE=.a4b51199-d869-4ed9-bda3-b28bfcd2b4e5@github.com>
Message-ID: <OWFr0qNsqiE4CH_x-kiuO4VwJxoSTccI954mYp8iQt0=.2c9253d6-fdf6-435e-9020-e07de64066b7@github.com>

On Sat, 26 Feb 2022 05:51:54 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi, this patch enhances the x86 assembler to emit more compact code for some popular instructions.
> 
> For common arithmetic instructions against immediates, if the immediate requires more than 1 byte to encode, we can still shave off 1 byte if the register operand is rax.
> 
> For test instruction, since the operation does not write the result, we can downgrade a long to an int and an int to a byte instruction if the immediate is positive and encodable using a smaller amount of bytes.
> 
> Thank you very much.

This pull request has now been integrated.

Changeset: bacfaa3e
Author:    Quan Anh Mai <anhmdq99 at gmail.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bacfaa3ee16882563200ef3b3df4441b33664451
Stats:     92 lines in 3 files changed: 69 ins; 11 del; 12 mod

8282414: x86: Enhance the assembler to generate more compact instructions

Reviewed-by: thartmann, sviswanathan

-------------

PR: https://git.openjdk.java.net/jdk/pull/7628

From duke at openjdk.java.net  Wed Mar 16 01:28:04 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 16 Mar 2022 01:28:04 GMT
Subject: RFR: 8283232: x86: Improve vector broadcast operations
Message-ID: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>

Hi,

This patch improves the generation of broadcasting a scalar in several ways:

- Avoid potential data bypass delay which can be observed on some platforms by using the correct type of instruction if it does not require extra instructions.
- As it has been pointed out, dumping the whole vector into the constant table is costly in terms of code size, this patch minimises this overhead for vector replicate of constants. Also, options are available for constants to be generated with more alignment so that vector load can be made efficiently without crossing cache lines.
- Vector broadcasting should prefer rematerialising to spilling when register pressure is high.

This patch also removes some redundant code paths and rename some incorrectly named instructions.

Thank you very much.

-------------

Commit messages:
 - fix
 - fix
 - minor changes
 - rematerialize
 - improve
 - fix
 - initial commit

Changes: https://git.openjdk.java.net/jdk/pull/7832/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7832&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283232
  Stats: 400 lines in 12 files changed: 237 ins; 79 del; 84 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7832.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7832/head:pull/7832

PR: https://git.openjdk.java.net/jdk/pull/7832

From pli at openjdk.java.net  Wed Mar 16 01:51:20 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Wed, 16 Mar 2022 01:51:20 GMT
Subject: RFR: 8280510: AArch64: Vectorize operations with loop induction
 variable [v2]
In-Reply-To: <w_vldryKEmdOE2X3ksGAVlDHr9ijiS6SozKO7nUNwIM=.cd4f7874-b3be-4719-ba90-19234588a2aa@github.com>
References: <w_vldryKEmdOE2X3ksGAVlDHr9ijiS6SozKO7nUNwIM=.cd4f7874-b3be-4719-ba90-19234588a2aa@github.com>
Message-ID: <CtQ4XEpSWiUZKBZwuILQc5qqMvyTn4-S9YD_JtEhDvo=.678e02c1-29a2-424a-9306-df442854a1cb@github.com>

> AArch64 has SVE instruction of populating incrementing indices into an
> SVE vector register. With this we can vectorize some operations in loop
> with the induction variable operand, such as below.
> 
>   for (int i = 0; i < count; i++) {
>     b[i] = a[i] * i;
>   }
> 
> This patch enables the vectorization of operations with loop induction
> variable by extending current scope of C2 superword vectorizable packs.
> Before this patch, any scalar input node in a vectorizable pack must be
> an out-of-loop invariant. This patch takes the induction variable input
> as consideration. It allows the input to be the iv phi node or phi plus
> its index offset, and creates a `PopulateIndexNode` to generate a vector
> filled with incrementing indices. On AArch64 SVE, final generated code
> for above loop expression is like below.
> 
>   add     x12, x16, x10
>   add     x12, x12, #0x10
>   ld1w    {z16.s}, p7/z, [x12]
>   index   z17.s, w1, #1
>   mul     z17.s, p7/m, z17.s, z16.s
>   add     x10, x17, x10
>   add     x10, x10, #0x10
>   st1w    {z17.s}, p7, [x10]
> 
> As there is no populating index instruction on AArch64 NEON or other
> platforms like x86, a function named `is_populate_index_supported()` is
> created in the VectorNode class for the backend support check.
> 
> Jtreg hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1
> are tested and no issue is found. Hotspot jtreg has existing tests in
> `compiler/c2/cr7192963/Test*Vect.java` covering this kind of use cases so
> no new jtreg is created within this patch. A new JMH is created in this
> patch and tested on a 512-bit SVE machine. Below test result shows the
> performance can be significantly improved in some cases.
> 
>   Benchmark                       Performance
>   IndexVector.exprWithIndex1            ~7.7x
>   IndexVector.exprWithIndex2           ~13.3x
>   IndexVector.indexArrayFill            ~5.7x

Pengfei Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Fix cut-and-paste error
 - Merge branch 'master' into indexvector
 - 8280510: AArch64: Vectorize operations with loop induction variable
   
   AArch64 has SVE instruction of populating incrementing indices into an
   SVE vector register. With this we can vectorize some operations in loop
   with the induction variable operand, such as below.
   
     for (int i = 0; i < count; i++) {
       b[i] = a[i] * i;
     }
   
   This patch enables the vectorization of operations with loop induction
   variable by extending current scope of C2 superword vectorizable packs.
   Before this patch, any scalar input node in a vectorizable pack must be
   an out-of-loop invariant. This patch takes the induction variable input
   as consideration. It allows the input to be the iv phi node or phi plus
   its index offset, and creates a PopulateIndexNode to generate a vector
   filled with incrementing indices. On AArch64 SVE, final generated code
   for above loop expression is like below.
   
     add     x12, x16, x10
     add     x12, x12, #0x10
     ld1w    {z16.s}, p7/z, [x12]
     index   z17.s, w1, #1
     mul     z17.s, p7/m, z17.s, z16.s
     add     x10, x17, x10
     add     x10, x10, #0x10
     st1w    {z17.s}, p7, [x10]
   
   As there is no populating index instruction on AArch64 NEON or other
   platforms like x86, a function named is_populate_index_supported() is
   created in the VectorNode class for the backend support check.
   
   Jtreg hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1
   are tested and no issue is found. Hotspot jtreg has existing tests in
   compiler/c2/cr7192963/Test*Vect.java covering this kind of use cases so
   no new jtreg is created within this patch. A new JMH is created in this
   patch and tested on a 512-bit SVE machine. Below test result shows the
   performance can be significantly improved in some cases.
   
     Benchmark                       Performance
     IndexVector.exprWithIndex1            ~7.7x
     IndexVector.exprWithIndex2           ~13.3x
     IndexVector.indexArrayFill            ~5.7x

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7491/files
  - new: https://git.openjdk.java.net/jdk/pull/7491/files/e85e8ef4..2fdb3e0c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7491&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7491&range=00-01

  Stats: 42778 lines in 1090 files changed: 28920 ins; 7727 del; 6131 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7491.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7491/head:pull/7491

PR: https://git.openjdk.java.net/jdk/pull/7491

From duke at openjdk.java.net  Wed Mar 16 05:55:18 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 16 Mar 2022 05:55:18 GMT
Subject: RFR: 8283232: x86: Improve vector broadcast operations [v2]
In-Reply-To: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
References: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
Message-ID: <1FBk3MauXFxUsyHz9kuhqGI-CtLRgHYmHn1eyyaDLvs=.6d4d94b0-32a0-42dc-a181-87df8d8f3b65@github.com>

> Hi,
> 
> This patch improves the generation of broadcasting a scalar in several ways:
> 
> - Avoid potential data bypass delay which can be observed on some platforms by using the correct type of instruction if it does not require extra instructions.
> - As it has been pointed out, dumping the whole vector into the constant table is costly in terms of code size, this patch minimises this overhead for vector replicate of constants. Also, options are available for constants to be generated with more alignment so that vector load can be made efficiently without crossing cache lines.
> - Vector broadcasting should prefer rematerialising to spilling when register pressure is high.
> 
> This patch also removes some redundant code paths and rename some incorrectly named instructions.
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  fix crash in sse

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7832/files
  - new: https://git.openjdk.java.net/jdk/pull/7832/files/0706aa56..8216d790

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7832&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7832&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7832.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7832/head:pull/7832

PR: https://git.openjdk.java.net/jdk/pull/7832

From pli at openjdk.java.net  Wed Mar 16 06:40:39 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Wed, 16 Mar 2022 06:40:39 GMT
Subject: RFR: 8280510: AArch64: Vectorize operations with loop induction
 variable [v2]
In-Reply-To: <QaYR9x53-K3dIZ19m9w1s0-3IyzV7nI_Pt9Ym_17zzo=.a862f97b-de86-400a-90de-5dc3a1829c1d@github.com>
References: <w_vldryKEmdOE2X3ksGAVlDHr9ijiS6SozKO7nUNwIM=.cd4f7874-b3be-4719-ba90-19234588a2aa@github.com>
 <QaYR9x53-K3dIZ19m9w1s0-3IyzV7nI_Pt9Ym_17zzo=.a862f97b-de86-400a-90de-5dc3a1829c1d@github.com>
Message-ID: <zy57BfG0Gsrinj-ViLlF74XmOVJHz_src-yD0ZJ8DlY=.473540a4-487a-4fee-a516-3bbf13df78a4@github.com>

On Tue, 15 Mar 2022 09:53:28 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> The code looks ok to me modulo the cut-and-paste error I highlighted.

Thanks for your careful review. The cut-and-paste error has been fixed in my updated patch.

> Have you any way of ensuring that the generated code is correct (other than the fact that it runs quicker).
>
> Also have you checked this does not invalidate any other SVE tests. I would expect some failures thanks to the cut-and-paste error.

I've run almost full jtreg on an SVE featured machine and no issue is found. I noticed that existing hotspot jtregs cases in `compiler/c2/cr7192963/Test*Vect.java` have this kind of loop patterns. (Unfortunately, there is no related failure found even with that cut-and-paste error.)

> It would be a good idea if someone who knows the superword code better than me could comment on this extension to the range of cases covered by superword transformation. This looks like a very useful extension to the range of cases that can be optimized using superword analysis. However, I am not familiar enough with the code to know if this is the best way to proceed or if some other alternative has been considered and might provide a better alternative, especially wrt architectures other than aarch64.

I agree. I think people who know superword well are mostly in Oracle so I'd like to see if anyone in Oracle could help look at this. I've considered enabling this for x86. But as I'm not familiar with x86 instruction set enough, I haven't found any instruction(s) to implement such index vector. I would be very glad if someone from Intel can give me some suggestions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7491

From dlong at openjdk.java.net  Wed Mar 16 08:17:44 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 16 Mar 2022 08:17:44 GMT
Subject: RFR: 8283229: compiler/arguments/TestCodeEntryAlignment.java fails
 with release VMs
In-Reply-To: <PZWHLnBCoRwtJrK9XYIToSf4sqdJ8gZm6286q1H-hK0=.dc5b4d10-0dfc-46ad-874b-534ac4da3dd9@github.com>
References: <PZWHLnBCoRwtJrK9XYIToSf4sqdJ8gZm6286q1H-hK0=.dc5b4d10-0dfc-46ad-874b-534ac4da3dd9@github.com>
Message-ID: <WRgs5ZlFURJqTyGId1umt8n369sWYKnWaG9q05CId1o=.7c61acbb-6026-41a9-afbb-787287b79d49@github.com>

On Tue, 15 Mar 2022 23:53:23 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> compiler/arguments/TestCodeEntryAlignment.java fails with release VMs due to 'CodeCacheSegmentSize' is develop and is available only in debug version of VM.
> The fix would only run with 'CodeCacheSegmentSize' for debug VMs.
> 
> Thanks.
> Best regards,
> Jie

Not running this test in product/release builds seems like the wrong fix.  I suggest 2 possible alternatives:
1. Make CodeCacheSegmentSize a product flag.  It doesn't make sense to me for CodeCacheSegmentSize (develop flag), CodeEntryAlignment (experimental, product flag), and OptoLoopAlignment (product flag) to be different kinds of flags.
2. Allow CodeEntryAlignment to change the default value of CodeCacheSegmentSize.  It would also make sense for OptoLoopAlignment to update the default values of CodeEntryAlignment and CodeCacheSegmentSize.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7830

From ddong at openjdk.java.net  Wed Mar 16 09:30:05 2022
From: ddong at openjdk.java.net (Denghui Dong)
Date: Wed, 16 Mar 2022 09:30:05 GMT
Subject: RFR: 8283085: AArch64: No need to leave a breadcrumb for
 JavaFrameAnchor::capture_last_Java_pc when leaf call
Message-ID: <tBYQE_afiNAqcBljcp_lZZ-EVVSBNHhw1ttktUsnF04=.663bffbb-3613-49c4-b89f-6fa0a3fe8692@github.com>

Hi,

Could I have a review of this fix that remove the breadcrumb in `aarch64_enc_java_to_runtime` for `Op_CallLeaf`, `Op_CallLeafNoFP` and `Op_CallNative`.

For more details please refer to the description of the issue.

Thanks,
Denghui

-------------

Commit messages:
 - 8283085: AArch64: No need to leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc when leaf call

Changes: https://git.openjdk.java.net/jdk/pull/7815/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7815&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283085
  Stats: 18 lines in 1 file changed: 9 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7815.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7815/head:pull/7815

PR: https://git.openjdk.java.net/jdk/pull/7815

From aph at openjdk.java.net  Wed Mar 16 09:30:07 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 16 Mar 2022 09:30:07 GMT
Subject: RFR: 8283085: AArch64: No need to leave a breadcrumb for
 JavaFrameAnchor::capture_last_Java_pc when leaf call
In-Reply-To: <tBYQE_afiNAqcBljcp_lZZ-EVVSBNHhw1ttktUsnF04=.663bffbb-3613-49c4-b89f-6fa0a3fe8692@github.com>
References: <tBYQE_afiNAqcBljcp_lZZ-EVVSBNHhw1ttktUsnF04=.663bffbb-3613-49c4-b89f-6fa0a3fe8692@github.com>
Message-ID: <z2RG2A40oxVBRRieYstAMkH20dmiIIC3Lqy7CXRc-KE=.23048f0d-c847-47e3-b9f8-b2bbf5288991@github.com>

On Tue, 15 Mar 2022 09:22:14 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> Hi,
> 
> Could I have a review of this fix that remove the breadcrumb in `aarch64_enc_java_to_runtime` for `Op_CallLeaf`, `Op_CallLeafNoFP` and `Op_CallNative`.
> 
> For more details please refer to the description of the issue.
> 
> Thanks,
> Denghui

While I can see the attraction of this, I don't think we should do it.
It removes information that may be used by the stack unwinder to get accurate stack traces through the transition from Java to native code. Without it, I don't think there's any way for the unwinder to get that information for a crash dump, even with PreserveFramePointer enabled.
See 8277948 for some recent changes in this area.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7815

From ddong at openjdk.java.net  Wed Mar 16 09:30:08 2022
From: ddong at openjdk.java.net (Denghui Dong)
Date: Wed, 16 Mar 2022 09:30:08 GMT
Subject: RFR: 8283085: AArch64: No need to leave a breadcrumb for
 JavaFrameAnchor::capture_last_Java_pc when leaf call
In-Reply-To: <z2RG2A40oxVBRRieYstAMkH20dmiIIC3Lqy7CXRc-KE=.23048f0d-c847-47e3-b9f8-b2bbf5288991@github.com>
References: <tBYQE_afiNAqcBljcp_lZZ-EVVSBNHhw1ttktUsnF04=.663bffbb-3613-49c4-b89f-6fa0a3fe8692@github.com>
 <z2RG2A40oxVBRRieYstAMkH20dmiIIC3Lqy7CXRc-KE=.23048f0d-c847-47e3-b9f8-b2bbf5288991@github.com>
Message-ID: <xyLvUzanbPX-evoE0nrNxrNYWITbUL4-MP627q3tqJM=.582e6b41-1c20-4619-9734-65afb5114f75@github.com>

On Tue, 15 Mar 2022 10:20:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> See 8277948 for some recent changes in this area.

Hi,
I did a quick try and didn't see this patch break the stack trace when PreserveFramePointer is enabled.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7815

From jiefu at openjdk.java.net  Wed Mar 16 09:38:40 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 16 Mar 2022 09:38:40 GMT
Subject: RFR: 8283229: compiler/arguments/TestCodeEntryAlignment.java fails
 with release VMs
In-Reply-To: <WRgs5ZlFURJqTyGId1umt8n369sWYKnWaG9q05CId1o=.7c61acbb-6026-41a9-afbb-787287b79d49@github.com>
References: <PZWHLnBCoRwtJrK9XYIToSf4sqdJ8gZm6286q1H-hK0=.dc5b4d10-0dfc-46ad-874b-534ac4da3dd9@github.com>
 <WRgs5ZlFURJqTyGId1umt8n369sWYKnWaG9q05CId1o=.7c61acbb-6026-41a9-afbb-787287b79d49@github.com>
Message-ID: <ZFLQL0vvYZihT2vpsNVWSwDzHe1oFbf9pnK6S0S_jQk=.d310e3f8-e53a-4426-9c43-c333a318fe02@github.com>

On Wed, 16 Mar 2022 08:14:10 GMT, Dean Long <dlong at openjdk.org> wrote:

> 1. Make CodeCacheSegmentSize a product flag.  It doesn't make sense to me for CodeCacheSegmentSize (develop flag), CodeEntryAlignment (experimental, product flag), and OptoLoopAlignment (product flag) to be different kinds of flags.

Thanks @dean-long for your review and comments.
So do we need a CSR if we make CodeCacheSegmentSize a product flag?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7830

From dlong at openjdk.java.net  Wed Mar 16 09:59:40 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 16 Mar 2022 09:59:40 GMT
Subject: RFR: 8283229: compiler/arguments/TestCodeEntryAlignment.java fails
 with release VMs
In-Reply-To: <ZFLQL0vvYZihT2vpsNVWSwDzHe1oFbf9pnK6S0S_jQk=.d310e3f8-e53a-4426-9c43-c333a318fe02@github.com>
References: <PZWHLnBCoRwtJrK9XYIToSf4sqdJ8gZm6286q1H-hK0=.dc5b4d10-0dfc-46ad-874b-534ac4da3dd9@github.com>
 <WRgs5ZlFURJqTyGId1umt8n369sWYKnWaG9q05CId1o=.7c61acbb-6026-41a9-afbb-787287b79d49@github.com>
 <ZFLQL0vvYZihT2vpsNVWSwDzHe1oFbf9pnK6S0S_jQk=.d310e3f8-e53a-4426-9c43-c333a318fe02@github.com>
Message-ID: <WH02BEayIz0C6KpAV4pvVLZ2BBjpDqWSkoCdQJE98eI=.29b1a3da-acfb-4e74-ba2b-0cca2fdbb88a@github.com>

On Wed, 16 Mar 2022 09:35:16 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>  So do we need a CSR if we make CodeCacheSegmentSize a product flag?

@DamonFool, good question.  I was assuming no, because I didn't see a CSR for JDK-8281467 when it made CodeEntryAlignment a product flag.  @dholmes-ora, do you know?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7830

From aph at openjdk.java.net  Wed Mar 16 11:11:47 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 16 Mar 2022 11:11:47 GMT
Subject: RFR: 8283085: AArch64: No need to leave a breadcrumb for
 JavaFrameAnchor::capture_last_Java_pc when leaf call
In-Reply-To: <xyLvUzanbPX-evoE0nrNxrNYWITbUL4-MP627q3tqJM=.582e6b41-1c20-4619-9734-65afb5114f75@github.com>
References: <tBYQE_afiNAqcBljcp_lZZ-EVVSBNHhw1ttktUsnF04=.663bffbb-3613-49c4-b89f-6fa0a3fe8692@github.com>
 <z2RG2A40oxVBRRieYstAMkH20dmiIIC3Lqy7CXRc-KE=.23048f0d-c847-47e3-b9f8-b2bbf5288991@github.com>
 <xyLvUzanbPX-evoE0nrNxrNYWITbUL4-MP627q3tqJM=.582e6b41-1c20-4619-9734-65afb5114f75@github.com>
Message-ID: <PThp9EoKkOGg5iDm-Ka4BeLymz04uPO_3sn9nU4SiJ0=.e9f779bb-4370-4dc5-985a-f73320aa72b3@github.com>

On Wed, 16 Mar 2022 03:50:39 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> > See 8277948 for some recent changes in this area.
> 
> Hi, I did a quick try and didn't see this patch break the stack trace when PreserveFramePointer is enabled.

Yes, that's interesting. I just stepped through the code and you may well be right.

I'll have to have a good think about this. I'm reluctant to make changes in this area because stack walking code is used in many places, and it's difficult to check everything. Also, it seems to me that the expected gain from removing the few instructions is quite small, and may be so small that it's immeasurable, so the question is how much time is justified.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7815

From jbhateja at openjdk.java.net  Wed Mar 16 13:20:45 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 16 Mar 2022 13:20:45 GMT
Subject: RFR: 8283232: x86: Improve vector broadcast operations [v2]
In-Reply-To: <1FBk3MauXFxUsyHz9kuhqGI-CtLRgHYmHn1eyyaDLvs=.6d4d94b0-32a0-42dc-a181-87df8d8f3b65@github.com>
References: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
 <1FBk3MauXFxUsyHz9kuhqGI-CtLRgHYmHn1eyyaDLvs=.6d4d94b0-32a0-42dc-a181-87df8d8f3b65@github.com>
Message-ID: <m18e8VI_ZcE8RhfM9aO60sqSYesH7ylJY2_Y3mM2268=.0004fd3f-bc61-4315-8ffe-c5e1550581db@github.com>

On Wed, 16 Mar 2022 05:55:18 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch improves the generation of broadcasting a scalar in several ways:
>> 
>> - Avoid potential data bypass delay which can be observed on some platforms by using the correct type of instruction if it does not require extra instructions.
>> - As it has been pointed out, dumping the whole vector into the constant table is costly in terms of code size, this patch minimises this overhead for vector replicate of constants. Also, options are available for constants to be generated with more alignment so that vector load can be made efficiently without crossing cache lines.
>> - Vector broadcasting should prefer rematerialising to spilling when register pressure is high.
>> 
>> This patch also removes some redundant code paths and rename some incorrectly named instructions.
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix crash in sse

Will be helpful  if a JMH can be created around this, following is the except from  X86 Optimizations manual Appendix E Section E.1.3 
"Forwarding the result within the same bypass domain from a producer micro-op to a consumer micro is done efficiently in hardware without delay"

-------------

PR: https://git.openjdk.java.net/jdk/pull/7832

From chagedorn at openjdk.java.net  Wed Mar 16 14:13:45 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 16 Mar 2022 14:13:45 GMT
Subject: RFR: 8282592: C2: assert(false) failed: graph should be
 schedulable [v2]
In-Reply-To: <rYKeXamlwlpn7dIGy99R_1KUbZaBhUkjINHzR7iDm94=.825ccf55-d66c-40ae-bbf2-2e444e71b234@github.com>
References: <-oXZLZYrKlxysFQgwKntZUr7dqC6G_WBEzi-ngqwqws=.c1ab815a-9065-4aba-9948-b3df225d0d3e@github.com>
 <rYKeXamlwlpn7dIGy99R_1KUbZaBhUkjINHzR7iDm94=.825ccf55-d66c-40ae-bbf2-2e444e71b234@github.com>
Message-ID: <Xq00k6LNsylBWqz5BbLGpTXqgvXeoWj-PMA-a-MSYiU=.45df5f9f-beab-4b82-9933-e12e167c5a07@github.com>

On Mon, 14 Mar 2022 09:16:52 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This is another case of overunrolling that causes the type of the main
>> loop's iv to conflict with a ConvI2L of an array access. Skeleton
>> predicates were added to solve this family of issues. A predicate that
>> should catch that the main loop is unreachable is indeed added but the
>> predicate's condition doesn't constant fold.
>> 
>> What happens is that the main loop's iv phi initial value is a CastII
>> (added by PhaseIdealLoop::cast_incr_before_loop()). That CastII is
>> input to the predicates above the main loop and of the main loop's iv
>> phi. Once loop opts are over, the type of the CastII is updated by
>> CastIINode::Value() (the logic that looks at the test that guards the
>> CastII). The type update causes the main loop iv phi's type to be
>> updated and a ConvI2L to be become top. The predicate that should
>> catch the overunrolling has the shape:
>> 
>> (CmpU (AddI#1 (CastII (AddI#2 (Phi ..) ConI#1)) ConI#2) ConI#3)
>> 
>> In the case of the test case:
>> 
>> ConI#3 = 10
>> ConI#2 = 7
>> ConI#1 = 1
>> 
>> CastII has type = int:<=max-8
>> Phi has type = int:>=8
>> 
>> As a result:
>> AddI#2 has type int
>> AddI#1 has type int:min+7..max-1
>> 
>> The Phi is the pre loop Phi.
>> 
>> The fix I propose is that predicates when they are updated should skip
>> over the CastII, that is in this case:
>> 
>> (CmpU (AddI#1 (AddI#2 (Phi ..) ConI#1) ConI#2) ConI#3)
>> 
>> which is reshaped to:
>> 
>> (CmpU (AddI#1' (Phi ..) ConI#1') ConI#3)
>> 
>> In this case:
>> 
>> ConI#1 = 4 (because the predicate constant fold in earlier passes of
>> unrolling)
>> 
>> As a result AddI#1' still has type int But CmpUNode has special logic
>> to deal with the (CmpU (AddI ...)) shape and it can determine that
>> this one always fails.
>> 
>> The role of the CastII is to enforce the dependency between nodes in
>> the loop and the the loop entry test so it's not required for
>> predicates.
>> 
>> With that change, compiler/loopopts/TestOverunrolling.java fails
>> because a predicate doesn't constant fold anymore. The reason in that
>> case, is that PhaseIdealLoop::reorg_offsets() adds an Opaque2 between
>> the pre loop iv phi and the predicate that hides the type of the iv
>> phi. Without the change, the CastII captures the type of the iv phi
>> and the Opaque2 node is added between the CastII and the pre loop iv
>> phi. To solve that problem, I propose that
>> PhaseIdealLoop::reorg_offsets() always add a CastII after the Opaque2
>> so the type of the iv phi is not lost.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - test run failure
>  - Merge branch 'master' into JDK-8282592
>  - test & fix

Testing looked good!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7758

From duke at openjdk.java.net  Wed Mar 16 14:48:27 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Wed, 16 Mar 2022 14:48:27 GMT
Subject: RFR: 8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0)
 failed: Don't process dead nodes [v5]
In-Reply-To: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
References: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
Message-ID: <urUzBha3x6Quy4oz0Gt7E0GLn7IiDWdzPXCFHLClaZY=.5b5293e1-5309-49e5-81cf-010ebd13b65b@github.com>

> Problem:
> Sometimes nodes are generated, and then not properly added to any other node, nor added to the worklist, so that it could be deleted. In some cases, a node can thus survive after IGVN and enter into `ConnectionGraph::compute_escape`, where no dead nodes are expected (except constants).
> 
> In `ArrayCopyNode::prepare_array_copy`:
> In one, I now add the new ConvI2LNode to the worklist if we are aborting.
> In the other case, I could safely reorder the code, such new ConvI2LNode would only be generated once we know we are not going to abort.
> 
> In `SubTypeCheckNode::Ideal`:
> Replaced `set_req` with `set_req_X`, such that the input-node that is replaced (which is now potentially a dead node) is put on the worklist.
> 
> In `ArrayCopyNode::Ideal`:
> If we decide to `return NULL` we also need to add the potentially dead forward / backward memory nodes to the worklist, they may turn out to be dead.
> 
> Added a regression test: the test + flag combination that first reproduced this issue.
> 
> All Tests, including this new regression test are passing.

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  implement review suggestions from Tobias

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7728/files
  - new: https://git.openjdk.java.net/jdk/pull/7728/files/2a50afde..5f68319d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7728&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7728&range=03-04

  Stats: 17 lines in 1 file changed: 5 ins; 9 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7728.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7728/head:pull/7728

PR: https://git.openjdk.java.net/jdk/pull/7728

From duke at openjdk.java.net  Wed Mar 16 14:55:48 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 16 Mar 2022 14:55:48 GMT
Subject: RFR: 8283232: x86: Improve vector broadcast operations [v2]
In-Reply-To: <1FBk3MauXFxUsyHz9kuhqGI-CtLRgHYmHn1eyyaDLvs=.6d4d94b0-32a0-42dc-a181-87df8d8f3b65@github.com>
References: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
 <1FBk3MauXFxUsyHz9kuhqGI-CtLRgHYmHn1eyyaDLvs=.6d4d94b0-32a0-42dc-a181-87df8d8f3b65@github.com>
Message-ID: <E5nFnqGvOizjwiFE0GPIlX4J9ejI82tI389h0j4MHEc=.59f1222f-40ba-4554-b127-90e7dcd1ab39@github.com>

On Wed, 16 Mar 2022 05:55:18 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch improves the generation of broadcasting a scalar in several ways:
>> 
>> - Avoid potential data bypass delay which can be observed on some platforms by using the correct type of instruction if it does not require extra instructions.
>> - As it has been pointed out, dumping the whole vector into the constant table is costly in terms of code size, this patch minimises this overhead for vector replicate of constants. Also, options are available for constants to be generated with more alignment so that vector load can be made efficiently without crossing cache lines.
>> - Vector broadcasting should prefer rematerialising to spilling when register pressure is high.
>> 
>> This patch also removes some redundant code paths and rename some incorrectly named instructions.
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix crash in sse

Hi, forwarding results within the same bypass domain does not result in delay, data bypass delay happens when the data crosses different domains, according to "Intel? 64 and IA-32 Architectures Optimization Reference Manual"

> When a source of a micro-op executed in one stack comes from a micro-op executed in another stack, a delay can occur. The delay occurs also for transitions between Intel SSE integer and Intel SSE floating-point operations. In some of the cases, the data transition is done using a micro-op that is added to the instruction flow.

The manual mentions the guideline at section 3.5.2.2

![image](https://user-images.githubusercontent.com/49088128/158618209-c0674ba7-1c93-4014-a7e1-330f4e5846da.png)

Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7832

From chagedorn at openjdk.java.net  Wed Mar 16 14:59:47 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 16 Mar 2022 14:59:47 GMT
Subject: RFR: 8282592: C2: assert(false) failed: graph should be
 schedulable [v2]
In-Reply-To: <rYKeXamlwlpn7dIGy99R_1KUbZaBhUkjINHzR7iDm94=.825ccf55-d66c-40ae-bbf2-2e444e71b234@github.com>
References: <-oXZLZYrKlxysFQgwKntZUr7dqC6G_WBEzi-ngqwqws=.c1ab815a-9065-4aba-9948-b3df225d0d3e@github.com>
 <rYKeXamlwlpn7dIGy99R_1KUbZaBhUkjINHzR7iDm94=.825ccf55-d66c-40ae-bbf2-2e444e71b234@github.com>
Message-ID: <50PwxRb75z9saNGSaEGe2hGTH95LYM78EApH2An7X0A=.b1dcbf02-2d2d-4c34-add4-78be74ef7257@github.com>

On Mon, 14 Mar 2022 09:16:52 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This is another case of overunrolling that causes the type of the main
>> loop's iv to conflict with a ConvI2L of an array access. Skeleton
>> predicates were added to solve this family of issues. A predicate that
>> should catch that the main loop is unreachable is indeed added but the
>> predicate's condition doesn't constant fold.
>> 
>> What happens is that the main loop's iv phi initial value is a CastII
>> (added by PhaseIdealLoop::cast_incr_before_loop()). That CastII is
>> input to the predicates above the main loop and of the main loop's iv
>> phi. Once loop opts are over, the type of the CastII is updated by
>> CastIINode::Value() (the logic that looks at the test that guards the
>> CastII). The type update causes the main loop iv phi's type to be
>> updated and a ConvI2L to be become top. The predicate that should
>> catch the overunrolling has the shape:
>> 
>> (CmpU (AddI#1 (CastII (AddI#2 (Phi ..) ConI#1)) ConI#2) ConI#3)
>> 
>> In the case of the test case:
>> 
>> ConI#3 = 10
>> ConI#2 = 7
>> ConI#1 = 1
>> 
>> CastII has type = int:<=max-8
>> Phi has type = int:>=8
>> 
>> As a result:
>> AddI#2 has type int
>> AddI#1 has type int:min+7..max-1
>> 
>> The Phi is the pre loop Phi.
>> 
>> The fix I propose is that predicates when they are updated should skip
>> over the CastII, that is in this case:
>> 
>> (CmpU (AddI#1 (AddI#2 (Phi ..) ConI#1) ConI#2) ConI#3)
>> 
>> which is reshaped to:
>> 
>> (CmpU (AddI#1' (Phi ..) ConI#1') ConI#3)
>> 
>> In this case:
>> 
>> ConI#1 = 4 (because the predicate constant fold in earlier passes of
>> unrolling)
>> 
>> As a result AddI#1' still has type int But CmpUNode has special logic
>> to deal with the (CmpU (AddI ...)) shape and it can determine that
>> this one always fails.
>> 
>> The role of the CastII is to enforce the dependency between nodes in
>> the loop and the the loop entry test so it's not required for
>> predicates.
>> 
>> With that change, compiler/loopopts/TestOverunrolling.java fails
>> because a predicate doesn't constant fold anymore. The reason in that
>> case, is that PhaseIdealLoop::reorg_offsets() adds an Opaque2 between
>> the pre loop iv phi and the predicate that hides the type of the iv
>> phi. Without the change, the CastII captures the type of the iv phi
>> and the Opaque2 node is added between the CastII and the pre loop iv
>> phi. To solve that problem, I propose that
>> PhaseIdealLoop::reorg_offsets() always add a CastII after the Opaque2
>> so the type of the iv phi is not lost.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - test run failure
>  - Merge branch 'master' into JDK-8282592
>  - test & fix

This looks reasonable to me.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7758

From jbhateja at openjdk.java.net  Wed Mar 16 15:59:53 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 16 Mar 2022 15:59:53 GMT
Subject: RFR: 8283232: x86: Improve vector broadcast operations [v2]
In-Reply-To: <E5nFnqGvOizjwiFE0GPIlX4J9ejI82tI389h0j4MHEc=.59f1222f-40ba-4554-b127-90e7dcd1ab39@github.com>
References: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
 <1FBk3MauXFxUsyHz9kuhqGI-CtLRgHYmHn1eyyaDLvs=.6d4d94b0-32a0-42dc-a181-87df8d8f3b65@github.com>
 <E5nFnqGvOizjwiFE0GPIlX4J9ejI82tI389h0j4MHEc=.59f1222f-40ba-4554-b127-90e7dcd1ab39@github.com>
Message-ID: <IA55ETrCc1oefjTpEJMVT9WeMhUSnHpX1HWxOJrqRn8=.811844d5-168d-4536-abb2-bf48eacf9a39@github.com>

On Wed, 16 Mar 2022 14:52:07 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi, forwarding results within the same bypass domain does not result in delay, data bypass delay happens when the data crosses different domains, according to "Intel? 64 and IA-32 Architectures Optimization Reference Manual"
> 
> > When a source of a micro-op executed in one stack comes from a micro-op executed in another stack, a delay can occur. The delay occurs also for transitions between Intel SSE integer and Intel SSE floating-point operations. In some of the cases, the data transition is done using a micro-op that is added to the instruction flow.
> 
> The manual mentions the guideline at section 3.5.2.2
> 
> ![image](https://user-images.githubusercontent.com/49088128/158618209-c0674ba7-1c93-4014-a7e1-330f4e5846da.png)
> 
> Thanks.

Thanks meant to refer to above text.  I have removed incorrect reference.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7832

From dcubed at openjdk.java.net  Wed Mar 16 16:27:48 2022
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 16 Mar 2022 16:27:48 GMT
Subject: RFR: 8283229: compiler/arguments/TestCodeEntryAlignment.java fails
 with release VMs
In-Reply-To: <PZWHLnBCoRwtJrK9XYIToSf4sqdJ8gZm6286q1H-hK0=.dc5b4d10-0dfc-46ad-874b-534ac4da3dd9@github.com>
References: <PZWHLnBCoRwtJrK9XYIToSf4sqdJ8gZm6286q1H-hK0=.dc5b4d10-0dfc-46ad-874b-534ac4da3dd9@github.com>
Message-ID: <IXFeh_Dq9nWPK7am_RvtocGAR5KCdtG_ExJ_Re7RKAs=.61ffc865-ee4f-4db6-8f18-2fb7fd155f0a@github.com>

On Tue, 15 Mar 2022 23:53:23 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> compiler/arguments/TestCodeEntryAlignment.java fails with release VMs due to 'CodeCacheSegmentSize' is develop and is available only in debug version of VM.
> The fix would only run with 'CodeCacheSegmentSize' for debug VMs.
> 
> Thanks.
> Best regards,
> Jie

@dholmes-ora is on vacation at the moment so a CSR related response
from him will likely be delayed.

This test failure has started showing up in Tier6 testing. We don't have
a way of ProblemListing a test just for 'release' bits. It would be good to
get some solution in place quickly even if we modify that solution down
the road.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7830

From jbhateja at openjdk.java.net  Wed Mar 16 17:28:43 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Wed, 16 Mar 2022 17:28:43 GMT
Subject: RFR: 8283232: x86: Improve vector broadcast operations [v2]
In-Reply-To: <IA55ETrCc1oefjTpEJMVT9WeMhUSnHpX1HWxOJrqRn8=.811844d5-168d-4536-abb2-bf48eacf9a39@github.com>
References: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
 <1FBk3MauXFxUsyHz9kuhqGI-CtLRgHYmHn1eyyaDLvs=.6d4d94b0-32a0-42dc-a181-87df8d8f3b65@github.com>
 <E5nFnqGvOizjwiFE0GPIlX4J9ejI82tI389h0j4MHEc=.59f1222f-40ba-4554-b127-90e7dcd1ab39@github.com>
 <IA55ETrCc1oefjTpEJMVT9WeMhUSnHpX1HWxOJrqRn8=.811844d5-168d-4536-abb2-bf48eacf9a39@github.com>
Message-ID: <XuCLCrdHxps8Qiq9GQbZv01pml_ln4bet_QUEDh8DHs=.ebba8985-7407-455c-b2b8-046112a7c373@github.com>

On Wed, 16 Mar 2022 15:56:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > Hi, forwarding results within the same bypass domain does not result in delay, data bypass delay happens when the data crosses different domains, according to "Intel? 64 and IA-32 Architectures Optimization Reference Manual"
> > > When a source of a micro-op executed in one stack comes from a micro-op executed in another stack, a delay can occur. The delay occurs also for transitions between Intel SSE integer and Intel SSE floating-point operations. In some of the cases, the data transition is done using a micro-op that is added to the instruction flow.
> > 
> > 
> > The manual mentions the guideline at section 3.5.2.2
> > ![image](https://user-images.githubusercontent.com/49088128/158618209-c0674ba7-1c93-4014-a7e1-330f4e5846da.png)
> > Thanks.
> 
> Thanks meant to refer to above text. I have removed incorrect reference.

It will still be good if we can come up with a micro benchmark, that shows the gain with the patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7832

From dlong at openjdk.java.net  Wed Mar 16 20:39:40 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Wed, 16 Mar 2022 20:39:40 GMT
Subject: RFR: 8283229: compiler/arguments/TestCodeEntryAlignment.java fails
 with release VMs
In-Reply-To: <ZFLQL0vvYZihT2vpsNVWSwDzHe1oFbf9pnK6S0S_jQk=.d310e3f8-e53a-4426-9c43-c333a318fe02@github.com>
References: <PZWHLnBCoRwtJrK9XYIToSf4sqdJ8gZm6286q1H-hK0=.dc5b4d10-0dfc-46ad-874b-534ac4da3dd9@github.com>
 <WRgs5ZlFURJqTyGId1umt8n369sWYKnWaG9q05CId1o=.7c61acbb-6026-41a9-afbb-787287b79d49@github.com>
 <ZFLQL0vvYZihT2vpsNVWSwDzHe1oFbf9pnK6S0S_jQk=.d310e3f8-e53a-4426-9c43-c333a318fe02@github.com>
Message-ID: <z0FNt1OzVXdPe73uZSrm0mpTi1c1rIO4dCa_wbjMwCM=.6b5764c4-9690-4d34-909b-29de4d5adac6@github.com>

On Wed, 16 Mar 2022 09:35:16 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Not running this test in product/release builds seems like the wrong fix.  I suggest 2 possible alternatives:
>> 1. Make CodeCacheSegmentSize a product flag.  It doesn't make sense to me for CodeCacheSegmentSize (develop flag), CodeEntryAlignment (experimental, product flag), and OptoLoopAlignment (product flag) to be different kinds of flags.
>> 2. Allow CodeEntryAlignment to change the default value of CodeCacheSegmentSize.  It would also make sense for OptoLoopAlignment to update the default values of CodeEntryAlignment and CodeCacheSegmentSize.
>
>> 1. Make CodeCacheSegmentSize a product flag.  It doesn't make sense to me for CodeCacheSegmentSize (develop flag), CodeEntryAlignment (experimental, product flag), and OptoLoopAlignment (product flag) to be different kinds of flags.
> 
> Thanks @dean-long for your review and comments.
> So do we need a CSR if we make CodeCacheSegmentSize a product flag?

@DamonFool I think the right thing to do is to use

@requires vm.debug

for now to fix the test failures, then file a new RFE to make CodeCacheSegmentSize a product flag and clean up the test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7830

From jiefu at openjdk.java.net  Wed Mar 16 23:12:29 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 16 Mar 2022 23:12:29 GMT
Subject: RFR: 8283229: compiler/arguments/TestCodeEntryAlignment.java fails
 with release VMs [v2]
In-Reply-To: <PZWHLnBCoRwtJrK9XYIToSf4sqdJ8gZm6286q1H-hK0=.dc5b4d10-0dfc-46ad-874b-534ac4da3dd9@github.com>
References: <PZWHLnBCoRwtJrK9XYIToSf4sqdJ8gZm6286q1H-hK0=.dc5b4d10-0dfc-46ad-874b-534ac4da3dd9@github.com>
Message-ID: <y-61Z1yQjKrE8a08DimmLwWSjhO_iduDPnR3KozyLTI=.74d259a1-a855-4c83-975b-072addaa72fa@github.com>

> Hi all,
> 
> compiler/arguments/TestCodeEntryAlignment.java fails with release VMs due to 'CodeCacheSegmentSize' is develop and is available only in debug version of VM.
> The fix would only run with 'CodeCacheSegmentSize' for debug VMs.
> 
> Thanks.
> Best regards,
> Jie

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7830/files
  - new: https://git.openjdk.java.net/jdk/pull/7830/files/f1ec57e8..2b16c14e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7830&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7830&range=00-01

  Stats: 10 lines in 1 file changed: 1 ins; 3 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7830.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7830/head:pull/7830

PR: https://git.openjdk.java.net/jdk/pull/7830

From jiefu at openjdk.java.net  Wed Mar 16 23:12:30 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 16 Mar 2022 23:12:30 GMT
Subject: RFR: 8283229: compiler/arguments/TestCodeEntryAlignment.java fails
 with release VMs
In-Reply-To: <ZFLQL0vvYZihT2vpsNVWSwDzHe1oFbf9pnK6S0S_jQk=.d310e3f8-e53a-4426-9c43-c333a318fe02@github.com>
References: <PZWHLnBCoRwtJrK9XYIToSf4sqdJ8gZm6286q1H-hK0=.dc5b4d10-0dfc-46ad-874b-534ac4da3dd9@github.com>
 <WRgs5ZlFURJqTyGId1umt8n369sWYKnWaG9q05CId1o=.7c61acbb-6026-41a9-afbb-787287b79d49@github.com>
 <ZFLQL0vvYZihT2vpsNVWSwDzHe1oFbf9pnK6S0S_jQk=.d310e3f8-e53a-4426-9c43-c333a318fe02@github.com>
Message-ID: <J1pYILJ5xUP6AuFvea_TW53XWoC_YADglEpTSXNuVU0=.72af7da2-2507-4f81-a73b-279144dfed7d@github.com>

On Wed, 16 Mar 2022 09:35:16 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Not running this test in product/release builds seems like the wrong fix.  I suggest 2 possible alternatives:
>> 1. Make CodeCacheSegmentSize a product flag.  It doesn't make sense to me for CodeCacheSegmentSize (develop flag), CodeEntryAlignment (experimental, product flag), and OptoLoopAlignment (product flag) to be different kinds of flags.
>> 2. Allow CodeEntryAlignment to change the default value of CodeCacheSegmentSize.  It would also make sense for OptoLoopAlignment to update the default values of CodeEntryAlignment and CodeCacheSegmentSize.
>
>> 1. Make CodeCacheSegmentSize a product flag.  It doesn't make sense to me for CodeCacheSegmentSize (develop flag), CodeEntryAlignment (experimental, product flag), and OptoLoopAlignment (product flag) to be different kinds of flags.
> 
> Thanks @dean-long for your review and comments.
> So do we need a CSR if we make CodeCacheSegmentSize a product flag?

> @DamonFool I think the right thing to do is to use
> 
> @requires vm.debug
> 
> for now to fix the test failures, then file a new RFE to make CodeCacheSegmentSize a product flag and clean up the test.

Good idea.
I will file a RFE and fix it today.
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7830

From dlong at openjdk.java.net  Thu Mar 17 00:04:40 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Thu, 17 Mar 2022 00:04:40 GMT
Subject: RFR: 8283229: compiler/arguments/TestCodeEntryAlignment.java fails
 with release VMs [v2]
In-Reply-To: <y-61Z1yQjKrE8a08DimmLwWSjhO_iduDPnR3KozyLTI=.74d259a1-a855-4c83-975b-072addaa72fa@github.com>
References: <PZWHLnBCoRwtJrK9XYIToSf4sqdJ8gZm6286q1H-hK0=.dc5b4d10-0dfc-46ad-874b-534ac4da3dd9@github.com>
 <y-61Z1yQjKrE8a08DimmLwWSjhO_iduDPnR3KozyLTI=.74d259a1-a855-4c83-975b-072addaa72fa@github.com>
Message-ID: <gKJ0W49s-BX18vdz8ds19z_kYR1VekbwGUDBqLwi7M8=.f398cb46-c0b3-4344-a105-146fd33a2dec@github.com>

On Wed, 16 Mar 2022 23:12:29 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> compiler/arguments/TestCodeEntryAlignment.java fails with release VMs due to 'CodeCacheSegmentSize' is develop and is available only in debug version of VM.
>> The fix would only run with 'CodeCacheSegmentSize' for debug VMs.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Looks good, and trivial.  Please integrate.

-------------

Marked as reviewed by dlong (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7830

From jiefu at openjdk.java.net  Thu Mar 17 00:09:45 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 17 Mar 2022 00:09:45 GMT
Subject: Integrated: 8283229: compiler/arguments/TestCodeEntryAlignment.java
 fails with release VMs
In-Reply-To: <PZWHLnBCoRwtJrK9XYIToSf4sqdJ8gZm6286q1H-hK0=.dc5b4d10-0dfc-46ad-874b-534ac4da3dd9@github.com>
References: <PZWHLnBCoRwtJrK9XYIToSf4sqdJ8gZm6286q1H-hK0=.dc5b4d10-0dfc-46ad-874b-534ac4da3dd9@github.com>
Message-ID: <5VYPctuuKNMgUC9GX2ml4tF_5BpiOY4WfHcc9LM80V4=.c13a0786-d256-4e51-9696-eaf9c9c636b6@github.com>

On Tue, 15 Mar 2022 23:53:23 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> compiler/arguments/TestCodeEntryAlignment.java fails with release VMs due to 'CodeCacheSegmentSize' is develop and is available only in debug version of VM.
> The fix would only run with 'CodeCacheSegmentSize' for debug VMs.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: 3da5204b
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3da5204b3c3a3f95bddcdcfe2628c2e0ed8a12d9
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8283229: compiler/arguments/TestCodeEntryAlignment.java fails with release VMs

Reviewed-by: dlong

-------------

PR: https://git.openjdk.java.net/jdk/pull/7830

From njian at openjdk.java.net  Thu Mar 17 04:40:10 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Thu, 17 Mar 2022 04:40:10 GMT
Subject: RFR: 8282764: AArch64:
 compiler/vectorapi/reshape/TestVectorCastNeon.java failed with incorrect
 result
Message-ID: <5s9gVoO8BXDC9k_GYrcMupuP60CgvgvvuTwy6obPZqA=.dbbccd3f-f4f2-404f-a9f5-7b2e110cd84e@github.com>

Vector API long to float conversion operation on NEON converts vector of 2 longs to 2 floats. In current implementation, we convert 2 longs to 2 doubles first and then converts 2 doubles to 2 floats. However, this two-steps conversion may have two roundings, while the expected behavior, conversion from long to float directly, has only one rounding. This will result in inconsistent result. E.g. for the failure test case:


jshell> long l = 0x561a524000000001L;
l ==> 6204361871487664129

jshell> float l2f = (float)l;
l2f ==> 6.2043621E18

jshell> float l2d2f = (float)((double)l);
l2d2f ==> 6.2043616E18


Since we don't have NEON instruction to support vector long to float conversion, we fix the codegen by doing it in scalar operation one element by one element.

TEST: vector api jtreg tests passed.

-------------

Commit messages:
 - 8282764: AArch64: compiler/vectorapi/reshape/TestVectorCastNeon.java failed with incorrect result

Changes: https://git.openjdk.java.net/jdk/pull/7850/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7850&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282764
  Stats: 49 lines in 12 files changed: 24 ins; 0 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7850.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7850/head:pull/7850

PR: https://git.openjdk.java.net/jdk/pull/7850

From dholmes at openjdk.java.net  Thu Mar 17 06:36:48 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 17 Mar 2022 06:36:48 GMT
Subject: RFR: 8283056: show abstract machine code for all VM crashes
In-Reply-To: <kKS2Tk_nZOc6NXbUOuluZ6IGvrUrZY9IRh5tT7BSb70=.4ad088ee-ba8d-4ab6-9132-bae951036bba@github.com>
References: <kKS2Tk_nZOc6NXbUOuluZ6IGvrUrZY9IRh5tT7BSb70=.4ad088ee-ba8d-4ab6-9132-bae951036bba@github.com>
Message-ID: <7gcGGa7xxIW3W6ncNPZ4rCb_EO9n_QxvITCnBxyvTJE=.ad5b5614-d8dd-4539-bd14-edd78eb209fa@github.com>

On Fri, 11 Mar 2022 20:48:06 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> [JDK-8272586](https://bugs.openjdk.java.net/browse/JDK-8272586) added abstract assembly to hs-err for methods on the stack of the crashing thread. However, it only does this if the crash is due to an unhandled signal. It can also be useful to see assembly for crashes due to failing VM assertions or guarantees. This PR implements this improvement.

Hi Doug,

I'm approving in principle but would like to see the code tweaked as per the comment below.

Thanks,
David

src/hotspot/share/utilities/vmError.cpp line 915:

> 913:      if (_verbose) {
> 914:        frame fr = _context ? os::fetch_frame_from_context(_context)
> 915:                            : os::current_frame();

This seems like it is only need in the else branch at L931, so I'd prefer to see it there please.

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7791

From jiefu at openjdk.java.net  Thu Mar 17 08:57:37 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 17 Mar 2022 08:57:37 GMT
Subject: RFR: 8283229: compiler/arguments/TestCodeEntryAlignment.java fails
 with release VMs
In-Reply-To: <J1pYILJ5xUP6AuFvea_TW53XWoC_YADglEpTSXNuVU0=.72af7da2-2507-4f81-a73b-279144dfed7d@github.com>
References: <PZWHLnBCoRwtJrK9XYIToSf4sqdJ8gZm6286q1H-hK0=.dc5b4d10-0dfc-46ad-874b-534ac4da3dd9@github.com>
 <WRgs5ZlFURJqTyGId1umt8n369sWYKnWaG9q05CId1o=.7c61acbb-6026-41a9-afbb-787287b79d49@github.com>
 <ZFLQL0vvYZihT2vpsNVWSwDzHe1oFbf9pnK6S0S_jQk=.d310e3f8-e53a-4426-9c43-c333a318fe02@github.com>
 <J1pYILJ5xUP6AuFvea_TW53XWoC_YADglEpTSXNuVU0=.72af7da2-2507-4f81-a73b-279144dfed7d@github.com>
Message-ID: <IN_h5wir07yAtauoiLTPd5O65Uc1I41lB8xoiA51o5A=.40a3af2e-e868-46e8-b00b-94f8a97a13e0@github.com>

On Wed, 16 Mar 2022 23:08:54 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> file a new RFE to make CodeCacheSegmentSize a product flag and clean up the test.

Hi @dean-long , please see https://github.com/openjdk/jdk/pull/7851
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7830

From aph at openjdk.java.net  Thu Mar 17 09:02:35 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 17 Mar 2022 09:02:35 GMT
Subject: RFR: 8262901: [macos_aarch64] NativeCallTest
 expected:<-3.8194101E18> but was:<3.02668882E10> [v2]
In-Reply-To: <NsThxZXeM6VxaES2bjnJlgdixb8qFLqkTUhJMUradPU=.71c82b76-885a-4025-8f6e-9deab9dc4b28@github.com>
References: <EKai9u5Kli5AfxN5AukPhdxVqAZAABnnJfmTwDRnj_A=.940a8b14-8822-4911-b3e0-8ba7ddcc2f35@github.com>
 <NsThxZXeM6VxaES2bjnJlgdixb8qFLqkTUhJMUradPU=.71c82b76-885a-4025-8f6e-9deab9dc4b28@github.com>
Message-ID: <mrZ2V7zD-GJWl4Ayco45c6lR6hF58MI-7kRdsd7oukg=.d10041f0-0abb-45a8-a1aa-2b21aeab7c91@github.com>

On Thu, 2 Dec 2021 07:00:52 GMT, Danil Bubnov <duke at openjdk.java.net> wrote:

>> This is the fix of aarch64 jvmci calling convention.
>> 
>> On MacOS/aarch64 "Function arguments may consume slots on the stack that are not multiples of 8 bytes" [1], but current approach uses only wordsize or bigger slots, which is incorrect (that is why tests were failing [4]). Now arguments consume the right amount of bytes.
>> 
>> Another problem is that current approach don't make 16-byte alignment of Stack Pointer [1][2][3]. However, tests not fail on Linux/aarch64 and Windows/aarch64. They pass because in this tests all functions have even number of argumets, that is why 16-byte alignment comes automatically. But if you try to add or delete one argumets, tests will fail with SIGBUS.
>> 
>> I've tested this patch on MacOS/aarch64 and Linux/aarch64, all tests have passed.
>> 
>> Also I don't understand, why current tests (NativeCallTest) use only int, long, float and double as arguments types. Is it possible to add functions with another types like byte or short? I tried, but it fails on every platform.
>> 
>> [1] https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms
>> [2] https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#the-stack
>> [3] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack
>> [4] https://bugs.openjdk.java.net/browse/JDK-8262901
>
> Danil Bubnov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test with an odd number of arguments

Marked as reviewed by aph (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/6641

From duke at openjdk.java.net  Thu Mar 17 10:08:14 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Thu, 17 Mar 2022 10:08:14 GMT
Subject: RFR: 8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0)
 failed: Don't process dead nodes [v6]
In-Reply-To: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
References: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
Message-ID: <Q7n-a7kpxj_onU3YF9f1wTwDQAoXU-7KEA3W49W11_U=.3fbac3b8-3f04-49a7-8ef0-52cf22ca5792@github.com>

> Problem:
> Sometimes nodes are generated, and then not properly added to any other node, nor added to the worklist, so that it could be deleted. In some cases, a node can thus survive after IGVN and enter into `ConnectionGraph::compute_escape`, where no dead nodes are expected (except constants).
> 
> In `ArrayCopyNode::prepare_array_copy`:
> In one, I now add the new ConvI2LNode to the worklist if we are aborting.
> In the other case, I could safely reorder the code, such new ConvI2LNode would only be generated once we know we are not going to abort.
> 
> In `SubTypeCheckNode::Ideal`:
> Replaced `set_req` with `set_req_X`, such that the input-node that is replaced (which is now potentially a dead node) is put on the worklist.
> 
> In `ArrayCopyNode::Ideal`:
> If we decide to `return NULL` we also need to add the potentially dead forward / backward memory nodes to the worklist, they may turn out to be dead.
> 
> Added a regression test: the test + flag combination that first reproduced this issue.
> 
> All Tests, including this new regression test are passing. Also passing with newest commit (response to review).

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  use can_reshape, is equivalent

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7728/files
  - new: https://git.openjdk.java.net/jdk/pull/7728/files/5f68319d..a5c95e7d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7728&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7728&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7728.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7728/head:pull/7728

PR: https://git.openjdk.java.net/jdk/pull/7728

From thartmann at openjdk.java.net  Thu Mar 17 10:17:33 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 17 Mar 2022 10:17:33 GMT
Subject: RFR: 8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0)
 failed: Don't process dead nodes [v6]
In-Reply-To: <Q7n-a7kpxj_onU3YF9f1wTwDQAoXU-7KEA3W49W11_U=.3fbac3b8-3f04-49a7-8ef0-52cf22ca5792@github.com>
References: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
 <Q7n-a7kpxj_onU3YF9f1wTwDQAoXU-7KEA3W49W11_U=.3fbac3b8-3f04-49a7-8ef0-52cf22ca5792@github.com>
Message-ID: <vkl4k7zcvA90qdBnHhmLiPC6Fkz4OJPL-MD26gyDac0=.59608b25-1c21-46bf-b0e9-62a6b3340ac6@github.com>

On Thu, 17 Mar 2022 10:08:14 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> Problem:
>> Sometimes nodes are generated, and then not properly added to any other node, nor added to the worklist, so that it could be deleted. In some cases, a node can thus survive after IGVN and enter into `ConnectionGraph::compute_escape`, where no dead nodes are expected (except constants).
>> 
>> In `ArrayCopyNode::prepare_array_copy`:
>> In one, I now add the new ConvI2LNode to the worklist if we are aborting.
>> In the other case, I could safely reorder the code, such new ConvI2LNode would only be generated once we know we are not going to abort.
>> 
>> In `SubTypeCheckNode::Ideal`:
>> Replaced `set_req` with `set_req_X`, such that the input-node that is replaced (which is now potentially a dead node) is put on the worklist.
>> 
>> In `ArrayCopyNode::Ideal`:
>> If we decide to `return NULL` we also need to add the potentially dead forward / backward memory nodes to the worklist, they may turn out to be dead.
>> 
>> Added a regression test: the test + flag combination that first reproduced this issue.
>> 
>> All Tests, including this new regression test are passing. Also passing with newest commit (response to review).
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use can_reshape, is equivalent

src/hotspot/share/opto/arraycopynode.cpp line 306:

> 304:       PhaseIterGVN* igvn = phase->is_IterGVN();
> 305:       if (can_reshape) {
> 306:         if (!src_offset->is_top()) {

The ifs can be merged.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7728

From thartmann at openjdk.java.net  Thu Mar 17 10:17:33 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 17 Mar 2022 10:17:33 GMT
Subject: RFR: 8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0)
 failed: Don't process dead nodes [v6]
In-Reply-To: <vkl4k7zcvA90qdBnHhmLiPC6Fkz4OJPL-MD26gyDac0=.59608b25-1c21-46bf-b0e9-62a6b3340ac6@github.com>
References: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
 <Q7n-a7kpxj_onU3YF9f1wTwDQAoXU-7KEA3W49W11_U=.3fbac3b8-3f04-49a7-8ef0-52cf22ca5792@github.com>
 <vkl4k7zcvA90qdBnHhmLiPC6Fkz4OJPL-MD26gyDac0=.59608b25-1c21-46bf-b0e9-62a6b3340ac6@github.com>
Message-ID: <omJPcXyu2TKP6CTggYLGWePkFIKtsfYKWIJnNULfxIY=.7b17d1f8-03ae-4feb-9cb9-7dcb6aa85f82@github.com>

On Thu, 17 Mar 2022 10:13:34 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use can_reshape, is equivalent
>
> src/hotspot/share/opto/arraycopynode.cpp line 306:
> 
>> 304:       PhaseIterGVN* igvn = phase->is_IterGVN();
>> 305:       if (can_reshape) {
>> 306:         if (!src_offset->is_top()) {
> 
> The ifs can be merged.

And looking at this again, `src_offset` can't be top, right? We just checked it above.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7728

From duke at openjdk.java.net  Thu Mar 17 10:28:19 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Thu, 17 Mar 2022 10:28:19 GMT
Subject: RFR: 8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0)
 failed: Don't process dead nodes [v7]
In-Reply-To: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
References: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
Message-ID: <qpTVvZwBjh0d29uljnYQjcmDIg36iLCrDeeL3I0anCc=.c52b835e-8146-42dd-b915-8c11bc5a770e@github.com>

> Problem:
> Sometimes nodes are generated, and then not properly added to any other node, nor added to the worklist, so that it could be deleted. In some cases, a node can thus survive after IGVN and enter into `ConnectionGraph::compute_escape`, where no dead nodes are expected (except constants).
> 
> In `ArrayCopyNode::prepare_array_copy`:
> In one, I now add the new ConvI2LNode to the worklist if we are aborting.
> In the other case, I could safely reorder the code, such new ConvI2LNode would only be generated once we know we are not going to abort.
> 
> In `SubTypeCheckNode::Ideal`:
> Replaced `set_req` with `set_req_X`, such that the input-node that is replaced (which is now potentially a dead node) is put on the worklist.
> 
> In `ArrayCopyNode::Ideal`:
> If we decide to `return NULL` we also need to add the potentially dead forward / backward memory nodes to the worklist, they may turn out to be dead.
> 
> Added a regression test: the test + flag combination that first reproduced this issue.
> 
> All Tests, including this new regression test are passing. Also passing with newest commit (response to review).

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  small refactoring

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7728/files
  - new: https://git.openjdk.java.net/jdk/pull/7728/files/a5c95e7d..11b82c1e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7728&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7728&range=05-06

  Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7728.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7728/head:pull/7728

PR: https://git.openjdk.java.net/jdk/pull/7728

From dnsimon at openjdk.java.net  Thu Mar 17 10:30:19 2022
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Thu, 17 Mar 2022 10:30:19 GMT
Subject: RFR: 8283056: show abstract machine code for all VM crashes [v2]
In-Reply-To: <kKS2Tk_nZOc6NXbUOuluZ6IGvrUrZY9IRh5tT7BSb70=.4ad088ee-ba8d-4ab6-9132-bae951036bba@github.com>
References: <kKS2Tk_nZOc6NXbUOuluZ6IGvrUrZY9IRh5tT7BSb70=.4ad088ee-ba8d-4ab6-9132-bae951036bba@github.com>
Message-ID: <N3BOfmfSAw-9a5xudx8k97xz0RmxrOzGvoS11ymop_Q=.5f82f08f-064c-482c-9aa8-db3922eade27@github.com>

> [JDK-8272586](https://bugs.openjdk.java.net/browse/JDK-8272586) added abstract assembly to hs-err for methods on the stack of the crashing thread. However, it only does this if the crash is due to an unhandled signal. It can also be useful to see assembly for crashes due to failing VM assertions or guarantees. This PR implements this improvement.

Doug Simon has updated the pull request incrementally with one additional commit since the last revision:

  moved fr declaration to block where it is used

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7791/files
  - new: https://git.openjdk.java.net/jdk/pull/7791/files/3ef8637d..a1adb8aa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7791&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7791&range=00-01

  Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7791.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7791/head:pull/7791

PR: https://git.openjdk.java.net/jdk/pull/7791

From dnsimon at openjdk.java.net  Thu Mar 17 10:33:33 2022
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Thu, 17 Mar 2022 10:33:33 GMT
Subject: RFR: 8283056: show abstract machine code in hs-err for all VM
 crashes [v2]
In-Reply-To: <7gcGGa7xxIW3W6ncNPZ4rCb_EO9n_QxvITCnBxyvTJE=.ad5b5614-d8dd-4539-bd14-edd78eb209fa@github.com>
References: <kKS2Tk_nZOc6NXbUOuluZ6IGvrUrZY9IRh5tT7BSb70=.4ad088ee-ba8d-4ab6-9132-bae951036bba@github.com>
 <7gcGGa7xxIW3W6ncNPZ4rCb_EO9n_QxvITCnBxyvTJE=.ad5b5614-d8dd-4539-bd14-edd78eb209fa@github.com>
Message-ID: <lMWc6RyZV_5sTHAhddOQNXZYvVq9868bAQ4RrePXe18=.9bcd4255-fc84-47fb-8f28-9bf1042dd1ab@github.com>

On Thu, 17 Mar 2022 06:33:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   moved fr declaration to block where it is used
>
> Hi Doug,
> 
> I'm approving in principle but would like to see the code tweaked as per the comment below.
> 
> Thanks,
> David

Thanks @dholmes-ora , I've made the suggested change: a1adb8aae99312b2a2b86fa4a6c57a8493484e4b

-------------

PR: https://git.openjdk.java.net/jdk/pull/7791

From duke at openjdk.java.net  Thu Mar 17 10:55:09 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Thu, 17 Mar 2022 10:55:09 GMT
Subject: RFR: 8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0)
 failed: Don't process dead nodes [v8]
In-Reply-To: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
References: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
Message-ID: <Ac1Nb0W7yD645LlFOZT66w4oV9v8uxpJgZoDQQKVnwk=.f606f437-3e8b-41bd-9361-5d743a8750bb@github.com>

> Problem:
> Sometimes nodes are generated, and then not properly added to any other node, nor added to the worklist, so that it could be deleted. In some cases, a node can thus survive after IGVN and enter into `ConnectionGraph::compute_escape`, where no dead nodes are expected (except constants).
> 
> In `ArrayCopyNode::prepare_array_copy`:
> In one, I now add the new ConvI2LNode to the worklist if we are aborting.
> In the other case, I could safely reorder the code, such new ConvI2LNode would only be generated once we know we are not going to abort.
> 
> In `SubTypeCheckNode::Ideal`:
> Replaced `set_req` with `set_req_X`, such that the input-node that is replaced (which is now potentially a dead node) is put on the worklist.
> 
> In `ArrayCopyNode::Ideal`:
> If we decide to `return NULL` we also need to add the potentially dead forward / backward memory nodes to the worklist, they may turn out to be dead.
> 
> Added a regression test: the test + flag combination that first reproduced this issue.
> 
> All Tests, including this new regression test are passing. [Rerunning tests after a small refactoring]

Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:

  remove condition that is always true

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7728/files
  - new: https://git.openjdk.java.net/jdk/pull/7728/files/11b82c1e..584326e0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7728&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7728&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7728.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7728/head:pull/7728

PR: https://git.openjdk.java.net/jdk/pull/7728

From thartmann at openjdk.java.net  Thu Mar 17 11:50:32 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 17 Mar 2022 11:50:32 GMT
Subject: RFR: 8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0)
 failed: Don't process dead nodes [v8]
In-Reply-To: <Ac1Nb0W7yD645LlFOZT66w4oV9v8uxpJgZoDQQKVnwk=.f606f437-3e8b-41bd-9361-5d743a8750bb@github.com>
References: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
 <Ac1Nb0W7yD645LlFOZT66w4oV9v8uxpJgZoDQQKVnwk=.f606f437-3e8b-41bd-9361-5d743a8750bb@github.com>
Message-ID: <q-0LLkmJpuwa-5mDXsWRC1uAokfzZnNhhn4jNI_WSgQ=.7c3079cb-dfbd-4711-bd4b-f8288a9eb2f3@github.com>

On Thu, 17 Mar 2022 10:55:09 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> Problem:
>> Sometimes nodes are generated, and then not properly added to any other node, nor added to the worklist, so that it could be deleted. In some cases, a node can thus survive after IGVN and enter into `ConnectionGraph::compute_escape`, where no dead nodes are expected (except constants).
>> 
>> In `ArrayCopyNode::prepare_array_copy`:
>> In one, I now add the new ConvI2LNode to the worklist if we are aborting.
>> In the other case, I could safely reorder the code, such new ConvI2LNode would only be generated once we know we are not going to abort.
>> 
>> In `SubTypeCheckNode::Ideal`:
>> Replaced `set_req` with `set_req_X`, such that the input-node that is replaced (which is now potentially a dead node) is put on the worklist.
>> 
>> In `ArrayCopyNode::Ideal`:
>> If we decide to `return NULL` we also need to add the potentially dead forward / backward memory nodes to the worklist, they may turn out to be dead.
>> 
>> Added a regression test: the test + flag combination that first reproduced this issue.
>> 
>> All Tests, including this new regression test are passing. [Rerunning tests after a small refactoring]
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove condition that is always true

Looks good, thanks for making these changes.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7728

From duke at openjdk.java.net  Thu Mar 17 12:05:18 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 17 Mar 2022 12:05:18 GMT
Subject: RFR: 8283232: x86: Improve vector broadcast operations [v3]
In-Reply-To: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
References: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
Message-ID: <_BenQBPyAIy6sOba4OwJLA-XusVv9-QWa6uH867eNRs=.75b35402-e739-4133-a091-18755a5ed8c4@github.com>

> Hi,
> 
> This patch improves the generation of broadcasting a scalar in several ways:
> 
> - Avoid potential data bypass delay which can be observed on some platforms by using the correct type of instruction if it does not require extra instructions.
> - As it has been pointed out, dumping the whole vector into the constant table is costly in terms of code size, this patch minimises this overhead for vector replicate of constants. Also, options are available for constants to be generated with more alignment so that vector load can be made efficiently without crossing cache lines.
> - Vector broadcasting should prefer rematerialising to spilling when register pressure is high.
> 
> This patch also removes some redundant code paths and rename some incorrectly named instructions.
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  fix rematerialize, constant deduplication

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7832/files
  - new: https://git.openjdk.java.net/jdk/pull/7832/files/8216d790..3bc7731a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7832&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7832&range=01-02

  Stats: 27 lines in 3 files changed: 23 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7832.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7832/head:pull/7832

PR: https://git.openjdk.java.net/jdk/pull/7832

From duke at openjdk.java.net  Thu Mar 17 12:51:32 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 17 Mar 2022 12:51:32 GMT
Subject: RFR: 8283232: x86: Improve vector broadcast operations [v3]
In-Reply-To: <_BenQBPyAIy6sOba4OwJLA-XusVv9-QWa6uH867eNRs=.75b35402-e739-4133-a091-18755a5ed8c4@github.com>
References: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
 <_BenQBPyAIy6sOba4OwJLA-XusVv9-QWa6uH867eNRs=.75b35402-e739-4133-a091-18755a5ed8c4@github.com>
Message-ID: <kUY_pkqjjlS19tqy80m9v7xWtNtHdIrmeQSlmhIyiI8=.a3baec0a-9864-4cf8-a0dd-caf12c4e52f9@github.com>

On Thu, 17 Mar 2022 12:05:18 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch improves the generation of broadcasting a scalar in several ways:
>> 
>> - Avoid potential data bypass delay which can be observed on some platforms by using the correct type of instruction if it does not require extra instructions.
>> - As it has been pointed out, dumping the whole vector into the constant table is costly in terms of code size, this patch minimises this overhead for vector replicate of constants. Also, options are available for constants to be generated with more alignment so that vector load can be made efficiently without crossing cache lines.
>> - Vector broadcasting should prefer rematerialising to spilling when register pressure is high.
>> 
>> This patch also removes some redundant code paths and rename some incorrectly named instructions.
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix rematerialize, constant deduplication

Doing a simple benchmark that has a lot of register pressure

    @Benchmark
    public long broadcastCon() {
        var species = IntVector.SPECIES_PREFERRED;
        var sum = IntVector.zero(species);
        return sum.add(1).add(2).add(3).add(4).add(5).add(6).add(7).add(8)
                .add(9).add(10).add(11).add(12).add(13).add(14).add(15).add(16)
                .add(17).add(18).add(19).add(20).add(21).add(22).add(23).add(24)
                .add(25).add(26).add(27).add(28).add(29).add(30).add(31).add(32)
                .add(1).add(2).add(3).add(4).add(5).add(6).add(7).add(8)
                .add(9).add(10).add(11).add(12).add(13).add(14).add(15).add(16)
                .add(17).add(18).add(19).add(20).add(21).add(22).add(23).add(24)
                .add(25).add(26).add(27).add(28).add(29).add(30).add(31).add(32)
                .reinterpretAsLongs()
                .lane(0);
    }

provides the following result:

    Before:
    Benchmark                     Mode  Cnt   Score   Error  Units
    VectorReplicate.broadcastCon  avgt    5  16.417 ? 0.515  ns/op

    After:
    Benchmark                     Mode  Cnt   Score   Error  Units
    VectorReplicate.broadcastCon  avgt    5  13.851 ? 0.154  ns/op

The constant table size decreases from 1024 bytes to 128 bytes, which is much more manageable. The throughput improvement mostly comes from the vector being rematerialized instead of being spilt on the stack.

I have not been able to observe performance gain regarding bypass delay, which is expected as according to "Agner's optimisation manual on the micro architecture of Intel, AMD and VIA CPUs", Intel CPUs since Skylake seem to have only a few such delays.

Thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7832

From dnsimon at openjdk.java.net  Thu Mar 17 12:54:32 2022
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Thu, 17 Mar 2022 12:54:32 GMT
Subject: Integrated: 8283056: show abstract machine code in hs-err for all VM
 crashes
In-Reply-To: <kKS2Tk_nZOc6NXbUOuluZ6IGvrUrZY9IRh5tT7BSb70=.4ad088ee-ba8d-4ab6-9132-bae951036bba@github.com>
References: <kKS2Tk_nZOc6NXbUOuluZ6IGvrUrZY9IRh5tT7BSb70=.4ad088ee-ba8d-4ab6-9132-bae951036bba@github.com>
Message-ID: <oBoPgERfRAhto_4-AIszbrZ1zpA1TW1n_rQEjGeGlB0=.e0f7c739-67d4-461b-a5b9-e40d0206409b@github.com>

On Fri, 11 Mar 2022 20:48:06 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> [JDK-8272586](https://bugs.openjdk.java.net/browse/JDK-8272586) added abstract assembly to hs-err for methods on the stack of the crashing thread. However, it only does this if the crash is due to an unhandled signal. It can also be useful to see assembly for crashes due to failing VM assertions or guarantees. This PR implements this improvement.

This pull request has now been integrated.

Changeset: 69e4e338
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/69e4e338b19c0ffd2f0881be1bbb19a5642bc4d4
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8283056: show abstract machine code in hs-err for all VM crashes

Reviewed-by: thartmann, dholmes

-------------

PR: https://git.openjdk.java.net/jdk/pull/7791

From chagedorn at openjdk.java.net  Thu Mar 17 12:55:43 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 17 Mar 2022 12:55:43 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view
In-Reply-To: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
Message-ID: <2biNIQgrADSLZbAdbSDGvSpAnO8NdJLHRsRWHAhNYpw=.491f9738-9678-4412-b615-1b741b4364ed@github.com>

On Tue, 15 Mar 2022 11:36:21 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change adds a new view to the Ideal Graph Visualizer showing a classic control-flow graph (CFG) where nodes are serialized within basic blocks and arcs across basic blocks represent control flow:
> 
> ![cfg](https://user-images.githubusercontent.com/8792647/158367227-1ccfb9e0-bba1-4a80-963e-3e8c5f23c1c4.png)
> 
> The CFG provides a higher-level, more compact view of the graph than the existing views, where it can be hard to see the overall structure for all but the smallest graphs:
> 
> ![sea-vs-cfg](https://user-images.githubusercontent.com/8792647/158366842-f32b1b22-f7ed-4404-bb43-9d5c58a98ec4.png)
> 
> ![clusters-vs-cfg](https://user-images.githubusercontent.com/8792647/158366861-64561cfa-2553-4c9e-ad59-25acce6b4961.png)
> 
> If a schedule is available in the input graph (because it corresponds to the _Global code motion_ phase or later), the CFG, including the serialization of nodes within basic blocks, is derived from it. Otherwise, the CFG is approximated by the C2-specific `ServerCompilerScheduler` class. Dependencies among nodes are shown textually, by extending the label of each node with a list of its inputs:
> 
> <p align="center">
>     <img width="35%" src="https://user-images.githubusercontent.com/8792647/158367428-5aa222e9-6a5c-4e78-871f-853e5b918599.png">
> </p>
> 
> The exact information shown about each input can be configured in Tools -> Options -> Tiny Node Text.
> 
> The new CFG view is available at the same level as the existing "sea of nodes" (default) and "clustered sea-of-nodes" views. The view can be selected from the main toolbar:
> 
> ![toolbar](https://user-images.githubusercontent.com/8792647/158367502-ac8d8a29-5f35-4604-acc3-9d563c60e917.png)
> 
> The default view shown when opening a new graph can be configured in Tools -> Options -> Default View.
> 
> The same functionality available for the existing views also applies to the new CFG:
> 
> - node extraction:
> 
> ![node-extraction](https://user-images.githubusercontent.com/8792647/158371016-f7988eb6-368f-4805-ac7a-2b5611d16d7a.png)
> 
> - pop-up information on edges:
> 
> ![popup](https://user-images.githubusercontent.com/8792647/158367664-495189d5-384c-4b86-a62b-08863420c531.png)
> 
> - filtering:
> 
> ![filtering](https://user-images.githubusercontent.com/8792647/158367690-47b95bcd-7e8e-466e-b71b-f3e7d04c60ac.png)
> 
> - quick node and basic block search:
> 
> ![quick-search](https://user-images.githubusercontent.com/8792647/158367717-8bc90027-8ce7-4071-be04-1d67de6c91dd.png)
> 
> - and exporting.
> 
> The list of custom filters is extended with three new block-hiding filters:
> 
> - `Hide root block`: remove root block and hide all back-edges from exiting blocks that clutter the CFG.
> 
> - `Hide uncommon trap blocks`: remove blocks with uncommon traps to simplify following the "hot paths" in the CFG.
> 
> - `Hide exception blocks`: remove blocks that create and throw exceptions to also simplify following the "hot paths" in the CFG.
> 
> When using the CFG view, it is important to keep in mind that, in graphs corresponding to phases earlier than _Global code motion_, the presented CFG is just one of many possible projections of the sea-of-nodes representation, and that this projection is computed by an approximation of what C2 would do if it scheduled the graph at that stage. The approximation has some known limitations ([JDK-8280568](https://bugs.openjdk.java.net/browse/JDK-8280568), [JDK-8282053](https://bugs.openjdk.java.net/browse/JDK-8282053)). Future work should address these and warn the user when the approximated CFG is known to be inaccurate.
> 
> ### Testing
> 
> #### Functionality
> 
> - Tested the above functionality manually on a small selection of graphs.
> 
> - Tested automatically that scheduling (approximating C2's GCM and LCM algorithms) and viewing thousands of graphs in the three views does not trigger any assertion failure (by instrumenting IGV to schedule and view graphs as they are loaded and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).
> 
> #### Performance
> 
> - Measured the scheduling and view creation time for each of the three views on a selection of 22 large graphs (between 2515 and 7329 nodes). On average:
> 
> - The change introduces a slight overhead when creating the existing views (2% and 5% for the clustered and non-clustered sea-of-nodes views). This overhead is due to the introduction of abstractions and data structures required by the CFG view.
> 
> - The new CFG view is considerably faster to create than the existing ones (4.2x and 2.5x faster than the clustered and non-clustered sea-of-nodes views), as it can be expected, since only basic blocks have to be laid out. Furthermore, the CFG view scales better as the size of the graph increases.
> 
> - The change slows down scheduling by 27%. This overhead corresponds to the additional work of approximating C2's LCM, and it is essential for the CFG view. Fortunately, scheduling takes only a fraction of the time needed to create a view (typically no more than a third), and it only needs to run once for each graph, whereas views have to be re-created on node extraction, filtering, etc.
> 
> The performance results are [attached](https://github.com/openjdk/jdk/files/8252786/performance-evaluation.ods) (note that each measurement in the sheet corresponds to the median of ten runs).

Great work Roberto! This looks very nice. I've tried it out and it worked well. The only thing I've noticed in the compact CFG view: When extracting a node, it shows all the empty blocks of the entire graph. I would have expected that empty blocks that are neither in- nor outputs of the extracted node are hidden. But I think that could also be potentially handled in a separate RFE and should not block this change.

My review comments are mostly just about code styling and the like since I'm not very familiar with the IGV code which made it hard to review - I trust your expertise in that area :-)

Thanks,
Christian

src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/InputGraph.java line 66:

> 64:     public InputBlockEdge addBlockEdge(InputBlock left, InputBlock right, String label) {
> 65:         InputBlockEdge edge = new InputBlockEdge(left, right);
> 66:         edge.setLabel(label);

As you only use `setLabel()` here, you could also directly pass it into the `InputBlockEdge()` constructor.

src/utils/IdealGraphVisualizer/Data/src/main/java/com/sun/hotspot/igv/data/InputGraph.java line 177:

> 175:             if (!scheduledNodes.contains(n)) {
> 176:                 if (noBlock == null) {
> 177:                     noBlock = this.addArtificialBlock();

`this` can be removed.

src/utils/IdealGraphVisualizer/Filter/src/main/java/com/sun/hotspot/igv/filter/RemoveBlockFilter.java line 37:

> 35: 
> 36:     private List<RemoveBlockRule> rules;
> 37:     private String name;

Both can be made `final`.

src/utils/IdealGraphVisualizer/Filter/src/main/java/com/sun/hotspot/igv/filter/RemoveBlockFilter.java line 64:

> 62:     public static class RemoveBlockRule {
> 63: 
> 64:         private BlockSelector selector;

Can also be made `final`.

src/utils/IdealGraphVisualizer/Graal/src/main/java/com/sun/hotspot/igv/graal/filters/GraalEdgeColorFilter.java line 63:

> 61:                     String type = null;
> 62: 
> 63:                     if (type != null) {

This block is dead since `type` is `null`. Is this intended?

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/AnySelector.java line 32:

> 30: public class AnySelector implements BlockSelector {
> 31: 
> 32:     private Selector selector;

Can be made `final`.

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/BlockConnection.java line 39:

> 37: 
> 38:     private Block sourceBlock;
> 39:     private Block destinationBlock;

Can be made `final`.

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/BlockConnection.java line 71:

> 69:     public String getLabel() {
> 70:         return label;
> 71:     }

Appears to be unused and can be removed.

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/BlockConnection.java line 77:

> 75:         StringBuilder builder = new StringBuilder();
> 76:         builder.append("B" + sourceBlock.getInputBlock().getName() + " ? " +
> 77:                        "B" + destinationBlock.getInputBlock().getName());

Could be replaced by `append()` calls:
Suggestion:

        builder.append("B").append(sourceBlock.getInputBlock().getName())
               .append(" ? B").append(destinationBlock.getInputBlock().getName());

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Connection.java line 38:

> 36:     }
> 37: 
> 38:     public ConnectionStyle getStyle();

`public` is implied for interface methods and does not need to be stated explicitly.

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Diagram.java line 55:

> 53:     // Whether widgets derived from this diagram should be adapted for the
> 54:     // control-flow graph view.
> 55:     private boolean cfg = false;

This assignment can be removed as you initialize it in the constructor.

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Diagram.java line 56:

> 54:     // control-flow graph view.
> 55:     private boolean cfg = false;
> 56:     private Set<BlockConnection> blockConnections;

Can be made `final`.

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Diagram.java line 119:

> 117:     }
> 118: 
> 119:     public Diagram getNext() {

Appears to be unused?

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Diagram.java line 127:

> 125:     }
> 126: 
> 127:     public Diagram getPrev() {

Appears to be unused?

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Diagram.java line 175:

> 173:         d.nodeText = nodeText;
> 174:         d.shortNodeText = shortNodeText;
> 175:         d.tinyNodeText = tinyNodeText;

Could be passed as arguments to the constructor.

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Diagram.java line 226:

> 224:             BlockConnection c = new BlockConnection(p, s, e.getLabel());
> 225:             c.setStyle(Connection.ConnectionStyle.BOLD);
> 226:             c.setColor(Color.BLUE);

These settings are only set here and could thus also be moved directly into the `BlockConnection()` constructor.

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Diagram.java line 296:

> 294: 
> 295:     public Set<FigureConnection> getConnections() {
> 296: 

New line can be removed

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Diagram.java line 299:

> 297:         Set<FigureConnection> connections = new HashSet<>();
> 298:         for (Figure f : figures) {
> 299: 

New line can be removed

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Figure.java line 74:

> 72:         Graphics g = image.getGraphics();
> 73:         g.setFont(diagram.getFont().deriveFont(Font.BOLD));
> 74:         FontMetrics metrics = g.getFontMetrics();

Do you really need to create a fake image just to get the font metrics?

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/FigureConnection.java line 2:

> 1: /*
> 2:  * Copyright (c) 2008, 2022, Oracle and/or its affiliates. All rights reserved.

Should only be 2022 for a new file.

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/FigureConnection.java line 35:

> 33: /**
> 34:  *
> 35:  * @author Thomas Wuerthinger

You should take credit of this class instead ;-)

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/FigureConnection.java line 42:

> 40:     public boolean isVIP() {
> 41:         return style == ConnectionStyle.BOLD;
> 42:     }

Should be moved down to the other methods.

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/FigureConnection.java line 44:

> 42:     }
> 43:     private InputSlot inputSlot;
> 44:     private OutputSlot outputSlot;

Can be made `final`.

src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/HierarchicalCFGLayoutManager.java line 43:

> 41:     private FontMetrics fontMetrics;
> 42:     private LayoutManager subManager;
> 43:     private LayoutManager manager;

You might want to add a comment what each of these managers do or why you need a sub manager as well.

src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/HierarchicalCFGLayoutManager.java line 85:

> 83:             cn.setBorder(BLOCK_BORDER);
> 84:             cn.setHeaderVerticalSpace(fontMetrics.getHeight());
> 85:             cn.setNodeOffset(c.getNodeOffset());

Could be combined to a second constructor in `ClusterNode` instead of using separate `set()` methods.

src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/HierarchicalCFGLayoutManager.java line 86:

> 84:             cn.setHeaderVerticalSpace(fontMetrics.getHeight());
> 85:             cn.setNodeOffset(c.getNodeOffset());
> 86:             String blockLabel = "B" + c.toString();

`toString()` is implicit and can be removed.

src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/HierarchicalCFGLayoutManager.java line 139:

> 137:             Link l = inputLink.get(new AbstractMap.SimpleEntry<Cluster, Cluster>(ce.getFromCluster(), ce.getToCluster()));
> 138:             l.setControlPoints(ce.getControlPoints());
> 139:         }

Refactor suggestion:
All the code blocks with a comment could be extracted to separate methods with method names matching the comments accordingly.

src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/HierarchicalCFGLayoutManager.java line 143:

> 141: 
> 142:     public void doRouting(LayoutGraph graph) {
> 143:     }

All the `doRouting()` methods do nothing. These could be removed together with the interface declaration.

src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/HierarchicalLayoutManager.java line 228:

> 226:         new BuildDatastructure().start();
> 227: 
> 228:         if (!layoutSelfEdges) {

This block could be extracted to a separate method.

src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/HierarchicalLayoutManager.java line 260:

> 258: 
> 259:         // Hide self-edges from the core layout algorithm.
> 260:         for (LayoutNode node : nodes) {

This block could also be extracted to a separate method.

src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/LinearLayoutManager.java line 36:

> 34: 
> 35:     // Ranking determining the vertical node ordering.
> 36:     private Map<? extends Vertex, Integer> vertexRank;

Can be made `final`.

src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/LinearLayoutManager.java line 56:

> 54:         vertices.sort((Vertex a, Vertex b) ->
> 55:                       Integer.compare(vertexRank.getOrDefault(a, Integer.MAX_VALUE),
> 56:                                       vertexRank.getOrDefault(b, Integer.MAX_VALUE)));

Could be simplified to:
Suggestion:

        vertices.sort(Comparator.comparingInt((Vertex a) -> vertexRank.getOrDefault(a, Integer.MAX_VALUE)));

src/utils/IdealGraphVisualizer/HierarchicalLayout/src/main/java/com/sun/hotspot/igv/hierarchicallayout/LinearLayoutManager.java line 63:

> 61:             v.setPosition(new Point(0, curY));
> 62:             curY += v.getSize().getHeight();
> 63:         }

Could be extracted to a separate `assignVerticalCoordinates()` method.

src/utils/IdealGraphVisualizer/Layout/src/main/java/com/sun/hotspot/igv/layout/LayoutGraph.java line 55:

> 53:         for (Link l : links) {
> 54:             if (l.getFrom() == null || l.getTo() == null)
> 55:                 continue;

Missing braces

src/utils/IdealGraphVisualizer/Layout/src/main/java/com/sun/hotspot/igv/layout/Link.java line 37:

> 35:     public Port getFrom();
> 36: 
> 37:     public Cluster getFromCluster();

`public` can be removed for interface methods.

src/utils/IdealGraphVisualizer/ServerCompiler/src/main/java/com/sun/hotspot/igv/servercompiler/ServerCompilerScheduler.java line 127:

> 125:                 // Ensure that the block ordering is deterministic.
> 126:                 Collections.sort(nControlSuccs, (Node a, Node b) ->
> 127:                                  Integer.compare(a.inputNode.getId(), b.inputNode.getId()));

Could be simplified to:
Suggestion:

                nControlSuccs.sort(Comparator.comparingInt((Node a) -> a.inputNode.getId()));

src/utils/IdealGraphVisualizer/ServerCompiler/src/main/java/com/sun/hotspot/igv/servercompiler/ServerCompilerScheduler.java line 570:

> 568:     }
> 569: 
> 570:     private static boolean isRegion(Node n) {

Is unused and can be removed.

src/utils/IdealGraphVisualizer/ServerCompiler/src/main/java/com/sun/hotspot/igv/servercompiler/ServerCompilerScheduler.java line 575:

> 573: 
> 574:     private static boolean isOtherBlockStart(Node n) {
> 575:         return n.inputNode.getProperties().get("name").equals("CountedLoopEnd");

This pattern is used several times. How about replacing these by a new method something like that:


    private static boolean isOtherBlockStart(Node n) {
        return isNodeWithName(n, "CountedLoopEnd");
    }

    private static boolean isNodeWithName(Node node, String nodeName) {
        return node.inputNode.getProperties().get("name").equals(nodeName);
    }

src/utils/IdealGraphVisualizer/ServerCompiler/src/main/resources/com/sun/hotspot/igv/servercompiler/filters/hideExceptionBlocks.filter line 4:

> 2: 
> 3: var f = new RemoveBlockFilter("Hide exception blocks");
> 4: f.addRule(

Could the rule object directly be passed to the constructor instead of going over `addRule()`? On top of that, all filters follow the pattern "create f + `f.apply(graph)`". This could be moved into a single method to simplify filters. But this would exceed the scope of this change and could be done in a separate RFE.

src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/BlockQuickSearch.java line 91:

> 89:                 if (!response.addResult(new Runnable() {
> 90:                         @Override
> 91:                         public void run() {

Could be replaced by lambda:

if (!response.addResult(() -> {
   final EditorTopComponent comp = EditorTopComponent.getActive();
   ....

src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/BlockQuickSearch.java line 122:

> 120:             response.addResult(new Runnable() {
> 121:                 @Override
> 122:                 public void run() {

Can be replaced by lambda.

src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/DiagramScene.java line 649:

> 647:             m.setSubManager(new HierarchicalLayoutManager(HierarchicalLayoutManager.Combine.SAME_OUTPUTS));
> 648:             m.doLayout(new LayoutGraph(edges, figures));
> 649:         } else if (getModel().getShowCFG()) {

Code code be put into separate `doCFGLayout()` method or something like that. Also, you can directly use `model` instead of `getModel()`.

src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/NodeQuickSearch.java line 33:

> 31: import com.sun.hotspot.igv.settings.Settings;
> 32: import com.sun.hotspot.igv.util.LookupHistory;
> 33: import com.sun.hotspot.igv.util.StringUtils;

Copyright of this file should be updated (I somehow cannot comment on non-shown lines)

src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/actions/EnableBlockLayoutAction.java line 2:

> 1: /*
> 2:  * Copyright (c) 2008, 2021, Oracle and/or its affiliates. All rights reserved.

Should be 2022.

src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/actions/EnableSeaLayoutAction.java line 34:

> 32: public class EnableSeaLayoutAction extends AbstractAction {
> 33: 
> 34:     private boolean state;

Seems to be unused and can be removed.

src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/actions/EnableSeaLayoutAction.java line 46:

> 44:     }
> 45: 
> 46:     public void setSelected(boolean b) {

I might be missing something but this method seems to be unused as well.

src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/widgets/BlockWidget.java line 46:

> 44:     public static final int BORDER = 20;
> 45:     public static final Color BACKGROUND_COLOR = new Color(235, 235, 255);
> 46:     private static final Font titleFont = new Font("Arial", Font.BOLD, 14);

Should be in upper case: `TITLE_FONT`

src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/widgets/InputSlotWidget.java line 44:

> 42:         inputSlot = slot;
> 43:         //init();
> 44:         //getFigureWidget().getLeftWidget().addChild(this);

Can also be removed?

src/utils/IdealGraphVisualizer/View/src/main/java/com/sun/hotspot/igv/view/widgets/SlotWidget.java line 72:

> 70:         this.setPreferredLocation(p);
> 71: 
> 72:         //this.setPreferredBounds(this.calculateClientArea());

Can be removed?

-------------

Changes requested by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7817

From aph at openjdk.java.net  Thu Mar 17 13:52:39 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Thu, 17 Mar 2022 13:52:39 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v17]
In-Reply-To: <zyFWnsymbgIL0sdxE9QXNWQ4lnoWrjd__As3bNUV88s=.ff7fefe5-59d6-4b1a-967f-e84bfc30d5ef@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <zyFWnsymbgIL0sdxE9QXNWQ4lnoWrjd__As3bNUV88s=.ff7fefe5-59d6-4b1a-967f-e84bfc30d5ef@github.com>
Message-ID: <KB1RN2QMcun3bPwStP1Ayx_XEy4ruZttl2ORt0R28_Q=.bb358914-3933-462e-8b69-80af83f333dd@github.com>

On Sun, 13 Mar 2022 06:36:15 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
>> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8279508: Windows build failure fix.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4143:

> 4141:   ldmxcsr(new_mxcsr);
> 4142:   // Move raw bits corresponding to double value 0.5 into scratch register.
> 4143:   mov64(scratch, 4602678819172646912L);

Suggestion:

  mov64(scratch, julong_cast(0.5));

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From chagedorn at openjdk.java.net  Thu Mar 17 15:32:32 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 17 Mar 2022 15:32:32 GMT
Subject: RFR: 8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0)
 failed: Don't process dead nodes [v8]
In-Reply-To: <Ac1Nb0W7yD645LlFOZT66w4oV9v8uxpJgZoDQQKVnwk=.f606f437-3e8b-41bd-9361-5d743a8750bb@github.com>
References: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
 <Ac1Nb0W7yD645LlFOZT66w4oV9v8uxpJgZoDQQKVnwk=.f606f437-3e8b-41bd-9361-5d743a8750bb@github.com>
Message-ID: <qvtR0crj3UEtEFXv1NZJ2Rkz4n6bOKO-PfsePE_9NF0=.07222ab6-56ad-4b79-b6c7-235d88eaecde@github.com>

On Thu, 17 Mar 2022 10:55:09 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

>> Problem:
>> Sometimes nodes are generated, and then not properly added to any other node, nor added to the worklist, so that it could be deleted. In some cases, a node can thus survive after IGVN and enter into `ConnectionGraph::compute_escape`, where no dead nodes are expected (except constants).
>> 
>> In `ArrayCopyNode::prepare_array_copy`:
>> In one, I now add the new ConvI2LNode to the worklist if we are aborting.
>> In the other case, I could safely reorder the code, such new ConvI2LNode would only be generated once we know we are not going to abort.
>> 
>> In `SubTypeCheckNode::Ideal`:
>> Replaced `set_req` with `set_req_X`, such that the input-node that is replaced (which is now potentially a dead node) is put on the worklist.
>> 
>> In `ArrayCopyNode::Ideal`:
>> If we decide to `return NULL` we also need to add the potentially dead forward / backward memory nodes to the worklist, they may turn out to be dead.
>> 
>> Added a regression test: the test + flag combination that first reproduced this issue.
>> 
>> All Tests, including this new regression test are passing. Tests rerun after small refactorings.
>
> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove condition that is always true

Looks good!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7728

From duke at openjdk.java.net  Thu Mar 17 15:34:19 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 17 Mar 2022 15:34:19 GMT
Subject: RFR: 8283232: x86: Improve vector broadcast operations [v4]
In-Reply-To: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
References: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
Message-ID: <ixz4Du_ty4dop5N_b2Bpj4_Yz76fvGB4X4yB7S91_6w=.dc98edf2-c060-4778-b231-9662cfc45584@github.com>

> Hi,
> 
> This patch improves the generation of broadcasting a scalar in several ways:
> 
> - Avoid potential data bypass delay which can be observed on some platforms by using the correct type of instruction if it does not require extra instructions.
> - As it has been pointed out, dumping the whole vector into the constant table is costly in terms of code size, this patch minimises this overhead for vector replicate of constants. Also, options are available for constants to be generated with more alignment so that vector load can be made efficiently without crossing cache lines.
> - Vector broadcasting should prefer rematerialising to spilling when register pressure is high.
> 
> This patch also removes some redundant code paths and rename some incorrectly named instructions.
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  fix comparison

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7832/files
  - new: https://git.openjdk.java.net/jdk/pull/7832/files/3bc7731a..3dbc7432

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7832&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7832&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7832.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7832/head:pull/7832

PR: https://git.openjdk.java.net/jdk/pull/7832

From Divino.Cesar at microsoft.com  Thu Mar 17 19:15:36 2022
From: Divino.Cesar at microsoft.com (Cesar Soares Lucas)
Date: Thu, 17 Mar 2022 19:15:36 +0000
Subject: [External] : Re: RFC : Approach to handle Allocation Merges in C2
 Scalar Replacement
In-Reply-To: <BY5PR21MB147353D5267885877DFB47D79A3B9@BY5PR21MB1473.namprd21.prod.outlook.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
 <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
 <806f2baa-9b48-e57a-d153-0a19fc3e709d@oracle.com>
 <BY5PR21MB14735BCBF26C72B09051613E9A379@BY5PR21MB1473.namprd21.prod.outlook.com>
 <3cd5e4b1-5a0e-28ef-2445-1bf65fca4422@oracle.com>
 <BY5PR21MB147353D5267885877DFB47D79A3B9@BY5PR21MB1473.namprd21.prod.outlook.com>
Message-ID: <BY5PR21MB1473482D25CF302438F83A289A129@BY5PR21MB1473.namprd21.prod.outlook.com>

Hi all,

I?ve been experimenting with the idea explained by Vladimir Ivanov and I was able to implement it and have a few non-trivial merges untangled and scalar replaced. However, I found an obstacle on the road. I was able to overcome it, but I?d very much appreciate your opinion about the matter. Assume we start off with the piece of code below.

if (?)     p0 = ?
else       p1 = ?
p = phi(p0, p1)
return p.x

The idea proposed suggests, AFAIU, that we change the code to be something like the below **where we use the bases directly**.

if (?)   p0 = ?
else     p1 = ?

s = # selector phi #

if (s == id_base0)           x0 = p0.x
elseif (s == id_base1)    x1 = p1.x
else                                  halt()

x = phi(x0, x1)
return x

The problem here is that the definition of ?p0? and/or ?p1? doesn?t dominate their use in the loads ?x0 = p0.x? / ?x1 = p1.x?, therefore certain IR verification steps in C2 fail. I was able to work around the issue by adding Phi nodes where all inputs are the same (excluding the ctrl), thus creating a ?fake? definition for the value. Please see code below.

if (?)   p0 = ?
else     p1 = ?

phi0 = phi(p0, p0)
phi1 = Phi(p1, p1)
s = # selector phi #

if (s == id_base0)           x0 = phi0.x
elseif (s == id_base1)    x1 = phi1.x
else                                  halt()

x = phi(x0, x1)
return x

Transforming the code to look like the above silenced the verifications ( :-] ) and at the end EA+SR was able to remove the allocations **and get rid of all the Phi?s**.

So, my question is: is this workaround acceptable? Do you have a suggestion of a better solution?


TIA, Cesar


From: hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.java.net> on behalf of Cesar Soares Lucas <Divino.Cesar at microsoft.com>
Date: Tuesday, February 22, 2022 at 10:01 AM
To: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>, Vladimir Kozlov <vladimir.kozlov at oracle.com>, hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
Cc: Brian Stafford <Brian.Stafford at microsoft.com>, Martijn Verburg <Martijn.Verburg at microsoft.com>
Subject: Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
Hi Vladimir,

I think I've enough feedback to start working on a prototype and see how things play out. Thank you for sharing your ideas/expertise!


Cheers,
Cesar

________________________________________
From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
Sent: February 21, 2022 10:26 AM
To: Cesar Soares Lucas; Vladimir Kozlov; hotspot compiler
Cc: Brian Stafford; Martijn Verburg
Subject: Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement

Hi Cesar,

> I with the selector-based base splitting idea using some examples and I think I understand the mechanics well. It's conceptually simple and quite effective, I like it! I've another question, though. From your previous message I had understood that we needed the clustering because split_unique_types can't handle multiple bases at once, which makes sense to me. _This time I don't understand why we need to do the clustering before doing the selector-based transformation_. AFAIU this transformation won't be creating any memory slices but rather just assigning IDs to different bases and then creating specialized memory operations conditionally using the different bases.

Yes, that's a valid simplification. It does sound like introducing
selector ID doesn't require a separate memory graph (and can be
performed before split_unique_types()), but I don't have a good
understanding how complicated simplifying selector-based IR shapes would
be compared to original (memory op-based) ones. It's definitely worth
experimenting with.

Best regards,
Vladimir Ivanov

> ________________________________________
> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> Sent: February 17, 2022 7:37 AM
> To: Vladimir Kozlov; Cesar Soares Lucas; hotspot compiler
> Cc: Brian Stafford; Martijn Verburg
> Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>
>
>> But depending on the actual shape of the base pointer (here it's
>> Phi(obj1,obj2)), it may become infeasible (from performance perspective)
>> or even impossible (e.g., for complex loop variant conditions) to
>> separate instance slices.
>
> I'd like to correct myself. After thinking more about the problem, I see
> a universal way to scalarize clusters of interfering non-escaping
> allocations even in presence of accesses with indeterminate base.
>
> The crucial property for such cluster of interacting non-escaping
> allocations is for any memory access its base is either part of the
> cluster or not (it's a static property for every access). Then, when it
> is part of the cluster, then the number of possible base values at
> runtime is finite and is a subset of the cluster.
>
> So, memory graph for the cluster can be scalarized as follows:
>
>     (1) separate memory graph for the cluster
>
>     (2) on the newly constructed graph:
>
>        (a) replace every base pointer with an ID ("selector id") and
> recreate data graph for selector IDs from base pointers graph;
>
>        (b) for accesses with indeterminate base pointer, replace them
> with a merge of states from relevant allocations selected by "selector id"
>
>        (c) after 2b, all memory accesses from the cluster memory graph
> should have fixed base pointing at a particular allocation
>
>     (3) scalarize individual allocations from the cluster one by one
> (since they are independent now)
>
>        - additional transformation (like, split-through-phi) should
> simplify the graph by reducing the number of cases at merge points to
> care about (ideally, leaving only a single one);
>
>
>
> As an illustration:
>
>     val = Load (AddP (Phi R base1 base2) offset) mem # load A.i
>
> ==(pseudo-code)==>
>
>     selector = (Phi R #base1 #base2)
>
>     if (selector == #base1) {
>       val1 = Load (base1 + offset) mem
>     } else if (selector == #base2) {
>       val2 = Load (base2 + offset) mem
>     } else {
>       halt(); // impossible
>     }
>
>     val = Phi(R1, val1, val2)
>
> ======
>
>     Store (AddP (Phi R base1 base2) offset) mem v # store A.i v
>
> ==(pseudo-code)==>
>
>     selector = (Phi R #base1 #base2)
>
>     if (selector == #base1) {
>       Store base1 mem v ==> mem1
>     } else if (selector == #base2) {
>       Store base2 mem v ==> mem2
>     } else {
>       halt(); // impossible
>     }
>
>     mem = Phi(R1, mem1, mem2);
>
>
> Best regards,
> Vladimir Ivanov
>
>>
>> So, gradual approach seems the way to go:
>>     (1) split memory graph for clusters of interacting non-escaping
>> allocations;
>>
>>     (2) perform adhoc transformation targeted at untangling aliasing
>> accesses (e.g, split-through-phi);
>>
>>     (3) extract unique instance types where possible, thus making the
>> corresponding allocation scalar replaceable
>>
>> =====================================================================
>>
>> Also, one observation: interacting allocations don't have to be of the
>> same class.
>>
>>       static int testPolluted(int r, boolean b) {
>>           A obj1 = new B1(r);
>>           A obj2 = new B2(r);
>>
>>           A obj = (b ? obj1 : obj2);
>>           for (int i = 1; i < r; i++) {
>>               obj.i++;
>>           }
>>
>>           return obj1.i + obj2.i;
>>       }
>>
>> Requiring unique instance types to perform SR (and not enhancing SR to
>> handle aliasing allocations case) helps avoid some challenges in
>> instance rematerialization logic at safepoints, because actual shape of
>> the scalarized object (its class and exact set of fields) becomes a
>> runtime property.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>>>>
>>>>> Otherwise, I believe wide memory states/merges would pose serious
>>>>> problems. E.g., when a load is split through a phi, you need to pick
>>>>> correct memory states for the new loads above the phi which quickly
>>>>> becomes quite a challenging task.
>>>>
>>>> Especially in loops. Actually I did tried such approach before and I
>>>> agree that it is hard.
>>>>
>>>> Thanks,
>>>> Vladimir K
>>>>
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>>>
>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>       p0 = Allocate(...);
>>>>>>       ...
>>>>>>       p0.x = first;
>>>>>>       p0.y = second;
>>>>>>
>>>>>>       if (cond) {
>>>>>>           p1 = Allocate(...);
>>>>>>           ...
>>>>>>           p1.x = second;
>>>>>>           p1.y = first;
>>>>>>       }
>>>>>>
>>>>>>       p = phi(p0, p1) // unused and will be removed
>>>>>>
>>>>>>
>>>>>>       return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>>>> }
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir K
>>>>>>
>>>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>>>> (BCCing hotspot-dev and moving the discussion to
>>>>>>> hotspot-compiler-dev.)
>>>>>>>
>>>>>>> Hi Cesar,
>>>>>>>
>>>>>>> Thanks for looking into enhancing EA.
>>>>>>>
>>>>>>> Overall, the proposal looks reasonable.
>>>>>>>
>>>>>>> I suggest to look more closely at split_unique_types().
>>>>>>> It introduces a dedicated class of alias categories for fields of
>>>>>>> the allocation being eliminated and clones memory graph. I don't
>>>>>>> see why it shouldn't work for multiple allocations.
>>>>>>>
>>>>>>> Moreover, split_unique_types() will break if you start optimizing
>>>>>>> multiple allocations at once. The notion of unique alias should be
>>>>>>> adjusted and cover the union of unique aliases for all interacting
>>>>>>> allocations.
>>>>>>>
>>>>>>> Seems like you need to enhance SR to work on non-intersecting
>>>>>>> clusters of allocations.
>>>>>>>
>>>>>>> One thing to take care of: scalar replacement relies on
>>>>>>> TypeOopPtr::instance_id().
>>>>>>>
>>>>>>>     // If not InstanceTop or InstanceBot, indicates that this is
>>>>>>>     // a particular instance of this type which is distinct.
>>>>>>>     // This is the node index of the allocation node creating this
>>>>>>> instance.
>>>>>>>     int           _instance_id;
>>>>>>>
>>>>>>> It'll break when multiple allocations are in play.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Vladimir Ivanov
>>>>>>>
>>>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>>>> Hi there again!
>>>>>>>>
>>>>>>>> Can you please give me feedback on the following approach to at
>>>>>>>> least partially
>>>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>>>
>>>>>>>> The problem that I am trying to solve arises when allocations are
>>>>>>>> merged after a
>>>>>>>> control flow split. The code below shows _one example_ of such a
>>>>>>>> situation.
>>>>>>>>
>>>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>>>>       Point p = new Point(x, y);
>>>>>>>>       if (cond)
>>>>>>>>           p = new Point(y, x);
>>>>>>>>       // Allocations for p are merged here.
>>>>>>>>       return p.calc();
>>>>>>>> }
>>>>>>>>
>>>>>>>> Assuming the method calls on "p" are inlined then the allocations
>>>>>>>> will not
>>>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>>>
>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>       p0 = Allocate(...);
>>>>>>>>       ...
>>>>>>>>       p0.x = first;
>>>>>>>>       p0.y = second;
>>>>>>>>
>>>>>>>>       if (cond) {
>>>>>>>>           p1 = Allocate(...);
>>>>>>>>           ...
>>>>>>>>           p1.x = second;
>>>>>>>>           p1.y = first;
>>>>>>>>       }
>>>>>>>>
>>>>>>>>       p = phi(p0, p1)
>>>>>>>>
>>>>>>>>       return p.x - p.y;
>>>>>>>> }
>>>>>>>>
>>>>>>>> However, one of the constraints implemented here [2],
>>>>>>>> specifically the third
>>>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>>>
>>>>>>>> The approach that I'm considering for solving the problem is to
>>>>>>>> replace the Phi
>>>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields
>>>>>>>> of the objects
>>>>>>>> in the original Phi. The IR for `ex1` would look something like
>>>>>>>> this after the
>>>>>>>> transformation:
>>>>>>>>
>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>       p0 = Allocate(...);
>>>>>>>>       ...
>>>>>>>>       p0.x = first;
>>>>>>>>       p0.y = second;
>>>>>>>>
>>>>>>>>       if (cond) {
>>>>>>>>           p1 = Allocate(...);
>>>>>>>>           ...
>>>>>>>>           p1.x = second;
>>>>>>>>           p1.y = first;
>>>>>>>>       }
>>>>>>>>
>>>>>>>>       pX = phi(first, second)
>>>>>>>>       pY = phi(second, first)
>>>>>>>>
>>>>>>>>       return pX - pY;
>>>>>>>> }
>>>>>>>>
>>>>>>>> I understand that this transformation might not be applicable for
>>>>>>>> all cases and
>>>>>>>> that it's not as simple as illustrated above. Also, it seems to
>>>>>>>> me that much of
>>>>>>>> what I'd have to implement is already implemented in other steps
>>>>>>>> of the Scalar
>>>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>>>> implementation details I plan to use as much of the existing code
>>>>>>>> as possible.
>>>>>>>> The algorithm for the transformation would be like this:
>>>>>>>>
>>>>>>>> split_phis(phi)
>>>>>>>>       # If output of phi escapes, or something uses its identity, etc
>>>>>>>>       # then we can't remove it. The conditions here might
>>>>>>>> possible be the
>>>>>>>>       # same as the ones implemented in
>>>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>>>>       if cant_remove_phi_output(phi)
>>>>>>>>           return ;
>>>>>>>>
>>>>>>>>       # Collect a set of tuples(F,U) containing nodes U that uses
>>>>>>>> field F
>>>>>>>>       # member of the object resulting from `phi`.
>>>>>>>>       fields_used = collect_fields_used_after_phi(phi)
>>>>>>>>
>>>>>>>>       foreach field in fields_used
>>>>>>>>           producers = {}
>>>>>>>>
>>>>>>>>           # Create a list with the last Store for each field
>>>>>>>> "field" on the
>>>>>>>>           # scope of each of the Phi input objects.
>>>>>>>>           foreach o in phi.inputs
>>>>>>>>               # The function called below might re-use a lot of
>>>>>>>> the code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>>>>               producers += last_store_to_o_field(0, field)
>>>>>>>>           # Create a new phi node whose inputs are the Store's to
>>>>>>>> 'field'
>>>>>>>>           field_phi = create_new_phi(producers)
>>>>>>>>
>>>>>>>>           update_consumers(field, field_phi)
>>>>>>>>
>>>>>>>> The implementation that I envisioned would be as a "pre-process"
>>>>>>>> [3] step just
>>>>>>>> after EA but before the constraint checks in
>>>>>>>> `adjust_scalar_replaceable_state`
>>>>>>>> [2]. If we agree that the overall Scalar Replacement
>>>>>>>> implementation goes through
>>>>>>>> the following major phases:
>>>>>>>>
>>>>>>>>       1. Identify the Escape Status of objects.
>>>>>>>>       2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>> based on a set of constraints.
>>>>>>>>       3. Make call to Split_unique_types [4].
>>>>>>>>       4 Iterate over object and array allocations.
>>>>>>>>           4.1 Check if allocation can be eliminated.
>>>>>>>>           4.2 Perform scalar replacement. Replace uses of object
>>>>>>>> in Safepoints.
>>>>>>>>           4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>
>>>>>>>> The transformation that I am proposing would change the overall
>>>>>>>> flow to look
>>>>>>>> like this:
>>>>>>>>
>>>>>>>>       1. Identify the Escape Status of objects.
>>>>>>>>       2. ----> New: "Split phi functions" <----
>>>>>>>>       2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>> based on a set of constraints.
>>>>>>>>       3. Make call to Split_unique_types [14].
>>>>>>>>       4 Iterate over object and array allocations.
>>>>>>>>           4.1 ----> Moved to split_phi: "Check if allocation can
>>>>>>>> be eliminated" <----
>>>>>>>>           4.2 Perform scalar replacement. Replace uses of object
>>>>>>>> in Safepoints.
>>>>>>>>           4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>
>>>>>>>> Please let me know what you think and thank you for taking the
>>>>>>>> time to review
>>>>>>>> this!
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Cesar
>>>>>>>>
>>>>>>>> Notes:
>>>>>>>>
>>>>>>>>       [1] I am not sure yet how this approach will play with the
>>>>>>>> case of a merge
>>>>>>>>           with NULL.
>>>>>>>>       [2]
>>>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809%26amp%3Bdata%3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc%24&amp;data=04%7C01%7Cdivino.cesar%40microsoft.com%7C8c1737b992e847651e8d08d9f62d649b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637811497098895122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=8hLm9BcYVRF810gFqf2%2B%2Fd28jzqU2k7htD%2FDLqR9vAM%3D&amp;reserved=0
>>>>>>>>
>>>>>>>>
>>>>>>>>       [3] Another option would be to "patch" the current
>>>>>>>> implementation to be able
>>>>>>>>           to handle the merges. I am not certain that the "patch"
>>>>>>>> approach would be
>>>>>>>>           better, however, the "pre-process" approach is certainly
>>>>>>>> much easier to test
>>>>>>>>           and more readable.
>>>>>>>>
>>>>>>>>       [4] I cannot say I understand 100% the effects of executing
>>>>>>>>           split_unique_types(). Would the transformation that I am
>>>>>>>> proposing need to
>>>>>>>>           be after the call to split_unique_types?

From duke at openjdk.java.net  Thu Mar 17 22:39:06 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 17 Mar 2022 22:39:06 GMT
Subject: RFR: 8283232: x86: Improve vector broadcast operations [v5]
In-Reply-To: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
References: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
Message-ID: <6BMjbZE-S8duO5F6mWU0tpPo6g4OV2QBSNZ5IuxTaP8=.c7c76db6-e84a-48a8-9e82-d1c3b97a4bd6@github.com>

> Hi,
> 
> This patch improves the generation of broadcasting a scalar in several ways:
> 
> - Avoid potential data bypass delay which can be observed on some platforms by using the correct type of instruction if it does not require extra instructions.
> - As it has been pointed out, dumping the whole vector into the constant table is costly in terms of code size, this patch minimises this overhead for vector replicate of constants. Also, options are available for constants to be generated with more alignment so that vector load can be made efficiently without crossing cache lines.
> - Vector broadcasting should prefer rematerialising to spilling when register pressure is high.
> 
> This patch also removes some redundant code paths and rename some incorrectly named instructions.
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  rematerializing input count

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7832/files
  - new: https://git.openjdk.java.net/jdk/pull/7832/files/3dbc7432..bb494bc2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7832&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7832&range=03-04

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7832.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7832/head:pull/7832

PR: https://git.openjdk.java.net/jdk/pull/7832

From duke at openjdk.java.net  Thu Mar 17 23:08:13 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Thu, 17 Mar 2022 23:08:13 GMT
Subject: RFR: 8283232: x86: Improve vector broadcast operations [v6]
In-Reply-To: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
References: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
Message-ID: <HiwXXDQjzk_os-mBZi2ASPgy6HLzEzg0ox48TVBLklU=.5bdd3f10-c8ae-4782-8cfd-f126ee1e2524@github.com>

> Hi,
> 
> This patch improves the generation of broadcasting a scalar in several ways:
> 
> - Avoid potential data bypass delay which can be observed on some platforms by using the correct type of instruction if it does not require extra instructions.
> - As it has been pointed out, dumping the whole vector into the constant table is costly in terms of code size, this patch minimises this overhead for vector replicate of constants. Also, options are available for constants to be generated with more alignment so that vector load can be made efficiently without crossing cache lines.
> - Vector broadcasting should prefer rematerialising to spilling when register pressure is high.
> 
> This patch also removes some redundant code paths and rename some incorrectly named instructions.
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  unsignness

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7832/files
  - new: https://git.openjdk.java.net/jdk/pull/7832/files/bb494bc2..2b1c1da4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7832&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7832&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7832.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7832/head:pull/7832

PR: https://git.openjdk.java.net/jdk/pull/7832

From duke at openjdk.java.net  Fri Mar 18 00:29:07 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Fri, 18 Mar 2022 00:29:07 GMT
Subject: RFR: 8283232: x86: Improve vector broadcast operations [v7]
In-Reply-To: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
References: <NJgxmXYMLyzs78VKdNQsbhwErM0H1UnKtTe9FKvKzf0=.896fb149-85ae-4ed5-8c0a-6659704ad130@github.com>
Message-ID: <Q0otIkhh1pfdBdHoA1OuUyqM-y5LXpfgyxXqea6j8sY=.3bd1dbf5-a8b2-4c52-bcd6-a36f38356524@github.com>

> Hi,
> 
> This patch improves the generation of broadcasting a scalar in several ways:
> 
> - Avoid potential data bypass delay which can be observed on some platforms by using the correct type of instruction if it does not require extra instructions.
> - As it has been pointed out, dumping the whole vector into the constant table is costly in terms of code size, this patch minimises this overhead for vector replicate of constants. Also, options are available for constants to be generated with more alignment so that vector load can be made efficiently without crossing cache lines.
> - Vector broadcasting should prefer rematerialising to spilling when register pressure is high.
> 
> This patch also removes some redundant code paths and rename some incorrectly named instructions.
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  remove duplicate

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7832/files
  - new: https://git.openjdk.java.net/jdk/pull/7832/files/2b1c1da4..63d84bd5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7832&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7832&range=05-06

  Stats: 49 lines in 2 files changed: 5 ins; 40 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7832.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7832/head:pull/7832

PR: https://git.openjdk.java.net/jdk/pull/7832

From jiefu at openjdk.java.net  Fri Mar 18 02:53:51 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 18 Mar 2022 02:53:51 GMT
Subject: RFR: 8283353: compiler/c2/cr6865031/Test.java and
 compiler/runtime/Test6826736.java fails on x86_32
Message-ID: <oQ85NUL5HK6lpyDFcEAOmBOYtFdRaeJvVy-u4Yy8xyM=.2feaed5c-510a-474f-9c1c-0d7ed519194d@github.com>

Hi all,

Fail due to improperly specified VM option 'HeapBaseMinAddress=32g' on x86_32.


STDERR:
Improperly specified VM option 'HeapBaseMinAddress=32g'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.


The fix just excludes them for 32-bit VMs.

Thanks.
Best regards,
Jie

-------------

Commit messages:
 - 8283353: compiler/c2/cr6865031/Test.java and compiler/runtime/Test6826736.java fails on x86_32

Changes: https://git.openjdk.java.net/jdk/pull/7864/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7864&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283353
  Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7864.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7864/head:pull/7864

PR: https://git.openjdk.java.net/jdk/pull/7864

From chagedorn at openjdk.java.net  Fri Mar 18 07:50:36 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 18 Mar 2022 07:50:36 GMT
Subject: RFR: 8283353: compiler/c2/cr6865031/Test.java and
 compiler/runtime/Test6826736.java fails on x86_32
In-Reply-To: <oQ85NUL5HK6lpyDFcEAOmBOYtFdRaeJvVy-u4Yy8xyM=.2feaed5c-510a-474f-9c1c-0d7ed519194d@github.com>
References: <oQ85NUL5HK6lpyDFcEAOmBOYtFdRaeJvVy-u4Yy8xyM=.2feaed5c-510a-474f-9c1c-0d7ed519194d@github.com>
Message-ID: <XAMs7rCHnzXegIoXG-bDWU6cUxmNHQ-LeIEL8QEuxPU=.35d78a7d-7c78-4cdb-9edd-5beb8ba8ce0d@github.com>

On Fri, 18 Mar 2022 02:47:09 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Fail due to improperly specified VM option 'HeapBaseMinAddress=32g' on x86_32.
> 
> 
> STDERR:
> Improperly specified VM option 'HeapBaseMinAddress=32g'
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> 
> The fix just excludes them for 32-bit VMs.
> 
> Thanks.
> Best regards,
> Jie

Looks good and trivial.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7864

From jiefu at openjdk.java.net  Fri Mar 18 08:02:34 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 18 Mar 2022 08:02:34 GMT
Subject: RFR: 8283353: compiler/c2/cr6865031/Test.java and
 compiler/runtime/Test6826736.java fails on x86_32
In-Reply-To: <XAMs7rCHnzXegIoXG-bDWU6cUxmNHQ-LeIEL8QEuxPU=.35d78a7d-7c78-4cdb-9edd-5beb8ba8ce0d@github.com>
References: <oQ85NUL5HK6lpyDFcEAOmBOYtFdRaeJvVy-u4Yy8xyM=.2feaed5c-510a-474f-9c1c-0d7ed519194d@github.com>
 <XAMs7rCHnzXegIoXG-bDWU6cUxmNHQ-LeIEL8QEuxPU=.35d78a7d-7c78-4cdb-9edd-5beb8ba8ce0d@github.com>
Message-ID: <yU9cK3g1qQgmdlldO6Ad_evi2_w_4o5k0DQmMmdXHTg=.26dae0e4-bc66-443c-a2e2-948d375cb046@github.com>

On Fri, 18 Mar 2022 07:46:53 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> Looks good and trivial.

Thanks @chhagedorn .

-------------

PR: https://git.openjdk.java.net/jdk/pull/7864

From jiefu at openjdk.java.net  Fri Mar 18 08:02:35 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 18 Mar 2022 08:02:35 GMT
Subject: Integrated: 8283353: compiler/c2/cr6865031/Test.java and
 compiler/runtime/Test6826736.java fails on x86_32
In-Reply-To: <oQ85NUL5HK6lpyDFcEAOmBOYtFdRaeJvVy-u4Yy8xyM=.2feaed5c-510a-474f-9c1c-0d7ed519194d@github.com>
References: <oQ85NUL5HK6lpyDFcEAOmBOYtFdRaeJvVy-u4Yy8xyM=.2feaed5c-510a-474f-9c1c-0d7ed519194d@github.com>
Message-ID: <x99YfTHmtrBzuCm4wrpwe5koXJQPc0Ut_mjKEmU9_QI=.9927a6ee-f424-4aa7-8f51-49e645b545d2@github.com>

On Fri, 18 Mar 2022 02:47:09 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Fail due to improperly specified VM option 'HeapBaseMinAddress=32g' on x86_32.
> 
> 
> STDERR:
> Improperly specified VM option 'HeapBaseMinAddress=32g'
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> 
> The fix just excludes them for 32-bit VMs.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: b96cb048
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b96cb048f1a7f3ae6e745b245f2b04c64ebb911e
Stats:     4 lines in 2 files changed: 3 ins; 0 del; 1 mod

8283353: compiler/c2/cr6865031/Test.java and compiler/runtime/Test6826736.java fails on x86_32

Reviewed-by: chagedorn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7864

From duke at openjdk.java.net  Fri Mar 18 11:15:45 2022
From: duke at openjdk.java.net (duke)
Date: Fri, 18 Mar 2022 11:15:45 GMT
Subject: Withdrawn: JDK-8277178: Reduce the priority of data dependent nodes
 when OptoScheduling enabled
In-Reply-To: <PdtgtgzxHOdz76Tyh7QvBXbGXt1ETkkSRzqH871QDKA=.3cdc32a9-eb88-4864-ac95-7b0eea1b4948@github.com>
References: <PdtgtgzxHOdz76Tyh7QvBXbGXt1ETkkSRzqH871QDKA=.3cdc32a9-eb88-4864-ac95-7b0eea1b4948@github.com>
Message-ID: <h5sP71WTIKH1nHFbxN1SPoplmvJu2lGG_LcVulOCkY4=.a91b8275-b64d-4f6a-87e9-1df6af322858@github.com>

On Tue, 16 Nov 2021 09:06:57 GMT, SUN Guoyun <duke at openjdk.java.net> wrote:

> when doing gcm/lcm, We should not only consider the height of nodes(latency), but also consider whether there is data dependency between nodes. When there is data dependency between two nodes and the delay of the previous node is large, another node without data dependency can be considered inserting between the two nodes. For example:
> for java code
> <pre><code class="java">
>     public static final double fval = 2.00;
>     public static double[] A = new double[N];
>     public static int[] B = new int[N];
> 
>     public static void testP(){
> 	for (int i=0; i<N; i++) {
> 	   A[i] += A[i] * fval;
> 	   B[i] += B[i]+2;
>         }
>     }
> </code></pre>
> 
> when use `-XX:+OptoScheduling` in aarch64, the sequence is
> <pre><code class="shell">
> 190     B15: #	out( B15 B16 ) <- in( B14 B15 ) Loop( B15-B15 inner main of N118 strip mined) Freq: 9.9999e+11
> 190     sxtw  R13, R15	# i2l
> 194 +   add R14, R17, R13, LShiftL #3	# ptr
> 198     ldrd  V16, [R14, #16]	# double
> 19c +   fmuld   V18, V16, V17
> 1a0 +   faddd   V16, V18, V16
> 1a4     strd  V16, [R14, #16]	# double
> 1a8 +   add R13, R0, R13, LShiftL #2	# ptr
> 1ac +   ldrw  R1, [R13, #16]	# int
> 1b0 +   addw  R14, R1, R1
> 1b4 +   addw R1, R14, #2
> 1b8 +   addw R15, R15, #1
> 1bc     strw  R1, [R13, #16]	# int
> 1c0 +   cmpw  R15, R12
> 1c4     blt B15 	// counted loop end  P=1.000000 C=40960.000000
> </code></pre>
> 
> Then a more efficient sequence should be:
> <pre><code class="shell">
> 190     B15: #	out( B15 B16 ) <- in( B14 B15 ) Loop( B15-B15 inner main of N118 strip mined) Freq: 9.9999e+11
> 190     sxtw  R13, R14	# i2l
> 194     add R15, R17, R13, LShiftL #3	# ptr
> 198     add R13, R0, R13, LShiftL #2	# ptr
> 19c     ldrd  V16, [R15, #16]	# double
> 1a0     ldrw  R2, [R13, #16]	# int
> 1a4     fmuld   V18, V16, V17
> 1a8     addw  R1, R2, R2
> 1ac     faddd   V16, V18, V16
> 1b0     strd  V16, [R15, #16]	# double
> 1b4     addw R1, R1, #2
> 1b8     strw  R1, [R13, #16]	# int
> 1bc     addw R14, R14, #1
> 1c0     cmpw  R14, R12
> 1c4     blt B15 	// counted loop end  P=1.000000 C=40960.000000
> </code></pre>
> 
> This problem also exists in MIPS architecture. This is a patch to fix this problem. Please help review it.
> Thanks

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/6407

From jbhateja at openjdk.java.net  Fri Mar 18 20:19:08 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 18 Mar 2022 20:19:08 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v18]
In-Reply-To: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
Message-ID: <KyoBFGrYKdHoGAWeNhM54eGA-AtOToazLOFg-zrnI9s=.a23c0299-ff24-44fb-aa13-e960d7b1f942@github.com>

> Summary of changes:
> - Intrinsify Math.round(float) and Math.round(double) APIs.
> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
> - Test creation using new IR testing framework.
> 
> Following are the performance number of a JMH micro included with the patch 
> 
> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
> 
> 
> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
> -- | -- | -- | -- | -- | -- | -- | --
> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
> 
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - 8279508: Using an explicit scratch register since rscratch1 is bound to r10 and its usage is transparent to compiler.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
 - 8279508: Windows build failure fix.
 - 8279508: Styling comments resolved.
 - 8279508: Creating separate test for round double under feature check.
 - 8279508: Reducing the invocation count and compile thresholds for RoundTests.java.
 - 8279508: Review comments resolution.
 - 8279508: Preventing domain switch-over penalty for Math.round(float) and constraining unrolling to prevent code bloating.
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
 - 8279508: Removing +LogCompilation flag.
 - ... and 12 more: https://git.openjdk.java.net/jdk/compare/ff0b0927...c17440cf

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7094/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=17
  Stats: 800 lines in 25 files changed: 707 ins; 30 del; 63 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094

PR: https://git.openjdk.java.net/jdk/pull/7094

From jbhateja at openjdk.java.net  Fri Mar 18 20:19:10 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Fri, 18 Mar 2022 20:19:10 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v17]
In-Reply-To: <1J7RFTiEF7VfaEg4EF29Hwd9UUU0D1MM1xh6waG3ulY=.251d7fd9-0d1d-4288-9a55-6feca4b0ec6a@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <zyFWnsymbgIL0sdxE9QXNWQ4lnoWrjd__As3bNUV88s=.ff7fefe5-59d6-4b1a-967f-e84bfc30d5ef@github.com>
 <1J7RFTiEF7VfaEg4EF29Hwd9UUU0D1MM1xh6waG3ulY=.251d7fd9-0d1d-4288-9a55-6feca4b0ec6a@github.com>
Message-ID: <9OJ2oXsQoXjxikba14rEmZMby_rRgq5yzeiwMkk0AMk=.07f34037-6510-453a-bb63-1f5ab162a530@github.com>

On Mon, 14 Mar 2022 10:35:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8279508: Windows build failure fix.
>
> `compiler/c2/cr6340864/TestFloatVect.java` and `TestDoubleVect.java` fail on Windows:
> 
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000001971b940123, pid=56524, tid=57368
> #
> # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-03-14-0834080.tobias.hartmann.jdk2)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-03-14-0834080.tobias.hartmann.jdk2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
> # Problematic frame:
> # J 205 c2 compiler.c2.cr6340864.TestFloatVect.test_round([I[F)V (24 bytes) @ 0x000001971b940123 [0x000001971b93ffe0+0x0000000000000143]

Hi @TobiHartmann , Can you kindly regress latest changes through your test infrastructure 
Hi @theRealAph , Your suggestions incorporated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From jiefu at openjdk.java.net  Sat Mar 19 02:49:28 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 19 Mar 2022 02:49:28 GMT
Subject: RFR: 8282162: [vector] Optimize vector negation API
In-Reply-To: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
Message-ID: <wcfhjAG9qX5jS9Sl70R59cGtCBbIT2W_nqompdTHaCU=.690af3d0-c3ab-4a5f-a264-df92f8022eeb@github.com>

On Fri, 11 Mar 2022 06:29:22 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE.
> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern.
> 
> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture:
>   - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation.
>   - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`.
> 
> So with this patch, the following transformations are applied:
> 
> For non-masked negation with NEON:
> 
>   movi    v16.4s, #0x0
>   sub v17.4s, v16.4s, v17.4s       ==> neg v17.4s, v17.4s
> 
> and with SVE:
> 
>   mov z16.s, #0
>   sub z18.s, z16.s, z17.s          ==> neg z16.s, p7/m, z16.s
> 
> For masked negation with NEON:
> 
>   movi    v17.4s, #0x1
>   mvn v19.16b, v18.16b
>   mov v20.16b, v16.16b             ==>  neg v18.4s, v17.4s
>   bsl v20.16b, v19.16b, v18.16b         bsl v19.16b, v18.16b, v17.16b
>   add v19.4s, v20.4s, v17.4s
>   mov v18.16b, v16.16b
>   bsl v18.16b, v19.16b, v20.16b
> 
> and with SVE:
> 
>   mov z16.s, #-1
>   mov z17.s, #1                    ==> neg z16.s, p0/m, z16.s
>   eor z18.s, p0/m, z18.s, z16.s
>   add z18.s, p0/m, z18.s, z17.s
> 
> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed):
> 
> NEON:
> Benchmark                Gain
> Byte128Vector.NEG        1.029
> Byte128Vector.NEGMasked  1.757
> Short128Vector.NEG       1.041
> Short128Vector.NEGMasked 1.659
> Int128Vector.NEG         1.005
> Int128Vector.NEGMasked   1.513
> Long128Vector.NEG        1.003
> Long128Vector.NEGMasked  1.878
> 
> SVE with 512-bits:
> Benchmark                Gain
> ByteMaxVector.NEG        1.10
> ByteMaxVector.NEGMasked  1.165
> ShortMaxVector.NEG       1.056
> ShortMaxVector.NEGMasked 1.195
> IntMaxVector.NEG         1.002
> IntMaxVector.NEGMasked   1.239
> LongMaxVector.NEG        1.031
> LongMaxVector.NEGMasked  1.191
> 
> X86 (non AVX-512):
> Benchmark                Gain
> ByteMaxVector.NEGMasked  1.254
> ShortMaxVector.NEGMasked 1.359
> IntMaxVector.NEGMasked   1.431
> LongMaxVector.NEGMasked  1.989
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896

src/hotspot/share/opto/vectorIntrinsics.cpp line 209:

> 207: #ifndef PRODUCT
> 208:       if (C->print_intrinsics()) {
> 209:         tty->print_cr("  ** Rejected vector op (%s,%s,%d) because architecture does not support variable vector negate",

"variable vector negate" seems a bit strange to me.
How about removing "variable"?

src/hotspot/share/opto/vectorIntrinsics.cpp line 291:

> 289:   if ((mask_use_type & VecMaskUsePred) != 0) {
> 290:     if (!Matcher::has_predicated_vectors()) {
> 291:       return false;

If we return here, we would miss the intrinsic failing msg "Rejected vector mask predicate using ...", right?

src/hotspot/share/opto/vectornode.cpp line 141:

> 139:       case T_BYTE:
> 140:       case T_SHORT:
> 141:       case T_INT: return Op_NegVI;

Why not add `Op_NegVB` for `BYTE` and `Op_NegVS` for `SHORT`?
Is there any performance drop for byte/short negation operation if both of them are handled as a NegVI vector?

src/hotspot/share/opto/vectornode.cpp line 1635:

> 1633: }
> 1634: 
> 1635: Node* NegVINode::Ideal(PhaseGVN* phase, bool can_reshape) {

Much duplication in `NegVINode::Ideal` and `NegVLNode::Ideal`.
Is it possible to refactor the implementation?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From jiefu at openjdk.java.net  Sat Mar 19 03:14:26 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 19 Mar 2022 03:14:26 GMT
Subject: RFR: 8282162: [vector] Optimize vector negation API
In-Reply-To: <UIbbi5W7BMv_b9IuzYdCQOCzSNfJuHEvOOuqqRyhHUE=.cc631985-5ef3-4d93-a6d6-c73db7903412@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
 <-E5E_NBci6gsGyOV5nWuTUNKLVnjiw2IiWjjgv2vFz0=.ebe7c447-ede9-4437-815c-a2004f9d6ce1@github.com>
 <UIbbi5W7BMv_b9IuzYdCQOCzSNfJuHEvOOuqqRyhHUE=.cc631985-5ef3-4d93-a6d6-c73db7903412@github.com>
Message-ID: <p3lkqI9cxLgVusyCGgnHKdvdKvHBEM7k4K05wVTogu4=.65b852ba-7d1c-4dd9-af68-f1a238050dd3@github.com>

On Tue, 15 Mar 2022 02:47:20 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Note that in terms of Java semantics, negation of floating point values needs to be implemented as subtraction from negative zero rather than positive zero:
> 
> double negate(double arg) {return -0.0 - arg; }
> 
> This is to handle signed zeros correctly.

This seems easy to be broken by an opt enhancement.
Just wondering do we have a jtreg test for this point? @jddarcy 
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From duke at openjdk.java.net  Sat Mar 19 14:55:30 2022
From: duke at openjdk.java.net (duke)
Date: Sat, 19 Mar 2022 14:55:30 GMT
Subject: Withdrawn: 8279651: [vectorapi] Implement the missing intrinsics for
 casting from integrals on x64
In-Reply-To: <iDJv_yQ8umHQdDsoDLJBD06u6d9GjAKyZSlhFoRyhkQ=.3cc41b1c-01e9-4af4-8f6c-d36b37306444@github.com>
References: <iDJv_yQ8umHQdDsoDLJBD06u6d9GjAKyZSlhFoRyhkQ=.3cc41b1c-01e9-4af4-8f6c-d36b37306444@github.com>
Message-ID: <xyREgt0ZSviTKPsKAPO3fEsEWQKkAm1u9SXkNaX8cjA=.e7380696-69ca-42b1-8563-92862b5b4783@github.com>

On Mon, 10 Jan 2022 00:38:41 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi,
> 
> This patch implements the remaining casts from integral types on x64.
> 
> Thank you very much.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7002

From duke at openjdk.java.net  Sun Mar 20 05:21:24 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Sun, 20 Mar 2022 05:21:24 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con
In-Reply-To: <MRdZSFcQFXaTh1k3x0y_grTFweY7ClildBdyQ7Mwi7U=.8efcf85b-73e4-45fc-be1b-d9591ad7078c@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
 <MRdZSFcQFXaTh1k3x0y_grTFweY7ClildBdyQ7Mwi7U=.8efcf85b-73e4-45fc-be1b-d9591ad7078c@github.com>
Message-ID: <ArGXOX-HzJl-GMe7vAXWv0CP-u0zflQNmyOJcKVNMfc=.a6ad8581-db6a-474e-abc9-ef14206f9211@github.com>

On Mon, 14 Mar 2022 04:54:48 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> That is what I mean by saying that careless strength reduction restricts our ability to perform more efficient transformations. What I propose is we delay your mentioned transformation after idealisation has settled on the whole graph. Thanks.

Thank you. I was wondering if you mean other stage, for example `Identity` (afaik `Identity` is invoked after `Ideal`), by saying "after idealisation has settled on the whole graph"? I am not sure where I should move transformation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7795

From xgong at openjdk.java.net  Mon Mar 21 01:24:40 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 21 Mar 2022 01:24:40 GMT
Subject: RFR: 8282162: [vector] Optimize vector negation API
In-Reply-To: <wcfhjAG9qX5jS9Sl70R59cGtCBbIT2W_nqompdTHaCU=.690af3d0-c3ab-4a5f-a264-df92f8022eeb@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
 <wcfhjAG9qX5jS9Sl70R59cGtCBbIT2W_nqompdTHaCU=.690af3d0-c3ab-4a5f-a264-df92f8022eeb@github.com>
Message-ID: <NdmL_GlhtLXdoO7sDPA-5bcLzke6udfzqmOmIRq9jyI=.a8a5a012-d758-4836-86f0-38d852f49707@github.com>

On Sat, 19 Mar 2022 02:34:55 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE.
>> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern.
>> 
>> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture:
>>   - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation.
>>   - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`.
>> 
>> So with this patch, the following transformations are applied:
>> 
>> For non-masked negation with NEON:
>> 
>>   movi    v16.4s, #0x0
>>   sub v17.4s, v16.4s, v17.4s       ==> neg v17.4s, v17.4s
>> 
>> and with SVE:
>> 
>>   mov z16.s, #0
>>   sub z18.s, z16.s, z17.s          ==> neg z16.s, p7/m, z16.s
>> 
>> For masked negation with NEON:
>> 
>>   movi    v17.4s, #0x1
>>   mvn v19.16b, v18.16b
>>   mov v20.16b, v16.16b             ==>  neg v18.4s, v17.4s
>>   bsl v20.16b, v19.16b, v18.16b         bsl v19.16b, v18.16b, v17.16b
>>   add v19.4s, v20.4s, v17.4s
>>   mov v18.16b, v16.16b
>>   bsl v18.16b, v19.16b, v20.16b
>> 
>> and with SVE:
>> 
>>   mov z16.s, #-1
>>   mov z17.s, #1                    ==> neg z16.s, p0/m, z16.s
>>   eor z18.s, p0/m, z18.s, z16.s
>>   add z18.s, p0/m, z18.s, z17.s
>> 
>> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed):
>> 
>> NEON:
>> Benchmark                Gain
>> Byte128Vector.NEG        1.029
>> Byte128Vector.NEGMasked  1.757
>> Short128Vector.NEG       1.041
>> Short128Vector.NEGMasked 1.659
>> Int128Vector.NEG         1.005
>> Int128Vector.NEGMasked   1.513
>> Long128Vector.NEG        1.003
>> Long128Vector.NEGMasked  1.878
>> 
>> SVE with 512-bits:
>> Benchmark                Gain
>> ByteMaxVector.NEG        1.10
>> ByteMaxVector.NEGMasked  1.165
>> ShortMaxVector.NEG       1.056
>> ShortMaxVector.NEGMasked 1.195
>> IntMaxVector.NEG         1.002
>> IntMaxVector.NEGMasked   1.239
>> LongMaxVector.NEG        1.031
>> LongMaxVector.NEGMasked  1.191
>> 
>> X86 (non AVX-512):
>> Benchmark                Gain
>> ByteMaxVector.NEGMasked  1.254
>> ShortMaxVector.NEGMasked 1.359
>> IntMaxVector.NEGMasked   1.431
>> LongMaxVector.NEGMasked  1.989
>> 
>> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896
>
> src/hotspot/share/opto/vectornode.cpp line 141:
> 
>> 139:       case T_BYTE:
>> 140:       case T_SHORT:
>> 141:       case T_INT: return Op_NegVI;
> 
> Why not add `Op_NegVB` for `BYTE` and `Op_NegVS` for `SHORT`?
> Is there any performance drop for byte/short negation operation if both of them are handled as a NegVI vector?

The compiler can get the real type info from `Op_NegVI` that can also handle the `BYTE ` and `SHORT ` basic type. I just don't want to add more new IRs which also need more match rules in the ad files.

> Is there any performance drop for byte/short negation operation if both of them are handled as a NegVI vector?

>From the benchmark results I showed in the commit message, I didn't see not any performance drop for byte/short.  Thanks!

> src/hotspot/share/opto/vectornode.cpp line 1635:
> 
>> 1633: }
>> 1634: 
>> 1635: Node* NegVINode::Ideal(PhaseGVN* phase, bool can_reshape) {
> 
> Much duplication in `NegVINode::Ideal` and `NegVLNode::Ideal`.
> Is it possible to refactor the implementation?

Yeah, maybe we need a superclass for `NegVINode` and `NegVLNode`. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From pli at openjdk.java.net  Mon Mar 21 06:07:54 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Mon, 21 Mar 2022 06:07:54 GMT
Subject: RFR: 8283408: Fix a C2 crash when filling arrays with unsafe
Message-ID: <B6NUr4Mz47vDH3FSwshS2R5U33FutQxB2s-jYRcQG80=.c3dee38b-a74f-42cd-9c01-381906b4a4ac@github.com>

We recently found a segmentation fault issue in C2 compiler with some
code that uses Java Unsafe API to initialize an array in a loop. It can
be reproduced by below code snippet compiled by C2 on AArch64. It's also
reproducible on x86 with an additional VM option "-XX:+OptimizeFill".

  byte[] arr = new byte[size];
  int offset = unsafe.arrayBaseOffset(byte[].class);
  for (int i = offset; i < offset + size; i++) {
    unsafe.putByte(arr, i, val);
  }

This issue is caused by a NULL pointer in a C2 loop optimization phase
called intrinsify_fill. In this phase, array filling loop patterns are
recognized and replaced by some intrinsics. But filling operations with
Unsafe API call are not handled very well. From C2 mid-end's point of
view, a difference between an Unsafe call and a normal array access like
`arr[i] = val` is element addressing. For normal array accesses, C2 uses
two AddP nodes for computing an element's address - one for adding array
header size and another for adding the element's relative offset from
the header. But Unsafe calls may have only one AddP node for adding an
absolute offset of an element from the array base. In current code, the
intrinsify_fill phase creates an AddP node but with NULL input for above
case and eventually causes a segmentation fault.

In this patch, we add a check to allow one AddP node in array filling
patterns to be optional. After this fix, the case above can be optimized
by intrinsify_fill as well. We know that the Unsafe call is rarely used
in Java application code and developers should use it at their own risk.
But we still propose this fix because C2 crashes even Unsafe is used in
a correct way.

Jtreg hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1
are tested and no issue is found. We also create a new jtreg case within
this patch.

-------------

Commit messages:
 - 8283408: Fix a C2 crash when filling arrays with unsafe

Changes: https://git.openjdk.java.net/jdk/pull/7884/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7884&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283408
  Stats: 70 lines in 2 files changed: 67 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7884.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7884/head:pull/7884

PR: https://git.openjdk.java.net/jdk/pull/7884

From duke at openjdk.java.net  Mon Mar 21 07:56:34 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Mon, 21 Mar 2022 07:56:34 GMT
Subject: RFR: 8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0)
 failed: Don't process dead nodes [v8]
In-Reply-To: <q-0LLkmJpuwa-5mDXsWRC1uAokfzZnNhhn4jNI_WSgQ=.7c3079cb-dfbd-4711-bd4b-f8288a9eb2f3@github.com>
References: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
 <Ac1Nb0W7yD645LlFOZT66w4oV9v8uxpJgZoDQQKVnwk=.f606f437-3e8b-41bd-9361-5d743a8750bb@github.com>
 <q-0LLkmJpuwa-5mDXsWRC1uAokfzZnNhhn4jNI_WSgQ=.7c3079cb-dfbd-4711-bd4b-f8288a9eb2f3@github.com>
Message-ID: <p1DD37vKy_q8rPWgfVCtZtNigtWEikITjgcCMbleoDw=.62a25001-d7e2-4be7-a44d-ecb071ae6585@github.com>

On Thu, 17 Mar 2022 11:47:01 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Emanuel Peter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove condition that is always true
>
> Looks good, thanks for making these changes.

Thanks @TobiHartmann and @chhagedorn for the help, suggestions for improvement and reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7728

From roland at openjdk.java.net  Mon Mar 21 08:20:34 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 21 Mar 2022 08:20:34 GMT
Subject: RFR: 8283408: Fix a C2 crash when filling arrays with unsafe
In-Reply-To: <B6NUr4Mz47vDH3FSwshS2R5U33FutQxB2s-jYRcQG80=.c3dee38b-a74f-42cd-9c01-381906b4a4ac@github.com>
References: <B6NUr4Mz47vDH3FSwshS2R5U33FutQxB2s-jYRcQG80=.c3dee38b-a74f-42cd-9c01-381906b4a4ac@github.com>
Message-ID: <Z-S5JGGu50FjtG7tszkhEAvryw-zmkGShrYng_fDrko=.b8c4d77a-f328-4832-ba2c-9a1b696d5d83@github.com>

On Mon, 21 Mar 2022 06:00:31 GMT, Pengfei Li <pli at openjdk.org> wrote:

> We recently found a segmentation fault issue in C2 compiler with some
> code that uses Java Unsafe API to initialize an array in a loop. It can
> be reproduced by below code snippet compiled by C2 on AArch64. It's also
> reproducible on x86 with an additional VM option "-XX:+OptimizeFill".
> 
>   byte[] arr = new byte[size];
>   int offset = unsafe.arrayBaseOffset(byte[].class);
>   for (int i = offset; i < offset + size; i++) {
>     unsafe.putByte(arr, i, val);
>   }
> 
> This issue is caused by a NULL pointer in a C2 loop optimization phase
> called intrinsify_fill. In this phase, array filling loop patterns are
> recognized and replaced by some intrinsics. But filling operations with
> Unsafe API call are not handled very well. From C2 mid-end's point of
> view, a difference between an Unsafe call and a normal array access like
> `arr[i] = val` is element addressing. For normal array accesses, C2 uses
> two AddP nodes for computing an element's address - one for adding array
> header size and another for adding the element's relative offset from
> the header. But Unsafe calls may have only one AddP node for adding an
> absolute offset of an element from the array base. In current code, the
> intrinsify_fill phase creates an AddP node but with NULL input for above
> case and eventually causes a segmentation fault.
> 
> In this patch, we add a check to allow one AddP node in array filling
> patterns to be optional. After this fix, the case above can be optimized
> by intrinsify_fill as well. We know that the Unsafe call is rarely used
> in Java application code and developers should use it at their own risk.
> But we still propose this fix because C2 crashes even Unsafe is used in
> a correct way.
> 
> Jtreg hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1
> are tested and no issue is found. We also create a new jtreg case within
> this patch.

Looks good to me.

src/hotspot/share/opto/loopTransform.cpp line 4046:

> 4044:   Node* from = new AddPNode(base, base, index);
> 4045:   _igvn.register_new_node_with_optimizer(from);
> 4046:   if (offset != NULL) {

A comment here that this happens with unsafe would be useful.

-------------

Marked as reviewed by roland (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7884

From serb at openjdk.java.net  Mon Mar 21 09:11:54 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 21 Mar 2022 09:11:54 GMT
Subject: RFR: 8283422: Create a new test for JDK-8254790
Message-ID: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>

The [JDK-8254790](https://bugs.openjdk.java.net/browse/JDK-8254790) initially was reported on macOS.
It was found by the "javax/xml/crypto/dsig/GenerationTests.java" test which for some reason worked fine on Linux/Windows most? of the time.

I tried to run that test on Linux/Windows many times on a few systems and it always pass. Also, I got the same result for the tier1...tier4 tests.

I have found that the easiest way to reproduce the crash is to pass the result of the string.indexOf to the str.charAt when the heap is big enough. The test below[1] trigger the crash 1000 time in a row on win/lin on systems I have tested.

I am not sure what is the best way to contribute to the test, should I create a stand-alone test like[1], or update an existing test as I did for the first version of this PR?

[1]:

package compiler.intrinsics.string;

import static jdk.test.lib.Asserts.assertTrue;

public final class TestStringIndexOfLargeHeap {
    static final int[] data = new int[Integer.MAX_VALUE / 2];
    public static void main(String[] args) throws Exception {
        test('a');
        test('\ubeef');
    }
    private static void test(char ch) {
        String str = ("0123456789" + ch).repeat(100);
        for (int i = 0; i < 1_000_000; ++i) {
            assertTrue(ch == str.charAt(str.indexOf(ch)));
        }
    }
}

-------------

Commit messages:
 - Add vm.bits == "64"
 - Initial version

Changes: https://git.openjdk.java.net/jdk/pull/7883/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7883&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283422
  Stats: 42 lines in 1 file changed: 40 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7883.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7883/head:pull/7883

PR: https://git.openjdk.java.net/jdk/pull/7883

From serb at openjdk.java.net  Mon Mar 21 09:11:56 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 21 Mar 2022 09:11:56 GMT
Subject: RFR: 8283422: Create a new test for JDK-8254790
In-Reply-To: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
References: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
Message-ID: <_jAgo5c4StFocVUexUOgjOdmgjeQZ-dKaYMHGaItJWY=.b8573367-1d71-4982-8c2e-1976794382ca@github.com>

On Mon, 21 Mar 2022 03:34:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The [JDK-8254790](https://bugs.openjdk.java.net/browse/JDK-8254790) initially was reported on macOS.
> It was found by the "javax/xml/crypto/dsig/GenerationTests.java" test which for some reason worked fine on Linux/Windows most? of the time.
> 
> I tried to run that test on Linux/Windows many times on a few systems and it always pass. Also, I got the same result for the tier1...tier4 tests.
> 
> I have found that the easiest way to reproduce the crash is to pass the result of the string.indexOf to the str.charAt when the heap is big enough. The test below[1] trigger the crash 1000 time in a row on win/lin on systems I have tested.
> 
> I am not sure what is the best way to contribute to the test, should I create a stand-alone test like[1], or update an existing test as I did for the first version of this PR?
> 
> [1]:
> 
> package compiler.intrinsics.string;
> 
> import static jdk.test.lib.Asserts.assertTrue;
> 
> public final class TestStringIndexOfLargeHeap {
>     static final int[] data = new int[Integer.MAX_VALUE / 2];
>     public static void main(String[] args) throws Exception {
>         test('a');
>         test('\ubeef');
>     }
>     private static void test(char ch) {
>         String str = ("0123456789" + ch).repeat(100);
>         for (int i = 0; i < 1_000_000; ++i) {
>             assertTrue(ch == str.charAt(str.indexOf(ch)));
>         }
>     }
> }

test/hotspot/jtreg/compiler/intrinsics/string/TestStringIntrinsics2.java line 47:

> 45: 
> 46: /*
> 47:  * @test id=LargeHeap

Is it useful to run all other tests in the TestStringIntrinsics2 using the large heap?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7883

From tschatzl at openjdk.java.net  Mon Mar 21 09:46:57 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 21 Mar 2022 09:46:57 GMT
Subject: RFR: 8283447: Remove unused LIR_Assembler::_bs
Message-ID: <CyWtbO7km0O3lyQvF9gwzQu58KD5QiWyWH03YEAm_AI=.ff0e52af-ebf0-4095-a181-0acd512fb169@github.com>

Hi,

  can I have reviews for this trivial removal of the unused `LIR_Assembler::_bs ` member?

Test: gha, local compilation

Thanks,
  Thomas

-------------

Commit messages:
 - Remove unused member

Changes: https://git.openjdk.java.net/jdk/pull/7887/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7887&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283447
  Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7887.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7887/head:pull/7887

PR: https://git.openjdk.java.net/jdk/pull/7887

From redestad at openjdk.java.net  Mon Mar 21 10:05:27 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 21 Mar 2022 10:05:27 GMT
Subject: RFR: 8283447: Remove unused LIR_Assembler::_bs
In-Reply-To: <CyWtbO7km0O3lyQvF9gwzQu58KD5QiWyWH03YEAm_AI=.ff0e52af-ebf0-4095-a181-0acd512fb169@github.com>
References: <CyWtbO7km0O3lyQvF9gwzQu58KD5QiWyWH03YEAm_AI=.ff0e52af-ebf0-4095-a181-0acd512fb169@github.com>
Message-ID: <QwLW0yU8ltaH5aFol-WZnRpED1QBbl2t9cX0PdeNat0=.c8a4de0d-0cb3-4101-aaa5-65d9d72f6ab2@github.com>

On Mon, 21 Mar 2022 09:39:42 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi,
> 
>   can I have reviews for this trivial removal of the unused `LIR_Assembler::_bs ` member?
> 
> Test: gha, local compilation
> 
> Thanks,
>   Thomas

Looks good and trivial, thanks!

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7887

From tschatzl at openjdk.java.net  Mon Mar 21 11:33:35 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 21 Mar 2022 11:33:35 GMT
Subject: RFR: 8283447: Remove unused LIR_Assembler::_bs
In-Reply-To: <QwLW0yU8ltaH5aFol-WZnRpED1QBbl2t9cX0PdeNat0=.c8a4de0d-0cb3-4101-aaa5-65d9d72f6ab2@github.com>
References: <CyWtbO7km0O3lyQvF9gwzQu58KD5QiWyWH03YEAm_AI=.ff0e52af-ebf0-4095-a181-0acd512fb169@github.com>
 <QwLW0yU8ltaH5aFol-WZnRpED1QBbl2t9cX0PdeNat0=.c8a4de0d-0cb3-4101-aaa5-65d9d72f6ab2@github.com>
Message-ID: <d9uG-9Z5FcnBhMjB22jQG0brRqaH8wf7Pwjj6R1XXdk=.13d55262-e521-4514-821a-e1d56d219cf9@github.com>

On Mon, 21 Mar 2022 10:01:58 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Hi,
>> 
>>   can I have reviews for this trivial removal of the unused `LIR_Assembler::_bs ` member?
>> 
>> Test: gha, local compilation
>> 
>> Thanks,
>>   Thomas
>
> Looks good and trivial, thanks!

Thanks @cl4es for your review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7887

From tschatzl at openjdk.java.net  Mon Mar 21 11:33:35 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Mon, 21 Mar 2022 11:33:35 GMT
Subject: Integrated: 8283447: Remove unused LIR_Assembler::_bs
In-Reply-To: <CyWtbO7km0O3lyQvF9gwzQu58KD5QiWyWH03YEAm_AI=.ff0e52af-ebf0-4095-a181-0acd512fb169@github.com>
References: <CyWtbO7km0O3lyQvF9gwzQu58KD5QiWyWH03YEAm_AI=.ff0e52af-ebf0-4095-a181-0acd512fb169@github.com>
Message-ID: <jZFGgGgpqVFfF1oqsCEMNHm9MvO1555hJcwo7hcUPQw=.1ef06a0b-cf46-4f7c-9426-3a1d456d5800@github.com>

On Mon, 21 Mar 2022 09:39:42 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi,
> 
>   can I have reviews for this trivial removal of the unused `LIR_Assembler::_bs ` member?
> 
> Test: gha, local compilation
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: b617f1db
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b617f1db4ec5d54b1ea541fb885e296da928f166
Stats:     6 lines in 2 files changed: 0 ins; 4 del; 2 mod

8283447: Remove unused LIR_Assembler::_bs

Reviewed-by: redestad

-------------

PR: https://git.openjdk.java.net/jdk/pull/7887

From roland at openjdk.java.net  Mon Mar 21 12:47:27 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 21 Mar 2022 12:47:27 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con
In-Reply-To: <MRdZSFcQFXaTh1k3x0y_grTFweY7ClildBdyQ7Mwi7U=.8efcf85b-73e4-45fc-be1b-d9591ad7078c@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
 <MRdZSFcQFXaTh1k3x0y_grTFweY7ClildBdyQ7Mwi7U=.8efcf85b-73e4-45fc-be1b-d9591ad7078c@github.com>
Message-ID: <UvPuQRUuZPgvopkXaAF9ZiQNhEQwyAX1fkOfp6ROnWw=.ed1d9518-a9f6-402a-a8a1-92a5b49fac30@github.com>

On Sat, 12 Mar 2022 07:44:09 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> I think I have a better idea for this. During idealisation, we will transform every subtraction into an addition with the negation of the second operand, pushing the negation down the computation graph.

One issue with such an approach is that it's then required to update all code that pattern match an expression with SubX node to now expect an (AddX (NegX ..) ..). PhaseIdealLoop::is_scaled_iv_plus_offset() for instance. And maybe there are not that many instances of code that require updating, but it's still needed to proceed carefully and double check, possibly update some code, write tests that verify the change does what's intended etc. So what appears relatively simple is going to be more work than expected and the risk associated with the change is higher than one might think. I doubt that's worth it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7795

From duke at openjdk.java.net  Mon Mar 21 13:48:38 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 21 Mar 2022 13:48:38 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con
In-Reply-To: <UvPuQRUuZPgvopkXaAF9ZiQNhEQwyAX1fkOfp6ROnWw=.ed1d9518-a9f6-402a-a8a1-92a5b49fac30@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
 <MRdZSFcQFXaTh1k3x0y_grTFweY7ClildBdyQ7Mwi7U=.8efcf85b-73e4-45fc-be1b-d9591ad7078c@github.com>
 <UvPuQRUuZPgvopkXaAF9ZiQNhEQwyAX1fkOfp6ROnWw=.ed1d9518-a9f6-402a-a8a1-92a5b49fac30@github.com>
Message-ID: <nSNID2fccf6oSn_NqlFBTLmCRIX5IuQOcjyjxJeXy58=.99c1040e-d701-4894-ab32-360bac74f4f4@github.com>

On Mon, 21 Mar 2022 12:43:48 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> I think I have a better idea for this. During idealisation, we will transform every subtraction into an addition with the negation of the second operand, pushing the negation down the computation graph. This will simplify numerous rules we have with subtractions. Addition presents nice commutative and associative properties so the graph transformation during idealisation with be much easier. Before matching, we may have another strength reduction phase which will push the negations up the computation graph, transform the computations to be as compact as possible.
>> 
>> This problem seems a lot like the problem we face in #7700 when eagerly strength reducing operations hurt our ability to perform other transformations by complicating the elements inside the graph. I believe this solution would simplify our arithmetic transformations and allow better numeric calculations. Similar to what has been discussed in #7395 , a more general solution would be much more valuable than trying to match every possible combinations.
>> 
>> Thank you very much.
>
>> I think I have a better idea for this. During idealisation, we will transform every subtraction into an addition with the negation of the second operand, pushing the negation down the computation graph.
> 
> One issue with such an approach is that it's then required to update all code that pattern match an expression with SubX node to now expect an (AddX (NegX ..) ..). PhaseIdealLoop::is_scaled_iv_plus_offset() for instance. And maybe there are not that many instances of code that require updating, but it's still needed to proceed carefully and double check, possibly update some code, write tests that verify the change does what's intended etc. So what appears relatively simple is going to be more work than expected and the risk associated with the change is higher than one might think. I doubt that's worth it.

@rwestrel  Thanks a lot for your information, it seems that the idea would turn out to be problematic with little applicable benefits then.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7795

From duke at openjdk.java.net  Mon Mar 21 14:09:33 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 21 Mar 2022 14:09:33 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con
In-Reply-To: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
Message-ID: <AUnmp5kb7fmEjEqjhnF7CUVUrDxzoAODFWV5o7QYCX4=.263d63a6-6a33-4ab3-8c9e-b37f9f40972a@github.com>

On Fri, 11 Mar 2022 23:40:19 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

> Hello,
> 
> `x + (con - y)  -> (x - y) + con` is a widely seen pattern; however it is missing in current implementation, which prevents some obvious constant folding from happening, such as `x + (1 - y) + 2` will be not optimized at all, rather than into `x - y + 3`.
> 
> This pull request adds this transformation.

src/hotspot/share/opto/addnode.cpp line 317:

> 315:   }
> 316: 
> 317:   // Convert (con - y) + x into "(x - y) + con"

This is the generalisation of the above transformations, you could consider removing them.

test/hotspot/jtreg/compiler/c2/irTests/TestIRAddIdealXPlus_ConMinusY_.java line 36:

> 34:  * @run driver compiler.c2.irTests.TestIRAddIdealXPlus_ConMinusY_
> 35:  */
> 36: public class TestIRAddIdealXPlus_ConMinusY_ {

Could you consider putting this in [SubINodeIdealizationTests](https://github.com/openjdk/jdk/blob/d24b6754a216c6d8b4d2fd1154dcf62d9e2c6c46/test/hotspot/jtreg/compiler/c2/irTests/SubINodeIdealizationTests.java) instead. Also I think it would be preferrable to have another PR to move the likes of [TestSpecialCasesOf_AMinusB_Plus_CMinusD_InAddIdeal](https://github.com/openjdk/jdk/blob/d24b6754a216c6d8b4d2fd1154dcf62d9e2c6c46/test/hotspot/jtreg/compiler/c2/irTests/TestSpecialCasesOf_AMinusB_Plus_CMinusD_InAddIdeal.java) to the corresponding group. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7795

From rbackman at openjdk.java.net  Mon Mar 21 14:54:02 2022
From: rbackman at openjdk.java.net (Rickard =?UTF-8?B?QsOkY2ttYW4=?=)
Date: Mon, 21 Mar 2022 14:54:02 GMT
Subject: RFR: 8281222: ciTypeFlow::profiled_count fails
 "assert(0 <= i && i < _len) failed: illegal index"
Message-ID: <TsG0o1zrQRvR93tubXro8EBe2KOvuEmEHVsSci5iiek=.05c25bab-4a8e-4141-827c-5d9cde29cb06@github.com>

This failed in Project Loom with a specific version of TestNG. 

The root cause is that the block that is considered tail doesn't have any _successors, but a couple of _exception "successors".

-------------

Commit messages:
 - 8281222: ciTypeFlow::profiled_count fails "assert(0 <= i && i < _len) failed: illegal index"

Changes: https://git.openjdk.java.net/jdk/pull/7892/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7892&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281222
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7892.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7892/head:pull/7892

PR: https://git.openjdk.java.net/jdk/pull/7892

From roland at openjdk.java.net  Mon Mar 21 15:12:32 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 21 Mar 2022 15:12:32 GMT
Subject: RFR: 8281222: ciTypeFlow::profiled_count fails
 "assert(0 <= i && i < _len) failed: illegal index"
In-Reply-To: <TsG0o1zrQRvR93tubXro8EBe2KOvuEmEHVsSci5iiek=.05c25bab-4a8e-4141-827c-5d9cde29cb06@github.com>
References: <TsG0o1zrQRvR93tubXro8EBe2KOvuEmEHVsSci5iiek=.05c25bab-4a8e-4141-827c-5d9cde29cb06@github.com>
Message-ID: <cx-Y1dFRqYBShCvokUMvAy195erPLgA4FsUWGf6TmHQ=.b6576322-12a1-4a18-b776-fb0e26c8f356@github.com>

On Mon, 21 Mar 2022 14:45:40 GMT, Rickard B?ckman <rbackman at openjdk.org> wrote:

> This failed in Project Loom with a specific version of TestNG. 
> 
> The root cause is that the block that is considered tail doesn't have any _successors, but a couple of _exception "successors".

Looks good to me. A test case would be nice.

-------------

Marked as reviewed by roland (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7892

From duke at openjdk.java.net  Mon Mar 21 17:59:44 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Mon, 21 Mar 2022 17:59:44 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v15]
In-Reply-To: <ClrjytnyyLKM7-F3AJyWRsmfy5uQBmt6yia4yq8kk3g=.be46074b-0bf8-4b97-a7d4-fc2559b60d64@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <Iv1sKvCahNhEMUynJAFeJBvI_i9Llg1IFGuMufxHKEU=.31394133-6f11-4cdd-92a3-2d387f948936@github.com>
 <DumsZCzq7RGmmWNBnTSHpNL91DbZ93sib12cl-0dhKs=.620444b6-4692-4614-a8cd-132f0d335115@github.com>
 <ClrjytnyyLKM7-F3AJyWRsmfy5uQBmt6yia4yq8kk3g=.be46074b-0bf8-4b97-a7d4-fc2559b60d64@github.com>
Message-ID: <cJpJyfwxcnklfgS3sHU-kbmVu8RUakQLVnCx7dhcGVw=.3145b02e-bc20-40c7-9170-d5dda1137e0b@github.com>

On Sun, 13 Mar 2022 04:27:44 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4178:
>> 
>>> 4176:   movl(scratch, 1056964608);
>>> 4177:   movq(xtmp1, scratch);
>>> 4178:   vbroadcastss(xtmp1, xtmp1, vec_enc);
>> 
>> You could put the constant in the constant table and use `vbroadcastss` here also.
>> 
>> Thank you very much.
>
> constant and register to register moves are never issued to execution ports,  rematerializing value rather than reading from memory will give better performance.

I have come across this a little bit. While `movl r, i` may not consume execution ports, `movq x, r` and `vbroadcastss x, x` surely do. This leads to 3 retired and 2 executed uops. Furthermore, both `movq x, r` and `vbroadcastss x, x` can only run on port 5, limit the throughput of the operation. On the contrary, a `vbroadcastss x, m` only results in 1 retired and 1 executed uop, reducing pressure on the decoder and the backend. A `vbroadcastss x, m` can run on both port 2 and port 3, offering a much better throughput. Latency is not much of a concern in this circumstance since the operation does not have any input dependency.

> register to register moves are never issued to execution ports

I believe you misremembered this part, a register to register move is only elided when the registers are of the same kind, `vmovq x, r` would result in 1 uop being executed on port 5.

What do you think? Thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From jbhateja at openjdk.java.net  Mon Mar 21 18:28:34 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Mon, 21 Mar 2022 18:28:34 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v15]
In-Reply-To: <cJpJyfwxcnklfgS3sHU-kbmVu8RUakQLVnCx7dhcGVw=.3145b02e-bc20-40c7-9170-d5dda1137e0b@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <Iv1sKvCahNhEMUynJAFeJBvI_i9Llg1IFGuMufxHKEU=.31394133-6f11-4cdd-92a3-2d387f948936@github.com>
 <DumsZCzq7RGmmWNBnTSHpNL91DbZ93sib12cl-0dhKs=.620444b6-4692-4614-a8cd-132f0d335115@github.com>
 <ClrjytnyyLKM7-F3AJyWRsmfy5uQBmt6yia4yq8kk3g=.be46074b-0bf8-4b97-a7d4-fc2559b60d64@github.com>
 <cJpJyfwxcnklfgS3sHU-kbmVu8RUakQLVnCx7dhcGVw=.3145b02e-bc20-40c7-9170-d5dda1137e0b@github.com>
Message-ID: <SkZZr4hNLRh6HIonJ0MdzH2Lz0awaX3EMC2Di1HM_2U=.926099eb-1638-41df-b520-ba350e81bbdc@github.com>

On Mon, 21 Mar 2022 17:56:22 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> constant and register to register moves are never issued to execution ports,  rematerializing value rather than reading from memory will give better performance.
>
> I have come across this a little bit. While `movl r, i` may not consume execution ports, `movq x, r` and `vbroadcastss x, x` surely do. This leads to 3 retired and 2 executed uops. Furthermore, both `movq x, r` and `vbroadcastss x, x` can only run on port 5, limit the throughput of the operation. On the contrary, a `vbroadcastss x, m` only results in 1 retired and 1 executed uop, reducing pressure on the decoder and the backend. A `vbroadcastss x, m` can run on both port 2 and port 3, offering a much better throughput. Latency is not much of a concern in this circumstance since the operation does not have any input dependency.
> 
>> register to register moves are never issued to execution ports
> 
> I believe you misremembered this part, a register to register move is only elided when the registers are of the same kind, `vmovq x, r` would result in 1 uop being executed on port 5.
> 
> What do you think? Thank you very much.

A read from constant table will incur minimum of L1I access penalty to access code blob or at worst even more if data is not present in first level cache. Change was done for replace vpbroadcastd with vbroadcastss because of two reasons.
1) vbroadcastss works at AVX=1 level where as vpbroadcastd need AVX2 feature. 
2) We can avoid extra cycle penalty due to two domain switchovers (FP -> INT and then from INT-> FP).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From duke at openjdk.java.net  Mon Mar 21 20:58:07 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Mon, 21 Mar 2022 20:58:07 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con [v2]
In-Reply-To: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
Message-ID: <7AeOY6yGuJbdSUf_XIV4nCwkfxrr6rlrfwyuD7WS-Wo=.35d141a8-2577-4417-b0aa-30429e8c5946@github.com>

> Hello,
> 
> `x + (con - y)  -> (x - y) + con` is a widely seen pattern; however it is missing in current implementation, which prevents some obvious constant folding from happening, such as `x + (1 - y) + 2` will be not optimized at all, rather than into `x - y + 3`.
> 
> This pull request adds this transformation.

Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:

  comment out "x+(0-y)" -> "(x-y)" and "(0-y)+x" -> "(x-y)" because they
  are covered already.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7795/files
  - new: https://git.openjdk.java.net/jdk/pull/7795/files/d24b6754..7c899d8a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7795&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7795&range=00-01

  Stats: 62 lines in 2 files changed: 52 ins; 10 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7795/head:pull/7795

PR: https://git.openjdk.java.net/jdk/pull/7795

From duke at openjdk.java.net  Mon Mar 21 22:08:09 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Mon, 21 Mar 2022 22:08:09 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con [v3]
In-Reply-To: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
Message-ID: <s210E9mQQT0SenSoO0rXeioNZY28eFTs4D18jEjfLLE=.bbeecb0f-0a32-4cda-ae40-8314a02d7941@github.com>

> Hello,
> 
> `x + (con - y)  -> (x - y) + con` is a widely seen pattern; however it is missing in current implementation, which prevents some obvious constant folding from happening, such as `x + (1 - y) + 2` will be not optimized at all, rather than into `x - y + 3`.
> 
> This pull request adds this transformation.

Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:

  move tests to existing test classes.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7795/files
  - new: https://git.openjdk.java.net/jdk/pull/7795/files/7c899d8a..83c2ce8c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7795&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7795&range=01-02

  Stats: 364 lines in 3 files changed: 96 ins; 246 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7795/head:pull/7795

PR: https://git.openjdk.java.net/jdk/pull/7795

From duke at openjdk.java.net  Mon Mar 21 23:25:21 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Mon, 21 Mar 2022 23:25:21 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con [v3]
In-Reply-To: <AUnmp5kb7fmEjEqjhnF7CUVUrDxzoAODFWV5o7QYCX4=.263d63a6-6a33-4ab3-8c9e-b37f9f40972a@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
 <AUnmp5kb7fmEjEqjhnF7CUVUrDxzoAODFWV5o7QYCX4=.263d63a6-6a33-4ab3-8c9e-b37f9f40972a@github.com>
Message-ID: <AFeY3tcNUolqqjka0Y0fp81qwjlLHz4Wn1YeTxi3E6I=.77ab3e81-4ab7-48f4-b231-23d1514b22da@github.com>

On Mon, 21 Mar 2022 14:06:04 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move tests to existing test classes.
>
> test/hotspot/jtreg/compiler/c2/irTests/TestIRAddIdealXPlus_ConMinusY_.java line 36:
> 
>> 34:  * @run driver compiler.c2.irTests.TestIRAddIdealXPlus_ConMinusY_
>> 35:  */
>> 36: public class TestIRAddIdealXPlus_ConMinusY_ {
> 
> Could you consider putting this in [SubINodeIdealizationTests](https://github.com/openjdk/jdk/blob/d24b6754a216c6d8b4d2fd1154dcf62d9e2c6c46/test/hotspot/jtreg/compiler/c2/irTests/SubINodeIdealizationTests.java) instead. Also I think it would be preferrable to have another PR to move the likes of [TestSpecialCasesOf_AMinusB_Plus_CMinusD_InAddIdeal](https://github.com/openjdk/jdk/blob/d24b6754a216c6d8b4d2fd1154dcf62d9e2c6c46/test/hotspot/jtreg/compiler/c2/irTests/TestSpecialCasesOf_AMinusB_Plus_CMinusD_InAddIdeal.java) to the corresponding group. Thanks.

Done. Thanks. I created a new PR #7897 for moving [TestSpecialCasesOf_AMinusB_Plus_CMinusD_InAddIdeal](https://github.com/openjdk/jdk/blob/d24b6754a216c6d8b4d2fd1154dcf62d9e2c6c46/test/hotspot/jtreg/compiler/c2/irTests/TestSpecialCasesOf_AMinusB_Plus_CMinusD_InAddIdeal.java).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7795

From duke at openjdk.java.net  Tue Mar 22 01:58:40 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 22 Mar 2022 01:58:40 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v15]
In-Reply-To: <SkZZr4hNLRh6HIonJ0MdzH2Lz0awaX3EMC2Di1HM_2U=.926099eb-1638-41df-b520-ba350e81bbdc@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <Iv1sKvCahNhEMUynJAFeJBvI_i9Llg1IFGuMufxHKEU=.31394133-6f11-4cdd-92a3-2d387f948936@github.com>
 <DumsZCzq7RGmmWNBnTSHpNL91DbZ93sib12cl-0dhKs=.620444b6-4692-4614-a8cd-132f0d335115@github.com>
 <ClrjytnyyLKM7-F3AJyWRsmfy5uQBmt6yia4yq8kk3g=.be46074b-0bf8-4b97-a7d4-fc2559b60d64@github.com>
 <cJpJyfwxcnklfgS3sHU-kbmVu8RUakQLVnCx7dhcGVw=.3145b02e-bc20-40c7-9170-d5dda1137e0b@github.com>
 <SkZZr4hNLRh6HIonJ0MdzH2Lz0awaX3EMC2Di1HM_2U=.926099eb-1638-41df-b520-ba350e81bbdc@github.com>
Message-ID: <M82OI4qS_kxpwrNv2BB3QDBO38vh-VhSz40cQ9zuUqM=.0d99f9a3-0934-405a-88a5-e1f42107fb2e@github.com>

On Mon, 21 Mar 2022 18:25:36 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> A read from constant table will incur minimum of L1I access penalty to access code blob or at worst even more if data is not present in first level cache

But your approach comes at a cost of frontend bandwidth and port contention, which imo are more important than latency in this case since a constant load does not prolong dependency chains. A load has very good throughput so it is often performant unless the load depends on its input (the memory location or the registers used for address calculation). Thanks

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From jbhateja at openjdk.java.net  Tue Mar 22 02:55:32 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Tue, 22 Mar 2022 02:55:32 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v15]
In-Reply-To: <M82OI4qS_kxpwrNv2BB3QDBO38vh-VhSz40cQ9zuUqM=.0d99f9a3-0934-405a-88a5-e1f42107fb2e@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <Iv1sKvCahNhEMUynJAFeJBvI_i9Llg1IFGuMufxHKEU=.31394133-6f11-4cdd-92a3-2d387f948936@github.com>
 <DumsZCzq7RGmmWNBnTSHpNL91DbZ93sib12cl-0dhKs=.620444b6-4692-4614-a8cd-132f0d335115@github.com>
 <ClrjytnyyLKM7-F3AJyWRsmfy5uQBmt6yia4yq8kk3g=.be46074b-0bf8-4b97-a7d4-fc2559b60d64@github.com>
 <cJpJyfwxcnklfgS3sHU-kbmVu8RUakQLVnCx7dhcGVw=.3145b02e-bc20-40c7-9170-d5dda1137e0b@github.com>
 <SkZZr4hNLRh6HIonJ0MdzH2Lz0awaX3EMC2Di1HM_2U=.926099eb-1638-41df-b520-ba350e81bbdc@github.com>
 <M82OI4qS_kxpwrNv2BB3QDBO38vh-VhSz40cQ9zuUqM=.0d99f9a3-0934-405a-88a5-e1f42107fb2e@github.com>
Message-ID: <m4ks0X0l0qe6s76a27yqao9N9lDocEZAUZRPB8Di4co=.aa9843f5-331e-45eb-8c4c-f87ef256e269@github.com>

On Tue, 22 Mar 2022 01:55:38 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> A read from constant table will incur minimum of L1I access penalty to access code blob or at worst even more if data is not present in first level cache. Change was done for replace vpbroadcastd with vbroadcastss because of two reasons.
>> 1) vbroadcastss works at AVX=1 level where as vpbroadcastd need AVX2 feature. 
>> 2) We can avoid extra cycle penalty due to two domain switchovers (FP -> INT and then from INT-> FP).
>
>> A read from constant table will incur minimum of L1I access penalty to access code blob or at worst even more if data is not present in first level cache
> 
> But your approach comes at a cost of frontend bandwidth and port contention, which imo are more important than latency in this case since a constant load does not prolong dependency chains. A load has very good throughput so it is often performant unless the load depends on its input (the memory location or the registers used for address calculation). Thanks

Thanks for going into details, multicycle memory load will also defer dispatch of dependent instructions to execution port, port congestion becomes bottleneck when multiple ready instructions cannot be issued due to lack of execution resource or throughput constraints imposed by instruction,  but a single cycle dependency chain may still win over  latency due to pending memory  operations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From duke at openjdk.java.net  Tue Mar 22 03:17:32 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Tue, 22 Mar 2022 03:17:32 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v15]
In-Reply-To: <m4ks0X0l0qe6s76a27yqao9N9lDocEZAUZRPB8Di4co=.aa9843f5-331e-45eb-8c4c-f87ef256e269@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <Iv1sKvCahNhEMUynJAFeJBvI_i9Llg1IFGuMufxHKEU=.31394133-6f11-4cdd-92a3-2d387f948936@github.com>
 <DumsZCzq7RGmmWNBnTSHpNL91DbZ93sib12cl-0dhKs=.620444b6-4692-4614-a8cd-132f0d335115@github.com>
 <ClrjytnyyLKM7-F3AJyWRsmfy5uQBmt6yia4yq8kk3g=.be46074b-0bf8-4b97-a7d4-fc2559b60d64@github.com>
 <cJpJyfwxcnklfgS3sHU-kbmVu8RUakQLVnCx7dhcGVw=.3145b02e-bc20-40c7-9170-d5dda1137e0b@github.com>
 <SkZZr4hNLRh6HIonJ0MdzH2Lz0awaX3EMC2Di1HM_2U=.926099eb-1638-41df-b520-ba350e81bbdc@github.com>
 <M82OI4qS_kxpwrNv2BB3QDBO38vh-VhSz40cQ9zuUqM=.0d99f9a3-0934-405a-88a5-e1f42107fb2e@github.com>
 <m4ks0X0l0qe6s76a27yqao9N9lDocEZAUZRPB8Di4co=.aa9843f5-331e-45eb-8c4c-f87ef256e269@github.com>
Message-ID: <HNhtyI_wiWmqo6AKKlccG5GBVSyOlAxrYaEocHpQ52Y=.c8ef434b-0b2e-4260-8e71-64bea9259b78@github.com>

On Tue, 22 Mar 2022 02:52:07 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> A read from constant table will incur minimum of L1I access penalty to access code blob or at worst even more if data is not present in first level cache
>> 
>> But your approach comes at a cost of frontend bandwidth and port contention, which imo are more important than latency in this case since a constant load does not prolong dependency chains. A load has very good throughput so it is often performant unless the load depends on its input (the memory location or the registers used for address calculation). Thanks
>
> Thanks for going into details, multicycle memory load will also defer dispatch of dependent instructions to execution port, port congestion becomes bottleneck when multiple ready instructions cannot be issued due to lack of execution resource or throughput constraints imposed by instruction,  but a single cycle dependency chain may still win over  latency due to pending memory  operations.

I think I get it now, thanks a lot for your detailed explanation.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From pli at openjdk.java.net  Tue Mar 22 03:43:08 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Tue, 22 Mar 2022 03:43:08 GMT
Subject: RFR: 8283408: Fix a C2 crash when filling arrays with unsafe [v2]
In-Reply-To: <B6NUr4Mz47vDH3FSwshS2R5U33FutQxB2s-jYRcQG80=.c3dee38b-a74f-42cd-9c01-381906b4a4ac@github.com>
References: <B6NUr4Mz47vDH3FSwshS2R5U33FutQxB2s-jYRcQG80=.c3dee38b-a74f-42cd-9c01-381906b4a4ac@github.com>
Message-ID: <tF8Dp608ZvVeZvjz5QMixxOIf-WlDJc4tdC26dNO1ZM=.5e8eed61-58b3-48be-a6d5-bda95d702b04@github.com>

> We recently found a segmentation fault issue in C2 compiler with some
> code that uses Java Unsafe API to initialize an array in a loop. It can
> be reproduced by below code snippet compiled by C2 on AArch64. It's also
> reproducible on x86 with an additional VM option "-XX:+OptimizeFill".
> 
>   byte[] arr = new byte[size];
>   int offset = unsafe.arrayBaseOffset(byte[].class);
>   for (int i = offset; i < offset + size; i++) {
>     unsafe.putByte(arr, i, val);
>   }
> 
> This issue is caused by a NULL pointer in a C2 loop optimization phase
> called intrinsify_fill. In this phase, array filling loop patterns are
> recognized and replaced by some intrinsics. But filling operations with
> Unsafe API call are not handled very well. From C2 mid-end's point of
> view, a difference between an Unsafe call and a normal array access like
> `arr[i] = val` is element addressing. For normal array accesses, C2 uses
> two AddP nodes for computing an element's address - one for adding array
> header size and another for adding the element's relative offset from
> the header. But Unsafe calls may have only one AddP node for adding an
> absolute offset of an element from the array base. In current code, the
> intrinsify_fill phase creates an AddP node but with NULL input for above
> case and eventually causes a segmentation fault.
> 
> In this patch, we add a check to allow one AddP node in array filling
> patterns to be optional. After this fix, the case above can be optimized
> by intrinsify_fill as well. We know that the Unsafe call is rarely used
> in Java application code and developers should use it at their own risk.
> But we still propose this fix because C2 crashes even Unsafe is used in
> a correct way.
> 
> Jtreg hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1
> are tested and no issue is found. We also create a new jtreg case within
> this patch.

Pengfei Li has updated the pull request incrementally with one additional commit since the last revision:

  Add a few comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7884/files
  - new: https://git.openjdk.java.net/jdk/pull/7884/files/040da679..16ebef57

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7884&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7884&range=00-01

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7884.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7884/head:pull/7884

PR: https://git.openjdk.java.net/jdk/pull/7884

From pli at openjdk.java.net  Tue Mar 22 03:43:10 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Tue, 22 Mar 2022 03:43:10 GMT
Subject: RFR: 8283408: Fix a C2 crash when filling arrays with unsafe [v2]
In-Reply-To: <Z-S5JGGu50FjtG7tszkhEAvryw-zmkGShrYng_fDrko=.b8c4d77a-f328-4832-ba2c-9a1b696d5d83@github.com>
References: <B6NUr4Mz47vDH3FSwshS2R5U33FutQxB2s-jYRcQG80=.c3dee38b-a74f-42cd-9c01-381906b4a4ac@github.com>
 <Z-S5JGGu50FjtG7tszkhEAvryw-zmkGShrYng_fDrko=.b8c4d77a-f328-4832-ba2c-9a1b696d5d83@github.com>
Message-ID: <wkR1hPUBBGyNT4yV0jOAgni6o5Xt8uLsAacNTK_FVF0=.8bc943ef-e0d6-4ee2-9d81-eaef54e7c1b7@github.com>

On Mon, 21 Mar 2022 08:17:30 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Pengfei Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a few comments
>
> src/hotspot/share/opto/loopTransform.cpp line 4046:
> 
>> 4044:   Node* from = new AddPNode(base, base, index);
>> 4045:   _igvn.register_new_node_with_optimizer(from);
>> 4046:   if (offset != NULL) {
> 
> A comment here that this happens with unsafe would be useful.

Comments are added. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7884

From pli at openjdk.java.net  Tue Mar 22 05:59:29 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Tue, 22 Mar 2022 05:59:29 GMT
Subject: RFR: 8283408: Fix a C2 crash when filling arrays with unsafe [v2]
In-Reply-To: <Z-S5JGGu50FjtG7tszkhEAvryw-zmkGShrYng_fDrko=.b8c4d77a-f328-4832-ba2c-9a1b696d5d83@github.com>
References: <B6NUr4Mz47vDH3FSwshS2R5U33FutQxB2s-jYRcQG80=.c3dee38b-a74f-42cd-9c01-381906b4a4ac@github.com>
 <Z-S5JGGu50FjtG7tszkhEAvryw-zmkGShrYng_fDrko=.b8c4d77a-f328-4832-ba2c-9a1b696d5d83@github.com>
Message-ID: <-npAbSMATD5HZY51douJmTxuMp174fIjbwWchqx1fxM=.16823e5c-2153-4a62-b805-53ffd0a8399e@github.com>

On Mon, 21 Mar 2022 08:17:42 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Looks good to me.

Thanks Roland. Can I  have another review?

The failure with my latest commit looks like some build system issue. My first patch passes all tests.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7884

From thartmann at openjdk.java.net  Tue Mar 22 07:41:37 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 22 Mar 2022 07:41:37 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v18]
In-Reply-To: <KyoBFGrYKdHoGAWeNhM54eGA-AtOToazLOFg-zrnI9s=.a23c0299-ff24-44fb-aa13-e960d7b1f942@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <KyoBFGrYKdHoGAWeNhM54eGA-AtOToazLOFg-zrnI9s=.a23c0299-ff24-44fb-aa13-e960d7b1f942@github.com>
Message-ID: <kv5OgAFJmrED7N0o758SDJktKRU0JChXmw9bpKRww38=.b6c92331-8a7a-465a-b6a5-36dbc8201610@github.com>

On Fri, 18 Mar 2022 20:19:08 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
>> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - 8279508: Using an explicit scratch register since rscratch1 is bound to r10 and its usage is transparent to compiler.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
>  - 8279508: Windows build failure fix.
>  - 8279508: Styling comments resolved.
>  - 8279508: Creating separate test for round double under feature check.
>  - 8279508: Reducing the invocation count and compile thresholds for RoundTests.java.
>  - 8279508: Review comments resolution.
>  - 8279508: Preventing domain switch-over penalty for Math.round(float) and constraining unrolling to prevent code bloating.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
>  - 8279508: Removing +LogCompilation flag.
>  - ... and 12 more: https://git.openjdk.java.net/jdk/compare/ff0b0927...c17440cf

Sure, I'll re-run testing and report back.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From thartmann at openjdk.java.net  Tue Mar 22 07:48:44 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 22 Mar 2022 07:48:44 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v12]
In-Reply-To: <ipzQF1uR_cuz1f7hI8RZ1HhokXaf6VGYGhx58h2VVQQ=.78863db8-b67f-4835-af92-e32c1a524353@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <ipzQF1uR_cuz1f7hI8RZ1HhokXaf6VGYGhx58h2VVQQ=.78863db8-b67f-4835-af92-e32c1a524353@github.com>
Message-ID: <yPFJwWs-EDGid_BVFuma5CHK7kC5cVx5tlvN_GMyjgA=.89e85fff-8941-4cc1-824c-cd163c9182d7@github.com>

On Sat, 12 Mar 2022 04:52:41 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into leaIns
>  - reviews
>  - remove unreached rules
>  - remove 0x67 prefix
>  - address reviews
>  - remove irrelevent changes
>  - reviews
>  - address reviews
>  - add benchmark
>  - add predicate
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/90759a67...e0fd81f6

Observed some intermittent issues that are probably unrelated. Will re-run testing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From thartmann at openjdk.java.net  Tue Mar 22 08:02:51 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 22 Mar 2022 08:02:51 GMT
Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v6]
In-Reply-To: <4f4q-PLj6psH50mRQCVLAX8bMjzF4XWzAornt_t4PNE=.4331b19d-469b-4e0d-8a1f-d1eeb5aaf9ed@github.com>
References: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
 <4f4q-PLj6psH50mRQCVLAX8bMjzF4XWzAornt_t4PNE=.4331b19d-469b-4e0d-8a1f-d1eeb5aaf9ed@github.com>
Message-ID: <b0a251YxVZkM_k6T3PuWQdkEAqo81p0-KUJa4yhwF5E=.e8c3b845-6203-420d-a3b5-a089d7f18b6d@github.com>

On Mon, 14 Mar 2022 06:13:30 GMT, Pengfei Li <pli at openjdk.org> wrote:

>> ### Background
>> 
>> Post loop vectorization is a C2 compiler optimization in an experimental
>> VM feature called PostLoopMultiversioning. It transforms the range-check
>> eliminated post loop to a 1-iteration vectorized loop with vector mask.
>> This optimization was contributed by Intel in 2016 to support x86 AVX512
>> masked vector instructions. However, it was disabled soon after an issue
>> was found. Due to insufficient maintenance in these years, multiple bugs
>> have been accumulated inside. But we (Arm) still think this is a useful
>> framework for vector mask support in C2 auto-vectorized loops, for both
>> x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
>> post loop vectorization.
>> 
>> ### Changes in this patch
>> 
>> This patch reworks post loop vectorization. The most significant change
>> is removing vector mask support in C2 x86 backend and re-implementing
>> it in the mid-end. With this, we can re-enable post loop vectorization
>> for platforms other than x86.
>> 
>> Previous implementation hard-codes x86 k1 register as a reserved AVX512
>> opmask register and defines two routines (setvectmask/restorevectmask)
>> to set and restore the value of k1. But after [JDK-8211251](https://bugs.openjdk.java.net/browse/JDK-8211251) which encodes
>> AVX512 instructions as unmasked by default, generated vector masks are
>> no longer used in AVX512 vector instructions. To fix incorrect codegen
>> and add vector mask support for more platforms, we turn to add a vector
>> mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
>> to generate a mask and replace all Load/Store nodes in the post loop
>> into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
>> IR form is exactly the same to those which are used in VectorAPI mask
>> support. For now, we only add mask inputs for Load/Store nodes because
>> we don't have reduction operations supported in post loop vectorization.
>> After this change, the x86 k1 register is no longer reserved and can be
>> allocated when PostLoopMultiversioning is enabled.
>> 
>> Besides this change, we have fixed a compiler crash and five incorrect
>> result issues with post loop vectorization.
>> 
>> **I) C2 crashes with segmentation fault in strip-mined loops**
>> 
>> Previous implementation was done before C2 loop strip-mining was merged
>> into JDK master so it didn't take strip-mined loops into consideration.
>> In C2's strip mined loops, post loop is not the sibling of the main loop
>> in ideal loop tree. Instead, it's the sibling of the main loop's parent.
>> This patch fixed a SIGSEGV issue caused by NULL pointer when locating
>> post loop from strip-mined main loop.
>> 
>> **II) Incorrect result issues with post loop vectorization**
>> 
>> We have also fixed five incorrect vectorization issues. Some of them are
>> hidden deep and can only be reproduced with corner cases. These issues
>> have a common cause that it assumes the post loop can be vectorized if
>> the vectorization in corresponding main loop is successful. But in many
>> cases this assumption is wrong. Below are details.
>> 
>> - **[Issue-1] Incorrect vectorization for partial vectorizable loops**
>> 
>> This issue can be reproduced by below loop where only some operations in
>> the loop body are vectorizable.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     res[i] = a[i] * b[i];
>>     k = 3 * k + 1;
>>   }
>> 
>> In the main loop, superword can work well if parts of the operations in
>> loop body are not vectorizable since those parts can be unrolled only.
>> But for post loops, we don't create vectors through combining scalar IRs
>> generated from loop unrolling. Instead, we are doing scalars to vectors
>> replacement for all operations in the loop body. Hence, all operations
>> should be either vectorized together or not vectorized at all. To fix
>> this kind of cases, we add an extra field "_slp_vector_pack_count" in
>> CountedLoopNode to record the eventual count of vector packs in the main
>> loop. This value is then passed to post loop and compared with post loop
>> pack count. Vectorization will be bailed out in post loop if it creates
>> more vector packs than in the main loop.
>> 
>> - **[Issue-2] Incorrect result in loops with growing-down vectors**
>> 
>> This issue appears with growing-down vectors, that is, vectors that grow
>> to smaller memory address as the loop iterates. It can be reproduced by
>> below counting-up loop with negative scale value in array index.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     a[MAX - i] = b[MAX - i];
>>   }
>> 
>> Cause of this issue is that for a growing-down vector, generated vector
>> mask value has reversed vector-lane order so it masks incorrect vector
>> lanes. Note that if negative scale value appears in counting-down loops,
>> the vector will be growing up. With this rule, we fix the issue by only
>> allowing positive array index scales in counting-up loops and negative
>> array index scales in counting-down loops. This check is done with the
>> help of SWPointer by comparing scale values in each memory access in the
>> loop with loop stride value.
>> 
>> - **[Issue-3] Incorrect result in manually unrolled loops**
>> 
>> This issue can be reproduced by below manually unrolled loop.
>> 
>>   for (int i = 0; i < 10000; i += 2) {
>>     c[i] = a[i] + b[i];
>>     c[i + 1] = a[i + 1] * b[i + 1];
>>   }
>> 
>> In this loop, operations in the 2nd statement duplicate those in the 1st
>> statement with a small memory address offset. Vectorization in the main
>> loop works well in this case because C2 does further unrolling and pack
>> combination. But we cannot vectorize the post loop through replacement
>> from scalars to vectors because it creates duplicated vector operations.
>> To fix this, we restrict post loop vectorization to loops with stride
>> values of 1 or -1.
>> 
>> - **[Issue-4] Incorrect result in loops with mixed vector element sizes**
>> 
>> This issue is found after we enable post loop vectorization for AArch64.
>> It's reproducible by multiple array operations with different element
>> sizes inside a loop. On x86, there is no issue because the values of x86
>> AVX512 opmasks only depend on which vector lanes are active. But AArch64
>> is different - the values of SVE predicates also depend on lane size of
>> the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
>> sizes, we should use different vector masks. For now, we just support
>> loops with only one vector element size, i.e., "int + float" vectors in
>> a single loop is ok but "int + double" vectors in a single loop is not
>> vectorizable. This fix also enables subword vectors support to make all
>> primitive type array operations vectorizable.
>> 
>> - **[Issue-5] Incorrect result in loops with potential data dependence**
>> 
>> This issue can be reproduced by below corner case on AArch64 only.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     a[i] = x;
>>     a[i + OFFSET] = y;
>>   }
>> 
>> In this case, two stores in the loop have data dependence if the OFFSET
>> value is smaller than the vector length. So we cannot do vectorization
>> through replacing scalars to vectors. But the main loop vectorization
>> in this case is successful on AArch64 because AArch64 has partial vector
>> load/store support. It splits vector fill with different values in lanes
>> to several smaller-sized fills. In this patch, we add additional data
>> dependence check for this kind of cases. The check is also done with the
>> help of SWPointer class. In this check, we require that every two memory
>> accesses (with at least one store) of the same element type (or subword
>> size) in the loop has the same array index expression.
>> 
>> ### Tests
>> 
>> So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
>> experimental VM option "PostLoopMultiversioning" turned on. We found no
>> issue in all tests. We notice that those existing cases are not enough
>> because some of above issues are not spotted by them. We would like to
>> add some new cases but we found existing vectorization tests are a bit
>> cumbersome - golden results must be pre-calculated and hard-coded in the
>> test code for correctness verification. Thus, in this patch, we propose
>> a new vectorization testing framework.
>> 
>> Our new framework brings a simpler way to add new cases. For a new test
>> case, we only need to create a new method annotated with "@Test". The
>> test runner will invoke each annotated method twice automatically. First
>> time it runs in the interpreter and second time it's forced compiled by
>> C2. Then the two return results are compared. So in this framework each
>> test method should return a primitive value or an array of primitives.
>> In this way, no extra verification code for vectorization correctness is
>> required. This test runner is still jtreg-based and takes advantages of
>> the jtreg WhiteBox API, which enables test methods running at specific
>> compilation levels. Each test class inside is also jtreg-based. It just
>> need to inherit from the test runner class and run with two additional
>> options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
>> 
>> ### Summary & Future work
>> 
>> In this patch, we reworked post loop vectorization. We made it platform
>> independent and fixed several issues inside. We also implemented a new
>> vectorization testing framework with many test cases inside. Meanwhile,
>> we did some code cleanups.
>> 
>> This patch only touches C2 code guarded with PostLoopMultiversioning,
>> except a few data structure changes. So, there's no behavior change when
>> experimental VM option PostLoopMultiversioning is off. Also, to reduce
>> risks, we still propose to keep post loop vectorization experimental for
>> now. But if it receives positive feedback, we would like to change it to
>> non-experimental in the future.
>
> Pengfei Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update a few comments

I tested this this with and without `-XX:+PostLoopMultiversioning`. All tests passed.

The changes look good to me but someone with a better understanding of the old implementation should look at this as well (@vnkozlov, @sviswanathan ?).

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6828

From thartmann at openjdk.java.net  Tue Mar 22 08:12:39 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 22 Mar 2022 08:12:39 GMT
Subject: RFR: 8283408: Fix a C2 crash when filling arrays with unsafe [v2]
In-Reply-To: <tF8Dp608ZvVeZvjz5QMixxOIf-WlDJc4tdC26dNO1ZM=.5e8eed61-58b3-48be-a6d5-bda95d702b04@github.com>
References: <B6NUr4Mz47vDH3FSwshS2R5U33FutQxB2s-jYRcQG80=.c3dee38b-a74f-42cd-9c01-381906b4a4ac@github.com>
 <tF8Dp608ZvVeZvjz5QMixxOIf-WlDJc4tdC26dNO1ZM=.5e8eed61-58b3-48be-a6d5-bda95d702b04@github.com>
Message-ID: <_-_4SQrfOPzSKIbhmhgx69JC6cHse4PO_Lf3fkWUD9o=.379848d9-ae8e-4fb4-8122-4f4e481c524c@github.com>

On Tue, 22 Mar 2022 03:43:08 GMT, Pengfei Li <pli at openjdk.org> wrote:

>> We recently found a segmentation fault issue in C2 compiler with some
>> code that uses Java Unsafe API to initialize an array in a loop. It can
>> be reproduced by below code snippet compiled by C2 on AArch64. It's also
>> reproducible on x86 with an additional VM option "-XX:+OptimizeFill".
>> 
>>   byte[] arr = new byte[size];
>>   int offset = unsafe.arrayBaseOffset(byte[].class);
>>   for (int i = offset; i < offset + size; i++) {
>>     unsafe.putByte(arr, i, val);
>>   }
>> 
>> This issue is caused by a NULL pointer in a C2 loop optimization phase
>> called intrinsify_fill. In this phase, array filling loop patterns are
>> recognized and replaced by some intrinsics. But filling operations with
>> Unsafe API call are not handled very well. From C2 mid-end's point of
>> view, a difference between an Unsafe call and a normal array access like
>> `arr[i] = val` is element addressing. For normal array accesses, C2 uses
>> two AddP nodes for computing an element's address - one for adding array
>> header size and another for adding the element's relative offset from
>> the header. But Unsafe calls may have only one AddP node for adding an
>> absolute offset of an element from the array base. In current code, the
>> intrinsify_fill phase creates an AddP node but with NULL input for above
>> case and eventually causes a segmentation fault.
>> 
>> In this patch, we add a check to allow one AddP node in array filling
>> patterns to be optional. After this fix, the case above can be optimized
>> by intrinsify_fill as well. We know that the Unsafe call is rarely used
>> in Java application code and developers should use it at their own risk.
>> But we still propose this fix because C2 crashes even Unsafe is used in
>> a correct way.
>> 
>> Jtreg hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1
>> are tested and no issue is found. We also create a new jtreg case within
>> this patch.
>
> Pengfei Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a few comments

Looks good to me too.

src/hotspot/share/opto/loopTransform.cpp line 4050:

> 4048:   // AddP node adding an absolute offset, so we do a NULL check here.
> 4049:   if (offset != NULL) {
> 4050:     from = new AddPNode(base, from, offset);

Is it worth adding an `C->has_unsafe_access()` assert here?

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7884

From thartmann at openjdk.java.net  Tue Mar 22 09:02:31 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 22 Mar 2022 09:02:31 GMT
Subject: RFR: 8279888: Local variable independently used by multiple loops
 can interfere with loop optimizations [v2]
In-Reply-To: <EPhDMRb-8V_7XtzGiD5-xNUCyMubRPCOrDGhw6Lyy_U=.216476ae-e92e-4642-bb7a-baf8d779f0bf@github.com>
References: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
 <EPhDMRb-8V_7XtzGiD5-xNUCyMubRPCOrDGhw6Lyy_U=.216476ae-e92e-4642-bb7a-baf8d779f0bf@github.com>
Message-ID: <gLKR0ccH6Xqv2Cj9E9-tnr0JvlGkaRoRPzIrQnV3W9E=.519c4be3-f6d5-416b-86b4-4811e13d819e@github.com>

On Wed, 9 Feb 2022 10:23:46 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The bytecode of the 2 methods of the benchmark is structured
>> differently: loopsWithSharedLocal(), the slowest one, has multiple
>> backedges with a single head while loopsWithScopedLocal() has a single
>> backedge and all the paths in the loop body merge before the
>> backedge. loopsWithSharedLocal() has its head cloned which results in
>> a 2 loops loop nest.
>> 
>> loopsWithSharedLocal() is slow when 2 of the backedges are most
>> commonly taken with one taken only 3 times as often as the other
>> one. So a thread executing that code only runs the inner loop for a
>> few iterations before exiting it and executing the outer loop. I think
>> what happens is that any time the inner loop is entered, some
>> predicates are executed and the overhead of the setup of loop strip
>> mining (if it's enabled) has to be paid. Also, if iteration
>> splitting/unrolling was applied, the main loop is likely never
>> executed and all time is spent in the pre/post loops where potentially
>> some range checks remain.
>> 
>> The fix I propose is that ciTypeFlow, when it clone heads, not only
>> rewires the most frequent loop but also all this other frequent loops
>> that share the same head. loopsWithSharedLocal() and
>> loopsWithScopedLocal() are then fairly similar once c2 parses them.
>> 
>> Without the patch I measure:
>> 
>> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.874 ? 250.463  ns/op
>> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1575.665 ?  70.372  ns/op
>> 
>> with it:
>> 
>> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.180 ? 245.873  ns/op
>> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1234.665 ? 157.912  ns/op
>> 
>> But this patch also causes a regression when running one of the
>> benchmarks added by 8278518. From:
>> 
>> SharedLoopHeader.sharedHeader  avgt    5  505.993 ? 44.126  ns/op
>> 
>> to:
>> 
>> SharedLoopHeader.sharedHeader  avgt    5  724.253 ? 1.664  ns/op
>> 
>> The hot method of this benchmark used to be compiled with 2 loops, the
>> inner one a counted loop. With the patch, it's now compiled with a
>> single one which can't be converted into a counted loop because the
>> loop variable is incremented by a different amount along the 2 paths
>> in the loop body. What I propose to fix this is to add a new loop
>> transformation that detects that, because of a merge point, a loop
>> can't be turned into a counted loop and transforms it into 2
>> loops. The benchmark performs better with this:
>> 
>> SharedLoopHeader.sharedHeader  avgt    5  567.150 ? 6.120  ns/op
>> 
>> Not quite on par with the previous score but AFAICT this is due to
>> code generation not being as good (the loop head can't be aligned in
>> particular).
>> 
>> In short, I propose:
>> 
>> - changing ciTypeFlow so that, when it pays off, a loop with
>> multiple backedges is compiled as a single loop with a merge point in
>> the loop body
>> 
>> - adding a new loop transformation so that, when it pays off, a loop
>> with a merge point in the loop body is converted into a 2 loops loop
>> nest, essentially the opposite transformation.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - fix
>  - Merge branch 'master' into JDK-8279888
>  - whitespaces
>  - fix & test

Looks good to me overall but this is very hard to review. More people should look at it.

If you resolve the merge conflicts, I can run some more testing with `-XX:+StressDuplicateBackedge` enabled.

src/hotspot/share/opto/loopopts.cpp line 2533:

> 2531:         // Now finish up 'r'
> 2532:         r->set_req( 1, newuse);
> 2533:         r->set_req( 2,    use);

Suggestion:

        r->set_req(1, newuse);
        r->set_req(2,    use);

src/hotspot/share/opto/loopopts.cpp line 2536:

> 2534:         _igvn.register_new_node_with_optimizer(r);
> 2535:         set_loop(r, use_loop);
> 2536:         set_idom(r, side_by_side_idom == NULL? newuse->in(0) : side_by_side_idom, dd_r);

Suggestion:

        set_idom(r, (side_by_side_idom == NULL) ? newuse->in(0) : side_by_side_idom, dd_r);

-------------

PR: https://git.openjdk.java.net/jdk/pull/7352

From thartmann at openjdk.java.net  Tue Mar 22 09:21:36 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 22 Mar 2022 09:21:36 GMT
Subject: RFR: 8283187: C2: loop candidate for superword not always unrolled
 fully if superword fails
In-Reply-To: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
References: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
Message-ID: <yY1knoCmNNttIftdcTLQN7Q7tfk1wyYyDJBCsKm-fcA=.ab51b29f-3788-4418-8218-ba4d7c2b4159@github.com>

On Tue, 15 Mar 2022 15:45:08 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> IdealLoopTree::policy_unroll_slp_analysis() restricts unrolling of
> loops that are found to be candidate for superword but if superword
> then fails, unrolling doesn't always resume. SuperWord::output() has
> logic for that in one of the failure paths but some other paths are
> not covered (for instance in the case of the test case). I propose
> that superword explictly returns whether it succeeded or not and that
> in case of failure, for a main loop, unrolling be attempted again.

Good catch! The fix looks good to me.

test/hotspot/jtreg/compiler/c2/irTests/TestSuperwordFailsUnrolling.java line 49:

> 47:         }
> 48:         TestFramework.run();
> 49: 

Suggestion:

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7822

From xgong at openjdk.java.net  Tue Mar 22 09:58:23 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 22 Mar 2022 09:58:23 GMT
Subject: RFR: 8282162: [vector] Optimize vector negation API [v2]
In-Reply-To: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
Message-ID: <QnpIqj1hBZz6GNQxOr72g8PEMH4uKtAzNyR-9tCX1b4=.797224d5-c5a6-4732-9323-3b64aa4fa12f@github.com>

> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE.
> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern.
> 
> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture:
>   - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation.
>   - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`.
> 
> So with this patch, the following transformations are applied:
> 
> For non-masked negation with NEON:
> 
>   movi    v16.4s, #0x0
>   sub v17.4s, v16.4s, v17.4s       ==> neg v17.4s, v17.4s
> 
> and with SVE:
> 
>   mov z16.s, #0
>   sub z18.s, z16.s, z17.s          ==> neg z16.s, p7/m, z16.s
> 
> For masked negation with NEON:
> 
>   movi    v17.4s, #0x1
>   mvn v19.16b, v18.16b
>   mov v20.16b, v16.16b             ==>  neg v18.4s, v17.4s
>   bsl v20.16b, v19.16b, v18.16b         bsl v19.16b, v18.16b, v17.16b
>   add v19.4s, v20.4s, v17.4s
>   mov v18.16b, v16.16b
>   bsl v18.16b, v19.16b, v20.16b
> 
> and with SVE:
> 
>   mov z16.s, #-1
>   mov z17.s, #1                    ==> neg z16.s, p0/m, z16.s
>   eor z18.s, p0/m, z18.s, z16.s
>   add z18.s, p0/m, z18.s, z17.s
> 
> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed):
> 
> NEON:
> Benchmark                Gain
> Byte128Vector.NEG        1.029
> Byte128Vector.NEGMasked  1.757
> Short128Vector.NEG       1.041
> Short128Vector.NEGMasked 1.659
> Int128Vector.NEG         1.005
> Int128Vector.NEGMasked   1.513
> Long128Vector.NEG        1.003
> Long128Vector.NEGMasked  1.878
> 
> SVE with 512-bits:
> Benchmark                Gain
> ByteMaxVector.NEG        1.10
> ByteMaxVector.NEGMasked  1.165
> ShortMaxVector.NEG       1.056
> ShortMaxVector.NEGMasked 1.195
> IntMaxVector.NEG         1.002
> IntMaxVector.NEGMasked   1.239
> LongMaxVector.NEG        1.031
> LongMaxVector.NEGMasked  1.191
> 
> X86 (non AVX-512):
> Benchmark                Gain
> ByteMaxVector.NEGMasked  1.254
> ShortMaxVector.NEGMasked 1.359
> IntMaxVector.NEGMasked   1.431
> LongMaxVector.NEGMasked  1.989
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Add a superclass for vector negation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7782/files
  - new: https://git.openjdk.java.net/jdk/pull/7782/files/828866f8..97c8119a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7782&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7782&range=00-01

  Stats: 64 lines in 4 files changed: 16 ins; 13 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7782.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7782/head:pull/7782

PR: https://git.openjdk.java.net/jdk/pull/7782

From xgong at openjdk.java.net  Tue Mar 22 09:58:23 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 22 Mar 2022 09:58:23 GMT
Subject: RFR: 8282162: [vector] Optimize vector negation API
In-Reply-To: <p3lkqI9cxLgVusyCGgnHKdvdKvHBEM7k4K05wVTogu4=.65b852ba-7d1c-4dd9-af68-f1a238050dd3@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
 <-E5E_NBci6gsGyOV5nWuTUNKLVnjiw2IiWjjgv2vFz0=.ebe7c447-ede9-4437-815c-a2004f9d6ce1@github.com>
 <UIbbi5W7BMv_b9IuzYdCQOCzSNfJuHEvOOuqqRyhHUE=.cc631985-5ef3-4d93-a6d6-c73db7903412@github.com>
 <p3lkqI9cxLgVusyCGgnHKdvdKvHBEM7k4K05wVTogu4=.65b852ba-7d1c-4dd9-af68-f1a238050dd3@github.com>
Message-ID: <roERQxyAYBeHUlp_ycHeT5Vb8kgX3vSpgMVxEHK7xH0=.3f324b1b-bd41-4b8a-9cef-1ebb14e210ab@github.com>

On Sat, 19 Mar 2022 03:11:12 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>>> Note that in terms of Java semantics, negation of floating point values needs to be implemented as subtraction from negative zero rather than positive zero:
>>> 
>>> double negate(double arg) {return -0.0 - arg; }
>>> 
>>> This is to handle signed zeros correctly.
>> 
>> Hi @jddarcy ,thanks for looking at this PR and thanks for the notes on the floating point negation! Yeah, this really makes sense to me. Kindly note that this patch didn't touch the negation of the floating point values. For Vector API, the vector floating point negation has been intrinsified to `NegVF/D` node by compiler that we directly generate the negation instructions for them. Thanks!
>
>> Note that in terms of Java semantics, negation of floating point values needs to be implemented as subtraction from negative zero rather than positive zero:
>> 
>> double negate(double arg) {return -0.0 - arg; }
>> 
>> This is to handle signed zeros correctly.
> 
> This seems easy to be broken by an opt enhancement.
> Just wondering do we have a jtreg test for this point? @jddarcy 
> Thanks.

Hi @DamonFool , thanks for your review! All the comments have been addressed. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From thartmann at openjdk.java.net  Tue Mar 22 10:22:34 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 22 Mar 2022 10:22:34 GMT
Subject: RFR: 8281429: PhiNode::Value() is too conservative for tripcount
 of CountedLoop
In-Reply-To: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
References: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
Message-ID: <9sYg3nlxZcukMcDoqB1r52bqOqMvuqom8K-iqTflX9w=.dfc952bd-060c-4287-a666-6d0db41afdca@github.com>

On Tue, 15 Mar 2022 16:02:54 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The type for the iv phi of a counted loop is computed from the types
> of the phi on loop entry and the type of the limit from the exit
> test. Because the exit test is applied to the iv after increment, the
> type of the iv phi is at least one less than the limit (for a positive
> stride, one more for a negative stride).
> 
> Also, for a stride whose absolute value is not 1 and constant init and
> limit values, it's possible to compute accurately the iv phi type.
> 
> This change caused a few failures and I had to make a few adjustments
> to loop opts code as well.

Looks good to me otherwise.

src/hotspot/share/opto/cfgnode.cpp line 1111:

> 1109:         const TypeInteger* stride_t = phase->type(stride)->isa_integer(l->bt());
> 1110:         if (lo != NULL && hi != NULL && stride_t != NULL) { // Dying loops might have TOP here
> 1111:           assert(stride_t->hi_as_long() == stride_t->lo_as_long(), "bad stride type");

Should we simply check `stride_t->is_con()` here?

src/hotspot/share/opto/cfgnode.cpp line 1127:

> 1125:                   julong uhi = static_cast<julong>(hi->lo_as_long());
> 1126:                   julong ulo = static_cast<julong>(lo->hi_as_long());
> 1127:                   julong diff = (uhi - ulo - 1) / (-stride_t->lo_as_long()) * (-stride_t->lo_as_long());

Suggestion:

                  julong diff = ((uhi - ulo - 1) / (-stride_t->lo_as_long())) * (-stride_t->lo_as_long());

src/hotspot/share/opto/cfgnode.cpp line 1142:

> 1140:                   julong uhi = static_cast<julong>(hi->lo_as_long());
> 1141:                   julong ulo = static_cast<julong>(lo->hi_as_long());
> 1142:                   julong diff = (uhi - ulo - 1) / stride_t->lo_as_long() * stride_t->lo_as_long();

Suggestion:

                  julong diff = ((uhi - ulo - 1) / stride_t->lo_as_long()) * stride_t->lo_as_long();

src/hotspot/share/opto/loopPredicate.cpp line 1069:

> 1067:                 inner_loop = inner_loop->_child;
> 1068:                 inner_head = inner_loop->_head->as_Loop();
> 1069:                 inner_head->verify_strip_mined(1);

Why did you remove the verification code?

src/hotspot/share/opto/loopnode.cpp line 850:

> 848:   const TypeInteger* lo = _igvn.type(init)->is_integer(bt);
> 849:   const TypeInteger* hi = _igvn.type(limit)->is_integer(bt);
> 850:   julong orig_iters;

Suggestion:

src/hotspot/share/opto/loopnode.cpp line 855:

> 853:   }
> 854:   assert(hi->hi_as_long() > lo->lo_as_long(), "no iterations?");
> 855:   orig_iters = hi->hi_as_long()  - lo->lo_as_long();

Suggestion:

  julong orig_iters = hi->hi_as_long() - lo->lo_as_long();

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7823

From thartmann at openjdk.java.net  Tue Mar 22 10:37:37 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 22 Mar 2022 10:37:37 GMT
Subject: RFR: 8282592: C2: assert(false) failed: graph should be
 schedulable [v2]
In-Reply-To: <rYKeXamlwlpn7dIGy99R_1KUbZaBhUkjINHzR7iDm94=.825ccf55-d66c-40ae-bbf2-2e444e71b234@github.com>
References: <-oXZLZYrKlxysFQgwKntZUr7dqC6G_WBEzi-ngqwqws=.c1ab815a-9065-4aba-9948-b3df225d0d3e@github.com>
 <rYKeXamlwlpn7dIGy99R_1KUbZaBhUkjINHzR7iDm94=.825ccf55-d66c-40ae-bbf2-2e444e71b234@github.com>
Message-ID: <acisP333utDN540LPu5hqCNRm0zVypcMBLNY2WNPrzU=.1327da0c-ad1f-4968-b0eb-e7822ca5b632@github.com>

On Mon, 14 Mar 2022 09:16:52 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This is another case of overunrolling that causes the type of the main
>> loop's iv to conflict with a ConvI2L of an array access. Skeleton
>> predicates were added to solve this family of issues. A predicate that
>> should catch that the main loop is unreachable is indeed added but the
>> predicate's condition doesn't constant fold.
>> 
>> What happens is that the main loop's iv phi initial value is a CastII
>> (added by PhaseIdealLoop::cast_incr_before_loop()). That CastII is
>> input to the predicates above the main loop and of the main loop's iv
>> phi. Once loop opts are over, the type of the CastII is updated by
>> CastIINode::Value() (the logic that looks at the test that guards the
>> CastII). The type update causes the main loop iv phi's type to be
>> updated and a ConvI2L to be become top. The predicate that should
>> catch the overunrolling has the shape:
>> 
>> (CmpU (AddI#1 (CastII (AddI#2 (Phi ..) ConI#1)) ConI#2) ConI#3)
>> 
>> In the case of the test case:
>> 
>> ConI#3 = 10
>> ConI#2 = 7
>> ConI#1 = 1
>> 
>> CastII has type = int:<=max-8
>> Phi has type = int:>=8
>> 
>> As a result:
>> AddI#2 has type int
>> AddI#1 has type int:min+7..max-1
>> 
>> The Phi is the pre loop Phi.
>> 
>> The fix I propose is that predicates when they are updated should skip
>> over the CastII, that is in this case:
>> 
>> (CmpU (AddI#1 (AddI#2 (Phi ..) ConI#1) ConI#2) ConI#3)
>> 
>> which is reshaped to:
>> 
>> (CmpU (AddI#1' (Phi ..) ConI#1') ConI#3)
>> 
>> In this case:
>> 
>> ConI#1 = 4 (because the predicate constant fold in earlier passes of
>> unrolling)
>> 
>> As a result AddI#1' still has type int But CmpUNode has special logic
>> to deal with the (CmpU (AddI ...)) shape and it can determine that
>> this one always fails.
>> 
>> The role of the CastII is to enforce the dependency between nodes in
>> the loop and the the loop entry test so it's not required for
>> predicates.
>> 
>> With that change, compiler/loopopts/TestOverunrolling.java fails
>> because a predicate doesn't constant fold anymore. The reason in that
>> case, is that PhaseIdealLoop::reorg_offsets() adds an Opaque2 between
>> the pre loop iv phi and the predicate that hides the type of the iv
>> phi. Without the change, the CastII captures the type of the iv phi
>> and the Opaque2 node is added between the CastII and the pre loop iv
>> phi. To solve that problem, I propose that
>> PhaseIdealLoop::reorg_offsets() always add a CastII after the Opaque2
>> so the type of the iv phi is not lost.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - test run failure
>  - Merge branch 'master' into JDK-8282592
>  - test & fix

Looks good to me too.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7758

From roland at openjdk.java.net  Tue Mar 22 10:37:38 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 10:37:38 GMT
Subject: RFR: 8282592: C2: assert(false) failed: graph should be
 schedulable [v2]
In-Reply-To: <Xq00k6LNsylBWqz5BbLGpTXqgvXeoWj-PMA-a-MSYiU=.45df5f9f-beab-4b82-9933-e12e167c5a07@github.com>
References: <-oXZLZYrKlxysFQgwKntZUr7dqC6G_WBEzi-ngqwqws=.c1ab815a-9065-4aba-9948-b3df225d0d3e@github.com>
 <rYKeXamlwlpn7dIGy99R_1KUbZaBhUkjINHzR7iDm94=.825ccf55-d66c-40ae-bbf2-2e444e71b234@github.com>
 <Xq00k6LNsylBWqz5BbLGpTXqgvXeoWj-PMA-a-MSYiU=.45df5f9f-beab-4b82-9933-e12e167c5a07@github.com>
Message-ID: <BwzkWu7PnfZuYxvubWrqNn05H7RR0-jO-y4-zdGbSl8=.0127ca9c-6b0d-442c-93a9-ecb466540c3a@github.com>

On Wed, 16 Mar 2022 14:10:31 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - test run failure
>>  - Merge branch 'master' into JDK-8282592
>>  - test & fix
>
> Testing looked good!

@chhagedorn @TobiHartmann thanks for the reviews

-------------

PR: https://git.openjdk.java.net/jdk/pull/7758

From roland at openjdk.java.net  Tue Mar 22 10:37:39 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 10:37:39 GMT
Subject: Integrated: 8282592: C2: assert(false) failed: graph should be
 schedulable
In-Reply-To: <-oXZLZYrKlxysFQgwKntZUr7dqC6G_WBEzi-ngqwqws=.c1ab815a-9065-4aba-9948-b3df225d0d3e@github.com>
References: <-oXZLZYrKlxysFQgwKntZUr7dqC6G_WBEzi-ngqwqws=.c1ab815a-9065-4aba-9948-b3df225d0d3e@github.com>
Message-ID: <QZmOP9-6NFmVkZJpiriF6Rr0q10ZqHuMZAYEjDZRfo8=.8ba39955-5bb5-4528-a62a-8dd779362a0f@github.com>

On Wed, 9 Mar 2022 13:42:01 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> This is another case of overunrolling that causes the type of the main
> loop's iv to conflict with a ConvI2L of an array access. Skeleton
> predicates were added to solve this family of issues. A predicate that
> should catch that the main loop is unreachable is indeed added but the
> predicate's condition doesn't constant fold.
> 
> What happens is that the main loop's iv phi initial value is a CastII
> (added by PhaseIdealLoop::cast_incr_before_loop()). That CastII is
> input to the predicates above the main loop and of the main loop's iv
> phi. Once loop opts are over, the type of the CastII is updated by
> CastIINode::Value() (the logic that looks at the test that guards the
> CastII). The type update causes the main loop iv phi's type to be
> updated and a ConvI2L to be become top. The predicate that should
> catch the overunrolling has the shape:
> 
> (CmpU (AddI#1 (CastII (AddI#2 (Phi ..) ConI#1)) ConI#2) ConI#3)
> 
> In the case of the test case:
> 
> ConI#3 = 10
> ConI#2 = 7
> ConI#1 = 1
> 
> CastII has type = int:<=max-8
> Phi has type = int:>=8
> 
> As a result:
> AddI#2 has type int
> AddI#1 has type int:min+7..max-1
> 
> The Phi is the pre loop Phi.
> 
> The fix I propose is that predicates when they are updated should skip
> over the CastII, that is in this case:
> 
> (CmpU (AddI#1 (AddI#2 (Phi ..) ConI#1) ConI#2) ConI#3)
> 
> which is reshaped to:
> 
> (CmpU (AddI#1' (Phi ..) ConI#1') ConI#3)
> 
> In this case:
> 
> ConI#1 = 4 (because the predicate constant fold in earlier passes of
> unrolling)
> 
> As a result AddI#1' still has type int But CmpUNode has special logic
> to deal with the (CmpU (AddI ...)) shape and it can determine that
> this one always fails.
> 
> The role of the CastII is to enforce the dependency between nodes in
> the loop and the the loop entry test so it's not required for
> predicates.
> 
> With that change, compiler/loopopts/TestOverunrolling.java fails
> because a predicate doesn't constant fold anymore. The reason in that
> case, is that PhaseIdealLoop::reorg_offsets() adds an Opaque2 between
> the pre loop iv phi and the predicate that hides the type of the iv
> phi. Without the change, the CastII captures the type of the iv phi
> and the Opaque2 node is added between the CastII and the pre loop iv
> phi. To solve that problem, I propose that
> PhaseIdealLoop::reorg_offsets() always add a CastII after the Opaque2
> so the type of the iv phi is not lost.

This pull request has now been integrated.

Changeset: 85628a87
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/85628a871df3fdeec1b422d1c01c222abe45d0a8
Stats:     86 lines in 3 files changed: 86 ins; 0 del; 0 mod

8282592: C2: assert(false) failed: graph should be schedulable

Reviewed-by: chagedorn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7758

From chagedorn at openjdk.java.net  Tue Mar 22 10:44:41 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 22 Mar 2022 10:44:41 GMT
Subject: RFR: 8281429: PhiNode::Value() is too conservative for tripcount
 of CountedLoop
In-Reply-To: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
References: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
Message-ID: <Da1Z1ev11UNEZK79-GrvcfDF42Y_x0AJMkfrQe7111Y=.f9f350d1-c83d-4878-a89a-f50194d79872@github.com>

On Tue, 15 Mar 2022 16:02:54 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The type for the iv phi of a counted loop is computed from the types
> of the phi on loop entry and the type of the limit from the exit
> test. Because the exit test is applied to the iv after increment, the
> type of the iv phi is at least one less than the limit (for a positive
> stride, one more for a negative stride).
> 
> Also, for a stride whose absolute value is not 1 and constant init and
> limit values, it's possible to compute accurately the iv phi type.
> 
> This change caused a few failures and I had to make a few adjustments
> to loop opts code as well.

src/hotspot/share/opto/cfgnode.cpp line 1129:

> 1127:                   julong diff = (uhi - ulo - 1) / (-stride_t->lo_as_long()) * (-stride_t->lo_as_long());
> 1128:                   julong ufirst = hi->lo_as_long() - diff;
> 1129:                   first = reinterpret_cast<jlong &>(ufirst);

Could we also use a `static_cast` here and further down instead?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7823

From roland at openjdk.java.net  Tue Mar 22 12:16:11 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 12:16:11 GMT
Subject: RFR: 8283451: C2: assert(_base == Long) failed: Not a Long
Message-ID: <fiSOEIRUkopMns-0e1fe2bLKp3Or_VtCOsXFL3t1AVU=.54a053b7-6629-4cd7-bbd1-799fac575a81@github.com>

The code in PhaseIterGVN::no_dependent_zero_check() tests for a top
input by checking if is_top() is true but in this case the node has
type top but is not yet transformed to top (after CCP).

-------------

Commit messages:
 - whitespaces
 - test
 - fix

Changes: https://git.openjdk.java.net/jdk/pull/7902/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7902&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283451
  Stats: 78 lines in 2 files changed: 76 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7902.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7902/head:pull/7902

PR: https://git.openjdk.java.net/jdk/pull/7902

From roland at openjdk.java.net  Tue Mar 22 12:18:22 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 12:18:22 GMT
Subject: RFR: 8283187: C2: loop candidate for superword not always unrolled
 fully if superword fails [v2]
In-Reply-To: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
References: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
Message-ID: <6etwB55nudBQgU6N-1hK35AO0h3uoZo_rnbseKrOUg4=.79af9aa5-3c64-48ff-93c3-81b7455169c8@github.com>

> IdealLoopTree::policy_unroll_slp_analysis() restricts unrolling of
> loops that are found to be candidate for superword but if superword
> then fails, unrolling doesn't always resume. SuperWord::output() has
> logic for that in one of the failure paths but some other paths are
> not covered (for instance in the case of the test case). I propose
> that superword explictly returns whether it succeeded or not and that
> in case of failure, for a main loop, unrolling be attempted again.

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  Update test/hotspot/jtreg/compiler/c2/irTests/TestSuperwordFailsUnrolling.java
  
  Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7822/files
  - new: https://git.openjdk.java.net/jdk/pull/7822/files/9941937d..cac6704b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7822&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7822&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7822/head:pull/7822

PR: https://git.openjdk.java.net/jdk/pull/7822

From roland at openjdk.java.net  Tue Mar 22 12:22:33 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 12:22:33 GMT
Subject: RFR: 8283187: C2: loop candidate for superword not always unrolled
 fully if superword fails [v2]
In-Reply-To: <yY1knoCmNNttIftdcTLQN7Q7tfk1wyYyDJBCsKm-fcA=.ab51b29f-3788-4418-8218-ba4d7c2b4159@github.com>
References: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
 <yY1knoCmNNttIftdcTLQN7Q7tfk1wyYyDJBCsKm-fcA=.ab51b29f-3788-4418-8218-ba4d7c2b4159@github.com>
Message-ID: <xTLbNO7QaLLnfTV6xq3GO0fVf0iY6xbhsnBaP9TI4WE=.c4049098-4a1d-4a19-ab50-e9e20966b631@github.com>

On Tue, 22 Mar 2022 09:18:14 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Good catch! The fix looks good to me.

thanks for the review! I applied your suggestions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7822

From thartmann at openjdk.java.net  Tue Mar 22 12:23:40 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 22 Mar 2022 12:23:40 GMT
Subject: RFR: 8283451: C2: assert(_base == Long) failed: Not a Long
In-Reply-To: <fiSOEIRUkopMns-0e1fe2bLKp3Or_VtCOsXFL3t1AVU=.54a053b7-6629-4cd7-bbd1-799fac575a81@github.com>
References: <fiSOEIRUkopMns-0e1fe2bLKp3Or_VtCOsXFL3t1AVU=.54a053b7-6629-4cd7-bbd1-799fac575a81@github.com>
Message-ID: <dZIjNTEzdC8t-XRJjaYonGKrRr1GYd0FYipPvHCMrns=.9f2e8997-7b91-4a82-9d44-32a7c222a892@github.com>

On Tue, 22 Mar 2022 11:27:56 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The code in PhaseIterGVN::no_dependent_zero_check() tests for a top
> input by checking if is_top() is true but in this case the node has
> type top but is not yet transformed to top (after CCP).

Looks good.

test/hotspot/jtreg/compiler/c2/TestModDivTopInput.java line 29:

> 27:  * @summary C2: assert(_base == Long) failed: Not a Long
> 28:  * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP -XX:+StressIGVN
> 29:  *                   -Xcomp -XX:CompileOnly=TestModDivTopInput -XX:-TieredCompilation -XX:StressSeed=87628618 TestModDivTopInput

Please add another run without a fixed seed.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7902

From roland at openjdk.java.net  Tue Mar 22 12:24:32 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 12:24:32 GMT
Subject: RFR: 8279888: Local variable independently used by multiple loops
 can interfere with loop optimizations [v3]
In-Reply-To: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
References: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
Message-ID: <5QafTkJRgy4_RPY_S9Y7xFF80lX5gnrXbfLL-k6bECc=.720caeb8-82fb-4ff1-8a0f-a057e08d8cf9@github.com>

> The bytecode of the 2 methods of the benchmark is structured
> differently: loopsWithSharedLocal(), the slowest one, has multiple
> backedges with a single head while loopsWithScopedLocal() has a single
> backedge and all the paths in the loop body merge before the
> backedge. loopsWithSharedLocal() has its head cloned which results in
> a 2 loops loop nest.
> 
> loopsWithSharedLocal() is slow when 2 of the backedges are most
> commonly taken with one taken only 3 times as often as the other
> one. So a thread executing that code only runs the inner loop for a
> few iterations before exiting it and executing the outer loop. I think
> what happens is that any time the inner loop is entered, some
> predicates are executed and the overhead of the setup of loop strip
> mining (if it's enabled) has to be paid. Also, if iteration
> splitting/unrolling was applied, the main loop is likely never
> executed and all time is spent in the pre/post loops where potentially
> some range checks remain.
> 
> The fix I propose is that ciTypeFlow, when it clone heads, not only
> rewires the most frequent loop but also all this other frequent loops
> that share the same head. loopsWithSharedLocal() and
> loopsWithScopedLocal() are then fairly similar once c2 parses them.
> 
> Without the patch I measure:
> 
> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.874 ? 250.463  ns/op
> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1575.665 ?  70.372  ns/op
> 
> with it:
> 
> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.180 ? 245.873  ns/op
> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1234.665 ? 157.912  ns/op
> 
> But this patch also causes a regression when running one of the
> benchmarks added by 8278518. From:
> 
> SharedLoopHeader.sharedHeader  avgt    5  505.993 ? 44.126  ns/op
> 
> to:
> 
> SharedLoopHeader.sharedHeader  avgt    5  724.253 ? 1.664  ns/op
> 
> The hot method of this benchmark used to be compiled with 2 loops, the
> inner one a counted loop. With the patch, it's now compiled with a
> single one which can't be converted into a counted loop because the
> loop variable is incremented by a different amount along the 2 paths
> in the loop body. What I propose to fix this is to add a new loop
> transformation that detects that, because of a merge point, a loop
> can't be turned into a counted loop and transforms it into 2
> loops. The benchmark performs better with this:
> 
> SharedLoopHeader.sharedHeader  avgt    5  567.150 ? 6.120  ns/op
> 
> Not quite on par with the previous score but AFAICT this is due to
> code generation not being as good (the loop head can't be aligned in
> particular).
> 
> In short, I propose:
> 
> - changing ciTypeFlow so that, when it pays off, a loop with
> multiple backedges is compiled as a single loop with a merge point in
> the loop body
> 
> - adding a new loop transformation so that, when it pays off, a loop
> with a merge point in the loop body is converted into a 2 loops loop
> nest, essentially the opposite transformation.

Roland Westrelin has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/hotspot/share/opto/loopopts.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - Update src/hotspot/share/opto/loopopts.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7352/files
  - new: https://git.openjdk.java.net/jdk/pull/7352/files/cabd514b..44327da1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7352&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7352&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7352.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7352/head:pull/7352

PR: https://git.openjdk.java.net/jdk/pull/7352

From roland at openjdk.java.net  Tue Mar 22 12:45:12 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 12:45:12 GMT
Subject: RFR: 8279888: Local variable independently used by multiple loops
 can interfere with loop optimizations [v4]
In-Reply-To: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
References: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
Message-ID: <YJhxTTOGOtTUtWTphu86IpfbSRsXEqvXxUHwwmbafuI=.cdbc0230-d32a-4da1-b1ca-e2a46a2e0b15@github.com>

> The bytecode of the 2 methods of the benchmark is structured
> differently: loopsWithSharedLocal(), the slowest one, has multiple
> backedges with a single head while loopsWithScopedLocal() has a single
> backedge and all the paths in the loop body merge before the
> backedge. loopsWithSharedLocal() has its head cloned which results in
> a 2 loops loop nest.
> 
> loopsWithSharedLocal() is slow when 2 of the backedges are most
> commonly taken with one taken only 3 times as often as the other
> one. So a thread executing that code only runs the inner loop for a
> few iterations before exiting it and executing the outer loop. I think
> what happens is that any time the inner loop is entered, some
> predicates are executed and the overhead of the setup of loop strip
> mining (if it's enabled) has to be paid. Also, if iteration
> splitting/unrolling was applied, the main loop is likely never
> executed and all time is spent in the pre/post loops where potentially
> some range checks remain.
> 
> The fix I propose is that ciTypeFlow, when it clone heads, not only
> rewires the most frequent loop but also all this other frequent loops
> that share the same head. loopsWithSharedLocal() and
> loopsWithScopedLocal() are then fairly similar once c2 parses them.
> 
> Without the patch I measure:
> 
> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.874 ? 250.463  ns/op
> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1575.665 ?  70.372  ns/op
> 
> with it:
> 
> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.180 ? 245.873  ns/op
> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1234.665 ? 157.912  ns/op
> 
> But this patch also causes a regression when running one of the
> benchmarks added by 8278518. From:
> 
> SharedLoopHeader.sharedHeader  avgt    5  505.993 ? 44.126  ns/op
> 
> to:
> 
> SharedLoopHeader.sharedHeader  avgt    5  724.253 ? 1.664  ns/op
> 
> The hot method of this benchmark used to be compiled with 2 loops, the
> inner one a counted loop. With the patch, it's now compiled with a
> single one which can't be converted into a counted loop because the
> loop variable is incremented by a different amount along the 2 paths
> in the loop body. What I propose to fix this is to add a new loop
> transformation that detects that, because of a merge point, a loop
> can't be turned into a counted loop and transforms it into 2
> loops. The benchmark performs better with this:
> 
> SharedLoopHeader.sharedHeader  avgt    5  567.150 ? 6.120  ns/op
> 
> Not quite on par with the previous score but AFAICT this is due to
> code generation not being as good (the loop head can't be aligned in
> particular).
> 
> In short, I propose:
> 
> - changing ciTypeFlow so that, when it pays off, a loop with
> multiple backedges is compiled as a single loop with a merge point in
> the loop body
> 
> - adding a new loop transformation so that, when it pays off, a loop
> with a merge point in the loop body is converted into a 2 loops loop
> nest, essentially the opposite transformation.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into JDK-8279888
 - Merge commit '44327da170c57ccd31bfad379738c7f00e67f4c1' into JDK-8279888
 - Update src/hotspot/share/opto/loopopts.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - Update src/hotspot/share/opto/loopopts.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - Merge branch 'master' into JDK-8279888
 - Merge branch 'master' into JDK-8279888
 - fix
 - Merge branch 'master' into JDK-8279888
 - whitespaces
 - fix & test

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7352/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7352&range=03
  Stats: 1083 lines in 9 files changed: 783 ins; 132 del; 168 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7352.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7352/head:pull/7352

PR: https://git.openjdk.java.net/jdk/pull/7352

From roland at openjdk.java.net  Tue Mar 22 12:45:14 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 12:45:14 GMT
Subject: RFR: 8279888: Local variable independently used by multiple loops
 can interfere with loop optimizations [v2]
In-Reply-To: <gLKR0ccH6Xqv2Cj9E9-tnr0JvlGkaRoRPzIrQnV3W9E=.519c4be3-f6d5-416b-86b4-4811e13d819e@github.com>
References: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
 <EPhDMRb-8V_7XtzGiD5-xNUCyMubRPCOrDGhw6Lyy_U=.216476ae-e92e-4642-bb7a-baf8d779f0bf@github.com>
 <gLKR0ccH6Xqv2Cj9E9-tnr0JvlGkaRoRPzIrQnV3W9E=.519c4be3-f6d5-416b-86b4-4811e13d819e@github.com>
Message-ID: <Y8o3iw3CWiX3ToTk4xeICC4oERVa7wur-t-nWjF7T-A=.eb7c9c85-6cee-4bd3-8aff-a453f0312d6c@github.com>

On Tue, 22 Mar 2022 08:59:30 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Looks good to me overall but this is very hard to review. More people should look at it.
> 
> If you resolve the merge conflicts, I can run some more testing with `-XX:+StressDuplicateBackedge` enabled.

Thanks for reviewing this. I applied your suggestions and merged.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7352

From roland at openjdk.java.net  Tue Mar 22 12:57:13 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 12:57:13 GMT
Subject: RFR: 8281429: PhiNode::Value() is too conservative for tripcount
 of CountedLoop [v2]
In-Reply-To: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
References: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
Message-ID: <Rc4Fq1y0pEYxMr00l97SzJ9JtiHsAAcA3sOA_K7IzBg=.d980223c-07d2-4ca6-8843-dd1d2a80b193@github.com>

> The type for the iv phi of a counted loop is computed from the types
> of the phi on loop entry and the type of the limit from the exit
> test. Because the exit test is applied to the iv after increment, the
> type of the iv phi is at least one less than the limit (for a positive
> stride, one more for a negative stride).
> 
> Also, for a stride whose absolute value is not 1 and constant init and
> limit values, it's possible to compute accurately the iv phi type.
> 
> This change caused a few failures and I had to make a few adjustments
> to loop opts code as well.

Roland Westrelin has updated the pull request incrementally with four additional commits since the last revision:

 - Update src/hotspot/share/opto/cfgnode.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - Update src/hotspot/share/opto/cfgnode.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - Update src/hotspot/share/opto/loopnode.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - Update src/hotspot/share/opto/loopnode.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7823/files
  - new: https://git.openjdk.java.net/jdk/pull/7823/files/a8722dba..1532675c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7823&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7823&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7823.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7823/head:pull/7823

PR: https://git.openjdk.java.net/jdk/pull/7823

From roland at openjdk.java.net  Tue Mar 22 12:57:16 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 12:57:16 GMT
Subject: RFR: 8281429: PhiNode::Value() is too conservative for tripcount
 of CountedLoop [v2]
In-Reply-To: <9sYg3nlxZcukMcDoqB1r52bqOqMvuqom8K-iqTflX9w=.dfc952bd-060c-4287-a666-6d0db41afdca@github.com>
References: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
 <9sYg3nlxZcukMcDoqB1r52bqOqMvuqom8K-iqTflX9w=.dfc952bd-060c-4287-a666-6d0db41afdca@github.com>
Message-ID: <i28XCs0ovz3ZOUo3cLSUWqvUpfMuTsxlnARKdD8VtjY=.6638c3b0-b4b7-453e-8d7d-c92342a25cc1@github.com>

On Tue, 22 Mar 2022 09:35:37 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Update src/hotspot/share/opto/cfgnode.cpp
>>    
>>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>>  - Update src/hotspot/share/opto/cfgnode.cpp
>>    
>>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>>  - Update src/hotspot/share/opto/loopnode.cpp
>>    
>>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>>  - Update src/hotspot/share/opto/loopnode.cpp
>>    
>>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>
> src/hotspot/share/opto/cfgnode.cpp line 1111:
> 
>> 1109:         const TypeInteger* stride_t = phase->type(stride)->isa_integer(l->bt());
>> 1110:         if (lo != NULL && hi != NULL && stride_t != NULL) { // Dying loops might have TOP here
>> 1111:           assert(stride_t->hi_as_long() == stride_t->lo_as_long(), "bad stride type");
> 
> Should we simply check `stride_t->is_con()` here?

right.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7823

From roland at openjdk.java.net  Tue Mar 22 12:57:17 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 12:57:17 GMT
Subject: RFR: 8281429: PhiNode::Value() is too conservative for tripcount
 of CountedLoop [v2]
In-Reply-To: <Da1Z1ev11UNEZK79-GrvcfDF42Y_x0AJMkfrQe7111Y=.f9f350d1-c83d-4878-a89a-f50194d79872@github.com>
References: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
 <Da1Z1ev11UNEZK79-GrvcfDF42Y_x0AJMkfrQe7111Y=.f9f350d1-c83d-4878-a89a-f50194d79872@github.com>
Message-ID: <TVfNcRf1PoQNhVICf9E1d_CZGUmJ9Dk6RoWDMq_u_Ko=.fbcf5126-75f9-4b15-bbf5-9246aae3bd6c@github.com>

On Tue, 22 Mar 2022 10:41:32 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Update src/hotspot/share/opto/cfgnode.cpp
>>    
>>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>>  - Update src/hotspot/share/opto/cfgnode.cpp
>>    
>>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>>  - Update src/hotspot/share/opto/loopnode.cpp
>>    
>>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>>  - Update src/hotspot/share/opto/loopnode.cpp
>>    
>>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>
> src/hotspot/share/opto/cfgnode.cpp line 1129:
> 
>> 1127:                   julong diff = (uhi - ulo - 1) / (-stride_t->lo_as_long()) * (-stride_t->lo_as_long());
>> 1128:                   julong ufirst = hi->lo_as_long() - diff;
>> 1129:                   first = reinterpret_cast<jlong &>(ufirst);
> 
> Could we also use a `static_cast` here and further down instead?

Thanks for looking at this.
I'm not sure. I modeled this code on java_add/java_substract etc.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7823

From thartmann at openjdk.java.net  Tue Mar 22 12:57:14 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 22 Mar 2022 12:57:14 GMT
Subject: RFR: 8281429: PhiNode::Value() is too conservative for tripcount
 of CountedLoop [v2]
In-Reply-To: <Rc4Fq1y0pEYxMr00l97SzJ9JtiHsAAcA3sOA_K7IzBg=.d980223c-07d2-4ca6-8843-dd1d2a80b193@github.com>
References: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
 <Rc4Fq1y0pEYxMr00l97SzJ9JtiHsAAcA3sOA_K7IzBg=.d980223c-07d2-4ca6-8843-dd1d2a80b193@github.com>
Message-ID: <NL6wuFpXzAQarqNjGtq3kil4Ag4Hk1558jysqqwQ6f4=.93c7e80b-044f-4c27-9b9d-5f1c66a89b28@github.com>

On Tue, 22 Mar 2022 12:54:05 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The type for the iv phi of a counted loop is computed from the types
>> of the phi on loop entry and the type of the limit from the exit
>> test. Because the exit test is applied to the iv after increment, the
>> type of the iv phi is at least one less than the limit (for a positive
>> stride, one more for a negative stride).
>> 
>> Also, for a stride whose absolute value is not 1 and constant init and
>> limit values, it's possible to compute accurately the iv phi type.
>> 
>> This change caused a few failures and I had to make a few adjustments
>> to loop opts code as well.
>
> Roland Westrelin has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update src/hotspot/share/opto/cfgnode.cpp
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - Update src/hotspot/share/opto/cfgnode.cpp
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - Update src/hotspot/share/opto/loopnode.cpp
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - Update src/hotspot/share/opto/loopnode.cpp
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

I executed testing and the "no iterations?" assert triggers. I'll follow up with details on how to reproduce.

-------------

Changes requested by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7823

From roland at openjdk.java.net  Tue Mar 22 13:01:36 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 13:01:36 GMT
Subject: RFR: 8281429: PhiNode::Value() is too conservative for tripcount
 of CountedLoop [v2]
In-Reply-To: <9sYg3nlxZcukMcDoqB1r52bqOqMvuqom8K-iqTflX9w=.dfc952bd-060c-4287-a666-6d0db41afdca@github.com>
References: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
 <9sYg3nlxZcukMcDoqB1r52bqOqMvuqom8K-iqTflX9w=.dfc952bd-060c-4287-a666-6d0db41afdca@github.com>
Message-ID: <_1zw-Ms3Da8_EwtlmTdH7QesA1-BmzzvkXcxIC45UnE=.ab7ec74c-4d8b-47b6-a810-1a072e128226@github.com>

On Tue, 22 Mar 2022 09:45:24 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Update src/hotspot/share/opto/cfgnode.cpp
>>    
>>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>>  - Update src/hotspot/share/opto/cfgnode.cpp
>>    
>>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>>  - Update src/hotspot/share/opto/loopnode.cpp
>>    
>>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>>  - Update src/hotspot/share/opto/loopnode.cpp
>>    
>>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>
> src/hotspot/share/opto/loopPredicate.cpp line 1069:
> 
>> 1067:                 inner_loop = inner_loop->_child;
>> 1068:                 inner_head = inner_loop->_head->as_Loop();
>> 1069:                 inner_head->verify_strip_mined(1);
> 
> Why did you remove the verification code?

I hit a failure in that code for an inner loop that no longer has the shape of a counted loop. Let me double check if I can still reproduce it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7823

From roland at openjdk.java.net  Tue Mar 22 13:08:33 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 13:08:33 GMT
Subject: RFR: 8281429: PhiNode::Value() is too conservative for tripcount
 of CountedLoop [v3]
In-Reply-To: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
References: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
Message-ID: <yQBdmbDtfQ0j88ZmjXatbThlIaiCt_pdGEpf9zy7ajE=.fce1a178-9a6b-471a-b4f5-79eceadfbc51@github.com>

> The type for the iv phi of a counted loop is computed from the types
> of the phi on loop entry and the type of the limit from the exit
> test. Because the exit test is applied to the iv after increment, the
> type of the iv phi is at least one less than the limit (for a positive
> stride, one more for a negative stride).
> 
> Also, for a stride whose absolute value is not 1 and constant init and
> limit values, it's possible to compute accurately the iv phi type.
> 
> This change caused a few failures and I had to make a few adjustments
> to loop opts code as well.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - review
 - Merge branch 'master' into JDK-8281429
 - Update src/hotspot/share/opto/cfgnode.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - Update src/hotspot/share/opto/cfgnode.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - Update src/hotspot/share/opto/loopnode.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - Update src/hotspot/share/opto/loopnode.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - fix & test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7823/files
  - new: https://git.openjdk.java.net/jdk/pull/7823/files/1532675c..ed91dd8e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7823&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7823&range=01-02

  Stats: 8740 lines in 1090 files changed: 4565 ins; 1710 del; 2465 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7823.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7823/head:pull/7823

PR: https://git.openjdk.java.net/jdk/pull/7823

From roland at openjdk.java.net  Tue Mar 22 13:08:33 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 13:08:33 GMT
Subject: RFR: 8281429: PhiNode::Value() is too conservative for tripcount
 of CountedLoop [v3]
In-Reply-To: <9sYg3nlxZcukMcDoqB1r52bqOqMvuqom8K-iqTflX9w=.dfc952bd-060c-4287-a666-6d0db41afdca@github.com>
References: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
 <9sYg3nlxZcukMcDoqB1r52bqOqMvuqom8K-iqTflX9w=.dfc952bd-060c-4287-a666-6d0db41afdca@github.com>
Message-ID: <UjlvTiYl36E4ypAhvbWCpuzaxENv6ozeyDycdqfMAJ4=.67cd1a85-21e6-4557-b27d-5583c30f87d7@github.com>

On Tue, 22 Mar 2022 10:19:49 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Looks good to me otherwise.

Thanks for reviewing this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7823

From rbackman at openjdk.java.net  Tue Mar 22 13:26:34 2022
From: rbackman at openjdk.java.net (Rickard =?UTF-8?B?QsOkY2ttYW4=?=)
Date: Tue, 22 Mar 2022 13:26:34 GMT
Subject: RFR: 8281222: ciTypeFlow::profiled_count fails
 "assert(0 <= i && i < _len) failed: illegal index"
In-Reply-To: <cx-Y1dFRqYBShCvokUMvAy195erPLgA4FsUWGf6TmHQ=.b6576322-12a1-4a18-b776-fb0e26c8f356@github.com>
References: <TsG0o1zrQRvR93tubXro8EBe2KOvuEmEHVsSci5iiek=.05c25bab-4a8e-4141-827c-5d9cde29cb06@github.com>
 <cx-Y1dFRqYBShCvokUMvAy195erPLgA4FsUWGf6TmHQ=.b6576322-12a1-4a18-b776-fb0e26c8f356@github.com>
Message-ID: <mYvwhDyl4Wf5GuOS8z_ZckdVPgeo7PfIhwlkUh4eVtE=.8f2ded58-46a3-4ed5-aedc-48057fd8a334@github.com>

On Mon, 21 Mar 2022 15:09:42 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Looks good to me. A test case would be nice.

Agreed, but I wasn't able to reproduce it in another environment than the one that caused the issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7892

From roland at openjdk.java.net  Tue Mar 22 14:05:26 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 14:05:26 GMT
Subject: RFR: 8283451: C2: assert(_base == Long) failed: Not a Long [v2]
In-Reply-To: <fiSOEIRUkopMns-0e1fe2bLKp3Or_VtCOsXFL3t1AVU=.54a053b7-6629-4cd7-bbd1-799fac575a81@github.com>
References: <fiSOEIRUkopMns-0e1fe2bLKp3Or_VtCOsXFL3t1AVU=.54a053b7-6629-4cd7-bbd1-799fac575a81@github.com>
Message-ID: <4seOrBFXmxcULh_UWeByjxgach3cQYhHZBrv-21BweM=.0c4336a2-43ee-442c-bc35-7d23beb599bd@github.com>

> The code in PhaseIterGVN::no_dependent_zero_check() tests for a top
> input by checking if is_top() is true but in this case the node has
> type top but is not yet transformed to top (after CCP).

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  review

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7902/files
  - new: https://git.openjdk.java.net/jdk/pull/7902/files/eca58ac5..82094cde

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7902&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7902&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7902.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7902/head:pull/7902

PR: https://git.openjdk.java.net/jdk/pull/7902

From chagedorn at openjdk.java.net  Tue Mar 22 14:05:26 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 22 Mar 2022 14:05:26 GMT
Subject: RFR: 8283451: C2: assert(_base == Long) failed: Not a Long [v2]
In-Reply-To: <4seOrBFXmxcULh_UWeByjxgach3cQYhHZBrv-21BweM=.0c4336a2-43ee-442c-bc35-7d23beb599bd@github.com>
References: <fiSOEIRUkopMns-0e1fe2bLKp3Or_VtCOsXFL3t1AVU=.54a053b7-6629-4cd7-bbd1-799fac575a81@github.com>
 <4seOrBFXmxcULh_UWeByjxgach3cQYhHZBrv-21BweM=.0c4336a2-43ee-442c-bc35-7d23beb599bd@github.com>
Message-ID: <YI9WZBrR5C4dcEcDCBNlgD4kUYhLOspChZxQX8M30y8=.36f6c615-99fe-4ff8-94cc-61a36d6a8a7d@github.com>

On Tue, 22 Mar 2022 14:02:13 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The code in PhaseIterGVN::no_dependent_zero_check() tests for a top
>> input by checking if is_top() is true but in this case the node has
>> type top but is not yet transformed to top (after CCP).
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Looks good!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7902

From roland at openjdk.java.net  Tue Mar 22 14:05:27 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 14:05:27 GMT
Subject: RFR: 8283451: C2: assert(_base == Long) failed: Not a Long [v2]
In-Reply-To: <dZIjNTEzdC8t-XRJjaYonGKrRr1GYd0FYipPvHCMrns=.9f2e8997-7b91-4a82-9d44-32a7c222a892@github.com>
References: <fiSOEIRUkopMns-0e1fe2bLKp3Or_VtCOsXFL3t1AVU=.54a053b7-6629-4cd7-bbd1-799fac575a81@github.com>
 <dZIjNTEzdC8t-XRJjaYonGKrRr1GYd0FYipPvHCMrns=.9f2e8997-7b91-4a82-9d44-32a7c222a892@github.com>
Message-ID: <LGj2-CKERQ9ZiPY_kB6V1wOtWrr_Lmn4ytRWJXZAlAU=.97b8483d-35d0-4c70-b5b5-d97c5e970aaa@github.com>

On Tue, 22 Mar 2022 12:20:12 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Looks good.

Thanks for reviewing this.

> test/hotspot/jtreg/compiler/c2/TestModDivTopInput.java line 29:
> 
>> 27:  * @summary C2: assert(_base == Long) failed: Not a Long
>> 28:  * @run main/othervm -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressCCP -XX:+StressIGVN
>> 29:  *                   -Xcomp -XX:CompileOnly=TestModDivTopInput -XX:-TieredCompilation -XX:StressSeed=87628618 TestModDivTopInput
> 
> Please add another run without a fixed seed.

Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7902

From roland at openjdk.java.net  Tue Mar 22 14:10:38 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 14:10:38 GMT
Subject: RFR: 8283451: C2: assert(_base == Long) failed: Not a Long [v2]
In-Reply-To: <YI9WZBrR5C4dcEcDCBNlgD4kUYhLOspChZxQX8M30y8=.36f6c615-99fe-4ff8-94cc-61a36d6a8a7d@github.com>
References: <fiSOEIRUkopMns-0e1fe2bLKp3Or_VtCOsXFL3t1AVU=.54a053b7-6629-4cd7-bbd1-799fac575a81@github.com>
 <4seOrBFXmxcULh_UWeByjxgach3cQYhHZBrv-21BweM=.0c4336a2-43ee-442c-bc35-7d23beb599bd@github.com>
 <YI9WZBrR5C4dcEcDCBNlgD4kUYhLOspChZxQX8M30y8=.36f6c615-99fe-4ff8-94cc-61a36d6a8a7d@github.com>
Message-ID: <BKhHQD7glgKoY_r18MSHxhKyFLzBvVpWPx9aO9bGNuU=.b7400520-e356-4202-9111-868ec2a19811@github.com>

On Tue, 22 Mar 2022 14:00:54 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> Looks good!

@chhagedorn thanks for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7902

From roland at openjdk.java.net  Tue Mar 22 14:10:39 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 22 Mar 2022 14:10:39 GMT
Subject: Integrated: 8283451: C2: assert(_base == Long) failed: Not a Long
In-Reply-To: <fiSOEIRUkopMns-0e1fe2bLKp3Or_VtCOsXFL3t1AVU=.54a053b7-6629-4cd7-bbd1-799fac575a81@github.com>
References: <fiSOEIRUkopMns-0e1fe2bLKp3Or_VtCOsXFL3t1AVU=.54a053b7-6629-4cd7-bbd1-799fac575a81@github.com>
Message-ID: <sm6kK-ZVCXdS8znEJPgyNrnI7f1Nm-QZa2pqn5crkys=.2595d8d4-6daf-4dd0-a4ad-cddb6d6c964c@github.com>

On Tue, 22 Mar 2022 11:27:56 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> The code in PhaseIterGVN::no_dependent_zero_check() tests for a top
> input by checking if is_top() is true but in this case the node has
> type top but is not yet transformed to top (after CCP).

This pull request has now been integrated.

Changeset: fabde3b7
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fabde3b7b8ed5e576febe8138c14696ccdf636d5
Stats:     80 lines in 2 files changed: 78 ins; 0 del; 2 mod

8283451: C2: assert(_base == Long) failed: Not a Long

Reviewed-by: thartmann, chagedorn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7902

From thartmann at openjdk.java.net  Tue Mar 22 15:18:35 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 22 Mar 2022 15:18:35 GMT
Subject: RFR: 8283422: Create a new test for JDK-8254790
In-Reply-To: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
References: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
Message-ID: <6vd52cbOe5EwVMzQzJXiKqPwH54iyaNKdgEM4423was=.88915790-a78e-41fd-994a-1b339c0f6887@github.com>

On Mon, 21 Mar 2022 03:34:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The [JDK-8254790](https://bugs.openjdk.java.net/browse/JDK-8254790) initially was reported on macOS.
> It was found by the "javax/xml/crypto/dsig/GenerationTests.java" test which for some reason worked fine on Linux/Windows most? of the time.
> 
> I tried to run that test on Linux/Windows many times on a few systems and it always pass. Also, I got the same result for the tier1...tier4 tests.
> 
> I have found that the easiest way to reproduce the crash is to pass the result of the string.indexOf to the str.charAt when the heap is big enough. The test below[1] trigger the crash 1000 time in a row on win/lin on systems I have tested.
> 
> I am not sure what is the best way to contribute to the test, should I create a stand-alone test like[1], or update an existing test as I did for the first version of this PR?
> 
> [1]:
> 
> package compiler.intrinsics.string;
> 
> import static jdk.test.lib.Asserts.assertTrue;
> 
> public final class TestStringIndexOfLargeHeap {
>     static final int[] data = new int[Integer.MAX_VALUE / 2];
>     public static void main(String[] args) throws Exception {
>         test('a');
>         test('\ubeef');
>     }
>     private static void test(char ch) {
>         String str = ("0123456789" + ch).repeat(100);
>         for (int i = 0; i < 1_000_000; ++i) {
>             assertTrue(ch == str.charAt(str.indexOf(ch)));
>         }
>     }
> }

The test fails in our CI with:


java.lang.OutOfMemoryError: Java heap space
	at compiler.intrinsics.string.TestStringIntrinsics2.main(TestStringIntrinsics2.java:142)
	at java.base/java.lang.invoke.LambdaForm$DMH/0x0000000801002800.invokeStatic(LambdaForm$DMH)
	at java.base/java.lang.invoke.LambdaForm$MH/0x0000000801003c00.invoke(LambdaForm$MH)
	at java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(DirectMethodHandleAccessor.java:155)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:828)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7883

From djelinski at openjdk.java.net  Tue Mar 22 15:27:57 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 22 Mar 2022 15:27:57 GMT
Subject: RFR: 8283519: Hsdis with capstone should annotate output
Message-ID: <cFqhmme_HJNYQKvYv9gW3ADqO1NGEDsSWdRxiLgVL7E=.9afd0736-6ff3-4077-8372-c7d83cfa4875@github.com>

Sample output after the changes:

[Stub Code]
  0x000001cd0a937e20:   nopl		(%rax, %rax)        ;   {no_reloc}
  0x000001cd0a937e25:   movabsq		$0x0, %rbx          ;   {static_stub}
  0x000001cd0a937e2f:   jmp		0x1cd0a937e2f       ;   {runtime_call}
[Exception Handler]
  0x000001cd0a937e34:   callq		0x1cd0a3ca480       ;   {runtime_call handle_exception_from_callee Runtime1 stub}
  0x000001cd0a937e39:   movabsq		$0x7ff8df21a850, %rcx;   {external_word}
  0x000001cd0a937e43:   andq		$0xfffffffffffffff0, %rsp
  0x000001cd0a937e47:   movabsq		$0x7ff8deef30c0, %r10;   {runtime_call MacroAssembler::debug64}
  0x000001cd0a937e51:   callq		*%r10
  0x000001cd0a937e54:   hlt		
[Deopt Handler Code]
  0x000001cd0a937e55:   movabsq		$0x1cd0a937e55, %r10;   {section_word}
  0x000001cd0a937e5f:   pushq		%r10
  0x000001cd0a937e61:   jmp		0x1cd0a325ca0       ;   {runtime_call DeoptimizationBlob}
  0x000001cd0a937e66:   hlt		
  0x000001cd0a937e67:   hlt		

before the changes none of the annotations (like `[Stub Code]` or `;   {no_reloc}`) were present.

-------------

Commit messages:
 - Annotate assembly output

Changes: https://git.openjdk.java.net/jdk/pull/7904/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7904&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283519
  Stats: 42 lines in 1 file changed: 41 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7904.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7904/head:pull/7904

PR: https://git.openjdk.java.net/jdk/pull/7904

From duke at openjdk.java.net  Tue Mar 22 16:26:38 2022
From: duke at openjdk.java.net (Emanuel Peter)
Date: Tue, 22 Mar 2022 16:26:38 GMT
Subject: Integrated: 8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0)
 failed: Don't process dead nodes
In-Reply-To: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
References: <5dWzMlDXAbiAfJtqap1f-pdk0D7NI5U9sSJ-UIc1kto=.8ea18c88-0a6b-4dd6-8da1-2f8b46dacb48@github.com>
Message-ID: <4HDlzpW9_MT94yFxCyVsBLuv20Jk_pBkW-98ImvRuzw=.ec6a17da-27ff-46f1-ad77-9d40dc60921d@github.com>

On Mon, 7 Mar 2022 15:04:54 GMT, Emanuel Peter <duke at openjdk.java.net> wrote:

> Problem:
> Sometimes nodes are generated, and then not properly added to any other node, nor added to the worklist, so that it could be deleted. In some cases, a node can thus survive after IGVN and enter into `ConnectionGraph::compute_escape`, where no dead nodes are expected (except constants).
> 
> In `ArrayCopyNode::prepare_array_copy`:
> In one, I now add the new ConvI2LNode to the worklist if we are aborting.
> In the other case, I could safely reorder the code, such new ConvI2LNode would only be generated once we know we are not going to abort.
> 
> In `SubTypeCheckNode::Ideal`:
> Replaced `set_req` with `set_req_X`, such that the input-node that is replaced (which is now potentially a dead node) is put on the worklist.
> 
> In `ArrayCopyNode::Ideal`:
> If we decide to `return NULL` we also need to add the potentially dead forward / backward memory nodes to the worklist, they may turn out to be dead.
> 
> Added a regression test: the test + flag combination that first reproduced this issue.
> 
> All Tests, including this new regression test are passing. Tests rerun after small refactorings.

This pull request has now been integrated.

Changeset: d29c7e74
Author:    Emanuel Peter <emanuel.peter at oracle.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d29c7e740d51cb50a1aa0a941a5b460782f8da68
Stats:     39 lines in 3 files changed: 30 ins; 4 del; 5 mod

8282590: C2: assert(addp->is_AddP() && addp->outcnt() > 0) failed: Don't process dead nodes

Reviewed-by: thartmann, chagedorn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7728

From serb at openjdk.java.net  Tue Mar 22 17:36:35 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 22 Mar 2022 17:36:35 GMT
Subject: RFR: 8283422: Create a new test for JDK-8254790
In-Reply-To: <6vd52cbOe5EwVMzQzJXiKqPwH54iyaNKdgEM4423was=.88915790-a78e-41fd-994a-1b339c0f6887@github.com>
References: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
 <6vd52cbOe5EwVMzQzJXiKqPwH54iyaNKdgEM4423was=.88915790-a78e-41fd-994a-1b339c0f6887@github.com>
Message-ID: <AbXD9-rK690FaDuyHAkHjkYKE6tIhzQLZ6p81FVbOwA=.9073a74a-45bb-4ec1-be0b-ae6ae149d69b@github.com>

On Tue, 22 Mar 2022 15:15:39 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The [JDK-8254790](https://bugs.openjdk.java.net/browse/JDK-8254790) initially was reported on macOS.
>> It was found by the "javax/xml/crypto/dsig/GenerationTests.java" test which for some reason worked fine on Linux/Windows most? of the time.
>> 
>> I tried to run that test on Linux/Windows many times on a few systems and it always pass. Also, I got the same result for the tier1...tier4 tests.
>> 
>> I have found that the easiest way to reproduce the crash is to pass the result of the string.indexOf to the str.charAt when the heap is big enough. The test below[1] trigger the crash 1000 time in a row on win/lin on systems I have tested.
>> 
>> I am not sure what is the best way to contribute to the test, should I create a stand-alone test like[1], or update an existing test as I did for the first version of this PR?
>> 
>> [1]:
>> 
>> package compiler.intrinsics.string;
>> 
>> import static jdk.test.lib.Asserts.assertTrue;
>> 
>> public final class TestStringIndexOfLargeHeap {
>>     static final int[] data = new int[Integer.MAX_VALUE / 2];
>>     public static void main(String[] args) throws Exception {
>>         test('a');
>>         test('\ubeef');
>>     }
>>     private static void test(char ch) {
>>         String str = ("0123456789" + ch).repeat(100);
>>         for (int i = 0; i < 1_000_000; ++i) {
>>             assertTrue(ch == str.charAt(str.indexOf(ch)));
>>         }
>>     }
>> }
>
> The test fails in our CI with:
> 
> 
> java.lang.OutOfMemoryError: Java heap space
> 	at compiler.intrinsics.string.TestStringIntrinsics2.main(TestStringIntrinsics2.java:142)
> 	at java.base/java.lang.invoke.LambdaForm$DMH/0x0000000801002800.invokeStatic(LambdaForm$DMH)
> 	at java.base/java.lang.invoke.LambdaForm$MH/0x0000000801003c00.invoke(LambdaForm$MH)
> 	at java.base/java.lang.invoke.Invokers$Holder.invokeExact_MT(Invokers$Holder)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(DirectMethodHandleAccessor.java:155)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> 	at java.base/java.lang.Thread.run(Thread.java:828)

@TobiHartmann Thank you for your feedback, the trace shows that the test fails to allocate the FILL_HEAP = new int[Integer.MAX_VALUE / 2]; when the heap is set to 5G.  I can increase the "-mx" option, but probably the root cause of the OOM is something different, the "git actions" are green, the test is also green when I run it multiple times. Probably mach5 adds some additional options to the test execution?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7883

From djelinski at openjdk.java.net  Tue Mar 22 19:41:31 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 22 Mar 2022 19:41:31 GMT
Subject: RFR: 8283519: Hsdis with capstone should annotate output
In-Reply-To: <cFqhmme_HJNYQKvYv9gW3ADqO1NGEDsSWdRxiLgVL7E=.9afd0736-6ff3-4077-8372-c7d83cfa4875@github.com>
References: <cFqhmme_HJNYQKvYv9gW3ADqO1NGEDsSWdRxiLgVL7E=.9afd0736-6ff3-4077-8372-c7d83cfa4875@github.com>
Message-ID: <htGo0MOWE2_cjE0BlXwbTNMFo8Vv9EY7mICB_spcu5Q=.95ea241c-7047-4c54-a20d-0ef99067e4a9@github.com>

On Tue, 22 Mar 2022 15:20:38 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Sample output after the changes:
> 
> [Stub Code]
>   0x000001cd0a937e20:   nopl		(%rax, %rax)        ;   {no_reloc}
>   0x000001cd0a937e25:   movabsq		$0x0, %rbx          ;   {static_stub}
>   0x000001cd0a937e2f:   jmp		0x1cd0a937e2f       ;   {runtime_call}
> [Exception Handler]
>   0x000001cd0a937e34:   callq		0x1cd0a3ca480       ;   {runtime_call handle_exception_from_callee Runtime1 stub}
>   0x000001cd0a937e39:   movabsq		$0x7ff8df21a850, %rcx;   {external_word}
>   0x000001cd0a937e43:   andq		$0xfffffffffffffff0, %rsp
>   0x000001cd0a937e47:   movabsq		$0x7ff8deef30c0, %r10;   {runtime_call MacroAssembler::debug64}
>   0x000001cd0a937e51:   callq		*%r10
>   0x000001cd0a937e54:   hlt		
> [Deopt Handler Code]
>   0x000001cd0a937e55:   movabsq		$0x1cd0a937e55, %r10;   {section_word}
>   0x000001cd0a937e5f:   pushq		%r10
>   0x000001cd0a937e61:   jmp		0x1cd0a325ca0       ;   {runtime_call DeoptimizationBlob}
>   0x000001cd0a937e66:   hlt		
>   0x000001cd0a937e67:   hlt		
> 
> before the changes none of the annotations (like `[Stub Code]` or `;   {no_reloc}`) were present.

tested on Windows 10 (vs2019) and Ubuntu 20.04. Additionally compared the output of PrintAssembly with capstone vs binutils; there were only cosmetic differences.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7904

From duke at openjdk.java.net  Tue Mar 22 22:58:16 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Tue, 22 Mar 2022 22:58:16 GMT
Subject: RFR: 8281453: New optimization: convert "c-(~x)" into "x+(c+1)"
 and "~(c-x)" into "x+(-c-1)" [v3]
In-Reply-To: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
References: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
Message-ID: <XvolfV-wWz0Z6Pih8E9uExORMhddAlG7anOFxw6V_OA=.98e209c1-dfe0-46fd-b45e-78e44976a138@github.com>

> Similar to `(~x)+c` -> `(c-1)-x` and `~(x+c)` -> `(-c-1)-x` in #6858, we can also introduce similar optimizations for subtraction, `c-(~x)` -> `x+(c+1)` and `~(c-x)` -> `x+(-c-1)`.
> 
> The results of the microbenchmark are as follows:
> 
> Baseline:                                                                                                                                         
> Benchmark                        Mode  Cnt  Score   Error  Units
> SubIdealCMinusNotX.baselineInt   avgt   60  0.504 ? 0.011  ns/op
> SubIdealCMinusNotX.baselineLong  avgt   60  0.484 ? 0.004  ns/op
> SubIdealCMinusNotX.testInt1      avgt   60  0.779 ? 0.004  ns/op
> SubIdealCMinusNotX.testInt2      avgt   60  0.896 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong1     avgt   60  0.722 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong2     avgt   60  0.720 ? 0.005  ns/op
> 
> Patch:
> Benchmark                        Mode  Cnt  Score   Error  Units
> SubIdealCMinusNotX.baselineInt   avgt   60  0.487 ? 0.009  ns/op
> SubIdealCMinusNotX.baselineLong  avgt   60  0.486 ? 0.009  ns/op
> SubIdealCMinusNotX.testInt1      avgt   60  0.372 ? 0.010  ns/op
> SubIdealCMinusNotX.testInt2      avgt   60  0.365 ? 0.003  ns/op
> SubIdealCMinusNotX.testLong1     avgt   60  0.369 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong2     avgt   60  0.399 ? 0.016  ns/op

Zhiqiang Zang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master'.
 - convert ~x into -1-x when ~x is part of Add and Sub.
 - include bug id.
 - include a microbenmark.
 - Convert c-(~x) into x+(c+1) in SubNode and convert ~(c-x) into x+(-c-1) in XorNode.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7376/files
  - new: https://git.openjdk.java.net/jdk/pull/7376/files/76bde38e..51c98b5f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7376&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7376&range=01-02

  Stats: 113586 lines in 2379 files changed: 67898 ins; 35769 del; 9919 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7376/head:pull/7376

PR: https://git.openjdk.java.net/jdk/pull/7376

From duke at openjdk.java.net  Tue Mar 22 23:04:03 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Tue, 22 Mar 2022 23:04:03 GMT
Subject: RFR: 8281453: New optimization: convert "c-(~x)" into "x+(c+1)"
 and "~(c-x)" into "x+(-c-1)" [v4]
In-Reply-To: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
References: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
Message-ID: <Uizd88G9r31cv-uguyVY1sCiDEs2hCMkdBWcDXJfZTI=.57749a5c-008a-47df-852f-4f9056372498@github.com>

> Similar to `(~x)+c` -> `(c-1)-x` and `~(x+c)` -> `(-c-1)-x` in #6858, we can also introduce similar optimizations for subtraction, `c-(~x)` -> `x+(c+1)` and `~(c-x)` -> `x+(-c-1)`.
> 
> The results of the microbenchmark are as follows:
> 
> Baseline:                                                                                                                                         
> Benchmark                        Mode  Cnt  Score   Error  Units
> SubIdealCMinusNotX.baselineInt   avgt   60  0.504 ? 0.011  ns/op
> SubIdealCMinusNotX.baselineLong  avgt   60  0.484 ? 0.004  ns/op
> SubIdealCMinusNotX.testInt1      avgt   60  0.779 ? 0.004  ns/op
> SubIdealCMinusNotX.testInt2      avgt   60  0.896 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong1     avgt   60  0.722 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong2     avgt   60  0.720 ? 0.005  ns/op
> 
> Patch:
> Benchmark                        Mode  Cnt  Score   Error  Units
> SubIdealCMinusNotX.baselineInt   avgt   60  0.487 ? 0.009  ns/op
> SubIdealCMinusNotX.baselineLong  avgt   60  0.486 ? 0.009  ns/op
> SubIdealCMinusNotX.testInt1      avgt   60  0.372 ? 0.010  ns/op
> SubIdealCMinusNotX.testInt2      avgt   60  0.365 ? 0.003  ns/op
> SubIdealCMinusNotX.testLong1     avgt   60  0.369 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong2     avgt   60  0.399 ? 0.016  ns/op

Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:

  clean.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7376/files
  - new: https://git.openjdk.java.net/jdk/pull/7376/files/51c98b5f..5f1939c9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7376&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7376&range=02-03

  Stats: 19 lines in 1 file changed: 0 ins; 19 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7376/head:pull/7376

PR: https://git.openjdk.java.net/jdk/pull/7376

From eliu at openjdk.java.net  Wed Mar 23 01:36:27 2022
From: eliu at openjdk.java.net (Eric Liu)
Date: Wed, 23 Mar 2022 01:36:27 GMT
Subject: RFR: 8282764: AArch64:
 compiler/vectorapi/reshape/TestVectorCastNeon.java failed with incorrect
 result
In-Reply-To: <5s9gVoO8BXDC9k_GYrcMupuP60CgvgvvuTwy6obPZqA=.dbbccd3f-f4f2-404f-a9f5-7b2e110cd84e@github.com>
References: <5s9gVoO8BXDC9k_GYrcMupuP60CgvgvvuTwy6obPZqA=.dbbccd3f-f4f2-404f-a9f5-7b2e110cd84e@github.com>
Message-ID: <N21rMY46bfMnyTv4sfWIkj89Tj5ITnReL9yubbuEpbg=.3564039f-6163-4bdc-a693-e053e10fc8ce@github.com>

On Thu, 17 Mar 2022 04:33:59 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

> Vector API long to float conversion operation on NEON converts vector of 2 longs to 2 floats. In current implementation, we convert 2 longs to 2 doubles first and then converts 2 doubles to 2 floats. However, this two-steps conversion may have two roundings, while the expected behavior, conversion from long to float directly, has only one rounding. This will result in inconsistent result. E.g. for the failure test case:
> 
> 
> jshell> long l = 0x561a524000000001L;
> l ==> 6204361871487664129
> 
> jshell> float l2f = (float)l;
> l2f ==> 6.2043621E18
> 
> jshell> float l2d2f = (float)((double)l);
> l2d2f ==> 6.2043616E18
> 
> 
> Since we don't have NEON instruction to support vector long to float conversion, we fix the codegen by doing it in scalar operation one element by one element.
> 
> TEST: vector api jtreg tests passed.

Looks good to me (not a reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7850

From pli at openjdk.java.net  Wed Mar 23 02:01:24 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Wed, 23 Mar 2022 02:01:24 GMT
Subject: RFR: 8283408: Fix a C2 crash when filling arrays with unsafe [v3]
In-Reply-To: <B6NUr4Mz47vDH3FSwshS2R5U33FutQxB2s-jYRcQG80=.c3dee38b-a74f-42cd-9c01-381906b4a4ac@github.com>
References: <B6NUr4Mz47vDH3FSwshS2R5U33FutQxB2s-jYRcQG80=.c3dee38b-a74f-42cd-9c01-381906b4a4ac@github.com>
Message-ID: <XuKASyaiwJ9Aw7Y6t1Pn07gKg7n5DVjzFed6yRpxJC4=.29e532a8-3210-43cc-8106-a6ae1b1e357c@github.com>

> We recently found a segmentation fault issue in C2 compiler with some
> code that uses Java Unsafe API to initialize an array in a loop. It can
> be reproduced by below code snippet compiled by C2 on AArch64. It's also
> reproducible on x86 with an additional VM option "-XX:+OptimizeFill".
> 
>   byte[] arr = new byte[size];
>   int offset = unsafe.arrayBaseOffset(byte[].class);
>   for (int i = offset; i < offset + size; i++) {
>     unsafe.putByte(arr, i, val);
>   }
> 
> This issue is caused by a NULL pointer in a C2 loop optimization phase
> called intrinsify_fill. In this phase, array filling loop patterns are
> recognized and replaced by some intrinsics. But filling operations with
> Unsafe API call are not handled very well. From C2 mid-end's point of
> view, a difference between an Unsafe call and a normal array access like
> `arr[i] = val` is element addressing. For normal array accesses, C2 uses
> two AddP nodes for computing an element's address - one for adding array
> header size and another for adding the element's relative offset from
> the header. But Unsafe calls may have only one AddP node for adding an
> absolute offset of an element from the array base. In current code, the
> intrinsify_fill phase creates an AddP node but with NULL input for above
> case and eventually causes a segmentation fault.
> 
> In this patch, we add a check to allow one AddP node in array filling
> patterns to be optional. After this fix, the case above can be optimized
> by intrinsify_fill as well. We know that the Unsafe call is rarely used
> in Java application code and developers should use it at their own risk.
> But we still propose this fix because C2 crashes even Unsafe is used in
> a correct way.
> 
> Jtreg hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1
> are tested and no issue is found. We also create a new jtreg case within
> this patch.

Pengfei Li has updated the pull request incrementally with one additional commit since the last revision:

  Add an assertion

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7884/files
  - new: https://git.openjdk.java.net/jdk/pull/7884/files/16ebef57..a7bfd896

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7884&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7884&range=01-02

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7884.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7884/head:pull/7884

PR: https://git.openjdk.java.net/jdk/pull/7884

From pli at openjdk.java.net  Wed Mar 23 02:01:25 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Wed, 23 Mar 2022 02:01:25 GMT
Subject: RFR: 8283408: Fix a C2 crash when filling arrays with unsafe [v2]
In-Reply-To: <_-_4SQrfOPzSKIbhmhgx69JC6cHse4PO_Lf3fkWUD9o=.379848d9-ae8e-4fb4-8122-4f4e481c524c@github.com>
References: <B6NUr4Mz47vDH3FSwshS2R5U33FutQxB2s-jYRcQG80=.c3dee38b-a74f-42cd-9c01-381906b4a4ac@github.com>
 <tF8Dp608ZvVeZvjz5QMixxOIf-WlDJc4tdC26dNO1ZM=.5e8eed61-58b3-48be-a6d5-bda95d702b04@github.com>
 <_-_4SQrfOPzSKIbhmhgx69JC6cHse4PO_Lf3fkWUD9o=.379848d9-ae8e-4fb4-8122-4f4e481c524c@github.com>
Message-ID: <DBLanC52HSuUCfM2z4vhLS_ZYrK77C_kauqEJgB_gXM=.ddda9180-4601-4596-b93e-55dbc7765e34@github.com>

On Tue, 22 Mar 2022 08:09:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Pengfei Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a few comments
>
> src/hotspot/share/opto/loopTransform.cpp line 4050:
> 
>> 4048:   // AddP node adding an absolute offset, so we do a NULL check here.
>> 4049:   if (offset != NULL) {
>> 4050:     from = new AddPNode(base, from, offset);
> 
> Is it worth adding an `C->has_unsafe_access()` assert here?

An assertion is added in new commit. Thanks for your review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7884

From njian at openjdk.java.net  Wed Mar 23 02:35:28 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Wed, 23 Mar 2022 02:35:28 GMT
Subject: RFR: 8282764: AArch64:
 compiler/vectorapi/reshape/TestVectorCastNeon.java failed with incorrect
 result
In-Reply-To: <N21rMY46bfMnyTv4sfWIkj89Tj5ITnReL9yubbuEpbg=.3564039f-6163-4bdc-a693-e053e10fc8ce@github.com>
References: <5s9gVoO8BXDC9k_GYrcMupuP60CgvgvvuTwy6obPZqA=.dbbccd3f-f4f2-404f-a9f5-7b2e110cd84e@github.com>
 <N21rMY46bfMnyTv4sfWIkj89Tj5ITnReL9yubbuEpbg=.3564039f-6163-4bdc-a693-e053e10fc8ce@github.com>
Message-ID: <xcBG-7-nYbizY2yCHC0NwUf5QnGhnlZtIXih-fBjvOw=.ec760bf0-7101-4b98-9b85-705345715db9@github.com>

On Wed, 23 Mar 2022 01:33:12 GMT, Eric Liu <eliu at openjdk.org> wrote:

> Looks good to me (not a reviewer).

Thank you @theRealELiu !

-------------

PR: https://git.openjdk.java.net/jdk/pull/7850

From duke at openjdk.java.net  Wed Mar 23 06:16:29 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 23 Mar 2022 06:16:29 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con [v3]
In-Reply-To: <s210E9mQQT0SenSoO0rXeioNZY28eFTs4D18jEjfLLE=.bbeecb0f-0a32-4cda-ae40-8314a02d7941@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
 <s210E9mQQT0SenSoO0rXeioNZY28eFTs4D18jEjfLLE=.bbeecb0f-0a32-4cda-ae40-8314a02d7941@github.com>
Message-ID: <PTWmXGwsOgvsAdlFQ1MogVOZXEAp-EIUKUdqx_-xT6E=.29474594-399f-4407-9cdf-811844440ffa@github.com>

On Mon, 21 Mar 2022 22:08:09 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> `x + (con - y)  -> (x - y) + con` is a widely seen pattern; however it is missing in current implementation, which prevents some obvious constant folding from happening, such as `x + (1 - y) + 2` will be not optimized at all, rather than into `x - y + 3`.
>> 
>> This pull request adds this transformation.
>
> Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move tests to existing test classes.

test/hotspot/jtreg/compiler/c2/irTests/AddINodeIdealizationTests.java line 47:

> 45:                  "test14", "test15", "test16",
> 46:                  "test17", "test18", "test19",
> 47:                  "testXPlus_PosConMinusY_", "testXPlus_NegConMinusY_",

Please make the name uniform and put them in correct order, thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7795

From thartmann at openjdk.java.net  Wed Mar 23 06:59:36 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Mar 2022 06:59:36 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v18]
In-Reply-To: <KyoBFGrYKdHoGAWeNhM54eGA-AtOToazLOFg-zrnI9s=.a23c0299-ff24-44fb-aa13-e960d7b1f942@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <KyoBFGrYKdHoGAWeNhM54eGA-AtOToazLOFg-zrnI9s=.a23c0299-ff24-44fb-aa13-e960d7b1f942@github.com>
Message-ID: <n4VayLGjH_E901Bt88BSj2Ll4VNoOV4r2fVY0kUHEtA=.0eeb0c75-ea9f-4135-83ad-e16551e577c5@github.com>

On Fri, 18 Mar 2022 20:19:08 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Summary of changes:
>> - Intrinsify Math.round(float) and Math.round(double) APIs.
>> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics.
>> - Test creation using new IR testing framework.
>> 
>> Following are the performance number of a JMH micro included with the patch 
>> 
>> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server)
>> 
>> 
>> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio
>> -- | -- | -- | -- | -- | -- | -- | --
>> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07
>> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93
>> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02
>> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43
>> 
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - 8279508: Using an explicit scratch register since rscratch1 is bound to r10 and its usage is transparent to compiler.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
>  - 8279508: Windows build failure fix.
>  - 8279508: Styling comments resolved.
>  - 8279508: Creating separate test for round double under feature check.
>  - 8279508: Reducing the invocation count and compile thresholds for RoundTests.java.
>  - 8279508: Review comments resolution.
>  - 8279508: Preventing domain switch-over penalty for Math.round(float) and constraining unrolling to prevent code bloating.
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
>  - 8279508: Removing +LogCompilation flag.
>  - ... and 12 more: https://git.openjdk.java.net/jdk/compare/ff0b0927...c17440cf

All tests passed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From thartmann at openjdk.java.net  Wed Mar 23 07:03:40 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Mar 2022 07:03:40 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v12]
In-Reply-To: <ipzQF1uR_cuz1f7hI8RZ1HhokXaf6VGYGhx58h2VVQQ=.78863db8-b67f-4835-af92-e32c1a524353@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <ipzQF1uR_cuz1f7hI8RZ1HhokXaf6VGYGhx58h2VVQQ=.78863db8-b67f-4835-af92-e32c1a524353@github.com>
Message-ID: <nf_ibokKGwu17BfQ_giaCfBVjMV2kXYZBAFx5jcYmxI=.4819b4d4-5103-40b4-973b-0ba19a8b3be4@github.com>

On Sat, 12 Mar 2022 04:52:41 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into leaIns
>  - reviews
>  - remove unreached rules
>  - remove 0x67 prefix
>  - address reviews
>  - remove irrelevent changes
>  - reviews
>  - address reviews
>  - add benchmark
>  - add predicate
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/11fb411c...e0fd81f6

Looks good to me. All tests passed.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7560

From chagedorn at openjdk.java.net  Wed Mar 23 07:04:38 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 23 Mar 2022 07:04:38 GMT
Subject: RFR: 8281222: ciTypeFlow::profiled_count fails
 "assert(0 <= i && i < _len) failed: illegal index"
In-Reply-To: <TsG0o1zrQRvR93tubXro8EBe2KOvuEmEHVsSci5iiek=.05c25bab-4a8e-4141-827c-5d9cde29cb06@github.com>
References: <TsG0o1zrQRvR93tubXro8EBe2KOvuEmEHVsSci5iiek=.05c25bab-4a8e-4141-827c-5d9cde29cb06@github.com>
Message-ID: <9OKsI6WcbnqQsNCSowyxP_1McVSmZznLFcqgK9VTweA=.e268db44-b8d8-41e6-abd1-3500183cc611@github.com>

On Mon, 21 Mar 2022 14:45:40 GMT, Rickard B?ckman <rbackman at openjdk.org> wrote:

> This failed in Project Loom with a specific version of TestNG. 
> 
> The root cause is that the block that is considered tail doesn't have any _successors, but a couple of _exception "successors".

Looks good!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7892

From chagedorn at openjdk.java.net  Wed Mar 23 07:11:30 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 23 Mar 2022 07:11:30 GMT
Subject: RFR: 8283187: C2: loop candidate for superword not always unrolled
 fully if superword fails [v2]
In-Reply-To: <6etwB55nudBQgU6N-1hK35AO0h3uoZo_rnbseKrOUg4=.79af9aa5-3c64-48ff-93c3-81b7455169c8@github.com>
References: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
 <6etwB55nudBQgU6N-1hK35AO0h3uoZo_rnbseKrOUg4=.79af9aa5-3c64-48ff-93c3-81b7455169c8@github.com>
Message-ID: <wKsip6CkZrs7gE-eTTFTN-Odpzbh5slWV8Cy4y2OnyE=.6af162f9-ea40-44ba-a52d-c5d45d2789b1@github.com>

On Tue, 22 Mar 2022 12:18:22 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> IdealLoopTree::policy_unroll_slp_analysis() restricts unrolling of
>> loops that are found to be candidate for superword but if superword
>> then fails, unrolling doesn't always resume. SuperWord::output() has
>> logic for that in one of the failure paths but some other paths are
>> not covered (for instance in the case of the test case). I propose
>> that superword explictly returns whether it succeeded or not and that
>> in case of failure, for a main loop, unrolling be attempted again.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/compiler/c2/irTests/TestSuperwordFailsUnrolling.java
>   
>   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

That looks good!

src/hotspot/share/opto/superword.cpp line 129:

> 127:   // skip any loop that has not been assigned max unroll by analysis
> 128:   if (do_optimization) {
> 129:     if (SuperWordLoopUnrollAnalysis && cl->slp_max_unroll() == 0) return false;

While at it, you could also add braces for the one liner ifs.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7822

From thartmann at openjdk.java.net  Wed Mar 23 07:16:30 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Mar 2022 07:16:30 GMT
Subject: RFR: 8283422: Create a new test for JDK-8254790
In-Reply-To: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
References: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
Message-ID: <z9N9yHqyi0qlTCZHirK6_xDtHeXLqwoa3_Ov7ANhmMQ=.a58b1227-b173-43be-a53e-8a0f4a4f56ec@github.com>

On Mon, 21 Mar 2022 03:34:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The [JDK-8254790](https://bugs.openjdk.java.net/browse/JDK-8254790) initially was reported on macOS.
> It was found by the "javax/xml/crypto/dsig/GenerationTests.java" test which for some reason worked fine on Linux/Windows most? of the time.
> 
> I tried to run that test on Linux/Windows many times on a few systems and it always pass. Also, I got the same result for the tier1...tier4 tests.
> 
> I have found that the easiest way to reproduce the crash is to pass the result of the string.indexOf to the str.charAt when the heap is big enough. The test below[1] trigger the crash 1000 time in a row on win/lin on systems I have tested.
> 
> I am not sure what is the best way to contribute to the test, should I create a stand-alone test like[1], or update an existing test as I did for the first version of this PR?
> 
> [1]:
> 
> package compiler.intrinsics.string;
> 
> import static jdk.test.lib.Asserts.assertTrue;
> 
> public final class TestStringIndexOfLargeHeap {
>     static final int[] data = new int[Integer.MAX_VALUE / 2];
>     public static void main(String[] args) throws Exception {
>         test('a');
>         test('\ubeef');
>     }
>     private static void test(char ch) {
>         String str = ("0123456789" + ch).repeat(100);
>         for (int i = 0; i < 1_000_000; ++i) {
>             assertTrue(ch == str.charAt(str.indexOf(ch)));
>         }
>     }
> }

I think the root cause is simply that there is not enough memory available to the VM to allocate such a large object. `MaxRAMPercentage` is set to 4 but the test could also be executed on a system with a small memory size. I think the test needs to be robust enough to account for all kinds of machines/settings.

Do you know why the issue is only reproducible with a large heap and only if the heap is filled?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7883

From thartmann at openjdk.java.net  Wed Mar 23 07:19:33 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Mar 2022 07:19:33 GMT
Subject: RFR: 8283187: C2: loop candidate for superword not always unrolled
 fully if superword fails [v2]
In-Reply-To: <6etwB55nudBQgU6N-1hK35AO0h3uoZo_rnbseKrOUg4=.79af9aa5-3c64-48ff-93c3-81b7455169c8@github.com>
References: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
 <6etwB55nudBQgU6N-1hK35AO0h3uoZo_rnbseKrOUg4=.79af9aa5-3c64-48ff-93c3-81b7455169c8@github.com>
Message-ID: <3ykOLSKaQIYoJRyzXnngc3gBjxC7xdh-Grdz2_yElBk=.187c06b2-3ba9-4da8-9e65-c68bec04b1af@github.com>

On Tue, 22 Mar 2022 12:18:22 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> IdealLoopTree::policy_unroll_slp_analysis() restricts unrolling of
>> loops that are found to be candidate for superword but if superword
>> then fails, unrolling doesn't always resume. SuperWord::output() has
>> logic for that in one of the failure paths but some other paths are
>> not covered (for instance in the case of the test case). I propose
>> that superword explictly returns whether it succeeded or not and that
>> in case of failure, for a main loop, unrolling be attempted again.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/compiler/c2/irTests/TestSuperwordFailsUnrolling.java
>   
>   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

I executed some testing and `compiler/c2/irTests/TestSuperwordFailsUnrolling.java` fails on Windows only with:

java.lang.Error: failed to install whitebox classes
	at compiler.lib.ir_framework.TestFramework.installWhiteBox(TestFramework.java:529)
	at compiler.lib.ir_framework.TestFramework.start(TestFramework.java:318)
	at compiler.lib.ir_framework.TestFramework.run(TestFramework.java:210)
	at compiler.lib.ir_framework.TestFramework.run(TestFramework.java:199)
	at compiler.c2.irTests.TestSuperwordFailsUnrolling.main(TestSuperwordFailsUnrolling.java:48)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:577)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.base/java.lang.Thread.run(Thread.java:828)
Caused by: java.nio.file.FileSystemException: sun\\hotspot\\WhiteBox.class: The process cannot access the file because it is being used by another process
	at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
	at java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:275)
	at java.base/sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:110)
	at java.base/java.nio.file.Files.deleteIfExists(Files.java:1191)
	at java.base/java.nio.file.Files.copy(Files.java:3149)
	at jdk.test.lib.helpers.ClassFileInstaller.writeToDisk(ClassFileInstaller.java:296)
	at jdk.test.lib.helpers.ClassFileInstaller.writeClassToDisk(ClassFileInstaller.java:255)
	at jdk.test.lib.helpers.ClassFileInstaller.writeClassToDisk(ClassFileInstaller.java:237)
	at jdk.test.lib.helpers.ClassFileInstaller.writeClassToDisk(ClassFileInstaller.java:234)
	at jdk.test.lib.helpers.ClassFileInstaller.main(ClassFileInstaller.java:97)
	at compiler.lib.ir_framework.TestFramework.installWhiteBox(TestFramework.java:527)
	... 8 more



Weird but reproducible.

-------------

Changes requested by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7822

From thartmann at openjdk.java.net  Wed Mar 23 07:25:29 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Mar 2022 07:25:29 GMT
Subject: RFR: 8281222: ciTypeFlow::profiled_count fails
 "assert(0 <= i && i < _len) failed: illegal index"
In-Reply-To: <TsG0o1zrQRvR93tubXro8EBe2KOvuEmEHVsSci5iiek=.05c25bab-4a8e-4141-827c-5d9cde29cb06@github.com>
References: <TsG0o1zrQRvR93tubXro8EBe2KOvuEmEHVsSci5iiek=.05c25bab-4a8e-4141-827c-5d9cde29cb06@github.com>
Message-ID: <ZUGCTsmKxKsoJch1Dgtz4vQ_pDpO2z9hgX19wnqgEoQ=.4c847000-68a7-40e2-81f8-ba87b924f3d3@github.com>

On Mon, 21 Mar 2022 14:45:40 GMT, Rickard B?ckman <rbackman at openjdk.org> wrote:

> This failed in Project Loom with a specific version of TestNG. 
> 
> The root cause is that the block that is considered tail doesn't have any _successors, but a couple of _exception "successors".

Looks good. I added the `noreg-hard` label.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7892

From thartmann at openjdk.java.net  Wed Mar 23 07:33:38 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Mar 2022 07:33:38 GMT
Subject: RFR: 8283187: C2: loop candidate for superword not always unrolled
 fully if superword fails [v2]
In-Reply-To: <6etwB55nudBQgU6N-1hK35AO0h3uoZo_rnbseKrOUg4=.79af9aa5-3c64-48ff-93c3-81b7455169c8@github.com>
References: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
 <6etwB55nudBQgU6N-1hK35AO0h3uoZo_rnbseKrOUg4=.79af9aa5-3c64-48ff-93c3-81b7455169c8@github.com>
Message-ID: <BckDP_M_Cs6XNpgVInICnn1-bTzyqntQ_KytU6ezw2I=.2e493450-6d2b-46dc-a298-38a72cc58c3b@github.com>

On Tue, 22 Mar 2022 12:18:22 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> IdealLoopTree::policy_unroll_slp_analysis() restricts unrolling of
>> loops that are found to be candidate for superword but if superword
>> then fails, unrolling doesn't always resume. SuperWord::output() has
>> logic for that in one of the failure paths but some other paths are
>> not covered (for instance in the case of the test case). I propose
>> that superword explictly returns whether it succeeded or not and that
>> in case of failure, for a main loop, unrolling be attempted again.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/compiler/c2/irTests/TestSuperwordFailsUnrolling.java
>   
>   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

Let me try to reproduce with `-DSkipWhiteBoxInstall=true`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7822

From thartmann at openjdk.java.net  Wed Mar 23 07:39:28 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Mar 2022 07:39:28 GMT
Subject: RFR: 8283187: C2: loop candidate for superword not always unrolled
 fully if superword fails [v2]
In-Reply-To: <6etwB55nudBQgU6N-1hK35AO0h3uoZo_rnbseKrOUg4=.79af9aa5-3c64-48ff-93c3-81b7455169c8@github.com>
References: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
 <6etwB55nudBQgU6N-1hK35AO0h3uoZo_rnbseKrOUg4=.79af9aa5-3c64-48ff-93c3-81b7455169c8@github.com>
Message-ID: <9EEYnVHi2cFqRTT6ZgtUptwxRi8c6n1NREAeCRoCuQA=.4fec6b58-2023-4253-8bee-d42e779d4911@github.com>

On Tue, 22 Mar 2022 12:18:22 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> IdealLoopTree::policy_unroll_slp_analysis() restricts unrolling of
>> loops that are found to be candidate for superword but if superword
>> then fails, unrolling doesn't always resume. SuperWord::output() has
>> logic for that in one of the failure paths but some other paths are
>> not covered (for instance in the case of the test case). I propose
>> that superword explictly returns whether it succeeded or not and that
>> in case of failure, for a main loop, unrolling be attempted again.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/compiler/c2/irTests/TestSuperwordFailsUnrolling.java
>   
>   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

This fixes the issue:

- * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI compiler.c2.irTests.TestSuperwordFailsUnrolling
+ * @run main/othervm -Xbootclasspath/a:. -DSkipWhiteBoxInstall=true -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI compiler.c2.irTests.TestSuperwordFailsUnrolling


@chhagedorn Maybe the IR verification framework could detect this automatically?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7822

From chagedorn at openjdk.java.net  Wed Mar 23 07:46:31 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 23 Mar 2022 07:46:31 GMT
Subject: RFR: 8283187: C2: loop candidate for superword not always unrolled
 fully if superword fails [v2]
In-Reply-To: <9EEYnVHi2cFqRTT6ZgtUptwxRi8c6n1NREAeCRoCuQA=.4fec6b58-2023-4253-8bee-d42e779d4911@github.com>
References: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
 <6etwB55nudBQgU6N-1hK35AO0h3uoZo_rnbseKrOUg4=.79af9aa5-3c64-48ff-93c3-81b7455169c8@github.com>
 <9EEYnVHi2cFqRTT6ZgtUptwxRi8c6n1NREAeCRoCuQA=.4fec6b58-2023-4253-8bee-d42e779d4911@github.com>
Message-ID: <24nf6_yFViCZrIE1-nLB2tROTDAdh-vNR6wGePWCidY=.5a671739-34a4-42a7-a7e9-a3cc7243d1e3@github.com>

On Wed, 23 Mar 2022 07:36:20 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> This fixes the issue:
> 
> ```
> - * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI compiler.c2.irTests.TestSuperwordFailsUnrolling
> + * @run main/othervm -Xbootclasspath/a:. -DSkipWhiteBoxInstall=true -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI compiler.c2.irTests.TestSuperwordFailsUnrolling
> ```
> 
> @chhagedorn Maybe the IR verification framework could detect this automatically?

Yes, it would be good to extend the framework to handle this. I added this `-DSkipWhiteBoxInstall` flag at some point to prevent the problem above but was more of a quick fix. I will follow up with an RFE to make this better without the need to use `-DSkipWhiteBoxInstall`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7822

From thartmann at openjdk.java.net  Wed Mar 23 07:53:36 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Mar 2022 07:53:36 GMT
Subject: RFR: 8281429: PhiNode::Value() is too conservative for tripcount
 of CountedLoop [v3]
In-Reply-To: <yQBdmbDtfQ0j88ZmjXatbThlIaiCt_pdGEpf9zy7ajE=.fce1a178-9a6b-471a-b4f5-79eceadfbc51@github.com>
References: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
 <yQBdmbDtfQ0j88ZmjXatbThlIaiCt_pdGEpf9zy7ajE=.fce1a178-9a6b-471a-b4f5-79eceadfbc51@github.com>
Message-ID: <YdS_vJ-n7bCZfYG0cVgSPgF-DrJ5GZSowPCjhzXTm2A=.08613d8a-6117-4844-a059-293c48ac9ff2@github.com>

On Tue, 22 Mar 2022 13:08:33 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The type for the iv phi of a counted loop is computed from the types
>> of the phi on loop entry and the type of the limit from the exit
>> test. Because the exit test is applied to the iv after increment, the
>> type of the iv phi is at least one less than the limit (for a positive
>> stride, one more for a negative stride).
>> 
>> Also, for a stride whose absolute value is not 1 and constant init and
>> limit values, it's possible to compute accurately the iv phi type.
>> 
>> This change caused a few failures and I had to make a few adjustments
>> to loop opts code as well.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into JDK-8281429
>  - Update src/hotspot/share/opto/cfgnode.cpp
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - Update src/hotspot/share/opto/cfgnode.cpp
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - Update src/hotspot/share/opto/loopnode.cpp
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - Update src/hotspot/share/opto/loopnode.cpp
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - fix & test

The following test triggers `assert(hi->hi_as_long() > lo->lo_as_long()) failed: no iterations?` when executed with `-XX:-TieredCompilation -Xbatch`:

``` 
public class Test {
    public static void main(String[] args) {
        for (long l = (Long.MAX_VALUE - 1); l != (Long.MIN_VALUE + 100_000); l++) {
            if (l == 0) {
                throw new RuntimeException("Test failed");
            }
        }
    }
}


Please add it as regression test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7823

From rcastanedalo at openjdk.java.net  Wed Mar 23 08:20:57 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 23 Mar 2022 08:20:57 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v2]
In-Reply-To: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
Message-ID: <uC10KRDlMqu_NSFuCyjYxb8UKUAB6A6AKAaI428zacs=.5d160a52-f1f7-4d52-a0e9-a08db63b573f@github.com>

> This change adds a new view to the Ideal Graph Visualizer showing a classic control-flow graph (CFG) where nodes are serialized within basic blocks and arcs across basic blocks represent control flow:
> 
> ![cfg](https://user-images.githubusercontent.com/8792647/158367227-1ccfb9e0-bba1-4a80-963e-3e8c5f23c1c4.png)
> 
> The CFG provides a higher-level, more compact view of the graph than the existing views, where it can be hard to see the overall structure for all but the smallest graphs:
> 
> ![sea-vs-cfg](https://user-images.githubusercontent.com/8792647/158366842-f32b1b22-f7ed-4404-bb43-9d5c58a98ec4.png)
> 
> ![clusters-vs-cfg](https://user-images.githubusercontent.com/8792647/158366861-64561cfa-2553-4c9e-ad59-25acce6b4961.png)
> 
> If a schedule is available in the input graph (because it corresponds to the _Global code motion_ phase or later), the CFG, including the serialization of nodes within basic blocks, is derived from it. Otherwise, the CFG is approximated by the C2-specific `ServerCompilerScheduler` class. Dependencies among nodes are shown textually, by extending the label of each node with a list of its inputs:
> 
> <p align="center">
>     <img width="35%" src="https://user-images.githubusercontent.com/8792647/158367428-5aa222e9-6a5c-4e78-871f-853e5b918599.png">
> </p>
> 
> The exact information shown about each input can be configured in Tools -> Options -> Tiny Node Text.
> 
> The new CFG view is available at the same level as the existing "sea of nodes" (default) and "clustered sea-of-nodes" views. The view can be selected from the main toolbar:
> 
> ![toolbar](https://user-images.githubusercontent.com/8792647/158367502-ac8d8a29-5f35-4604-acc3-9d563c60e917.png)
> 
> The default view shown when opening a new graph can be configured in Tools -> Options -> Default View.
> 
> The same functionality available for the existing views also applies to the new CFG:
> 
> - node extraction:
> 
> ![node-extraction](https://user-images.githubusercontent.com/8792647/158371016-f7988eb6-368f-4805-ac7a-2b5611d16d7a.png)
> 
> - pop-up information on edges:
> 
> ![popup](https://user-images.githubusercontent.com/8792647/158367664-495189d5-384c-4b86-a62b-08863420c531.png)
> 
> - filtering:
> 
> ![filtering](https://user-images.githubusercontent.com/8792647/158367690-47b95bcd-7e8e-466e-b71b-f3e7d04c60ac.png)
> 
> - quick node and basic block search:
> 
> ![quick-search](https://user-images.githubusercontent.com/8792647/158367717-8bc90027-8ce7-4071-be04-1d67de6c91dd.png)
> 
> - and exporting.
> 
> The list of custom filters is extended with three new block-hiding filters:
> 
> - `Hide root block`: remove root block and hide all back-edges from exiting blocks that clutter the CFG.
> 
> - `Hide uncommon trap blocks`: remove blocks with uncommon traps to simplify following the "hot paths" in the CFG.
> 
> - `Hide exception blocks`: remove blocks that create and throw exceptions to also simplify following the "hot paths" in the CFG.
> 
> When using the CFG view, it is important to keep in mind that, in graphs corresponding to phases earlier than _Global code motion_, the presented CFG is just one of many possible projections of the sea-of-nodes representation, and that this projection is computed by an approximation of what C2 would do if it scheduled the graph at that stage. The approximation has some known limitations ([JDK-8280568](https://bugs.openjdk.java.net/browse/JDK-8280568), [JDK-8282053](https://bugs.openjdk.java.net/browse/JDK-8282053)). Future work should address these and warn the user when the approximated CFG is known to be inaccurate.
> 
> ### Testing
> 
> #### Functionality
> 
> - Tested the above functionality manually on a small selection of graphs.
> 
> - Tested automatically that scheduling (approximating C2's GCM and LCM algorithms) and viewing thousands of graphs in the three views does not trigger any assertion failure (by instrumenting IGV to schedule and view graphs as they are loaded and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).
> 
> #### Performance
> 
> - Measured the scheduling and view creation time for each of the three views on a selection of 22 large graphs (between 2515 and 7329 nodes). On average:
> 
> - The change introduces a slight overhead when creating the existing views (2% and 5% for the clustered and non-clustered sea-of-nodes views). This overhead is due to the introduction of abstractions and data structures required by the CFG view.
> 
> - The new CFG view is considerably faster to create than the existing ones (4.2x and 2.5x faster than the clustered and non-clustered sea-of-nodes views), as it can be expected, since only basic blocks have to be laid out. Furthermore, the CFG view scales better as the size of the graph increases.
> 
> - The change slows down scheduling by 27%. This overhead corresponds to the additional work of approximating C2's LCM, and it is essential for the CFG view. Fortunately, scheduling takes only a fraction of the time needed to create a view (typically no more than a third), and it only needs to run once for each graph, whereas views have to be re-created on node extraction, filtering, etc.
> 
> The performance results are [attached](https://github.com/openjdk/jdk/files/8252786/performance-evaluation.ods) (note that each measurement in the sheet corresponds to the median of ten runs).

Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:

  Refactor code as suggested by Christian

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7817/files
  - new: https://git.openjdk.java.net/jdk/pull/7817/files/481afcf0..7b78cd7f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7817&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7817&range=00-01

  Stats: 428 lines in 27 files changed: 117 ins; 211 del; 100 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7817.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7817/head:pull/7817

PR: https://git.openjdk.java.net/jdk/pull/7817

From rcastanedalo at openjdk.java.net  Wed Mar 23 08:27:29 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 23 Mar 2022 08:27:29 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v2]
In-Reply-To: <2biNIQgrADSLZbAdbSDGvSpAnO8NdJLHRsRWHAhNYpw=.491f9738-9678-4412-b615-1b741b4364ed@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <2biNIQgrADSLZbAdbSDGvSpAnO8NdJLHRsRWHAhNYpw=.491f9738-9678-4412-b615-1b741b4364ed@github.com>
Message-ID: <DVZNOdv_9InW27gwCRhDdia6KHCPFgGauVRMwXebz5Q=.965a7380-6441-4576-8663-63fcb1e4c193@github.com>

On Thu, 17 Mar 2022 07:46:49 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor code as suggested by Christian
>
> src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Connection.java line 38:
> 
>> 36:     }
>> 37: 
>> 38:     public ConnectionStyle getStyle();
> 
> `public` is implied for interface methods and does not need to be stated explicitly.

I declared it explicitly as `public` for consistency with the rest of the IGV project. Updating all interfaces would be better addressed in a separate cleanup RFE, I think.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7817

From rcastanedalo at openjdk.java.net  Wed Mar 23 08:32:36 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 23 Mar 2022 08:32:36 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v2]
In-Reply-To: <2biNIQgrADSLZbAdbSDGvSpAnO8NdJLHRsRWHAhNYpw=.491f9738-9678-4412-b615-1b741b4364ed@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <2biNIQgrADSLZbAdbSDGvSpAnO8NdJLHRsRWHAhNYpw=.491f9738-9678-4412-b615-1b741b4364ed@github.com>
Message-ID: <AP28-EuNy9LNKZbih3TIyYrBqWpp6go4PCTrXcIkBSE=.f07eb21a-9c08-4efb-9d8c-c95531947787@github.com>

On Thu, 17 Mar 2022 10:03:17 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor code as suggested by Christian
>
> src/utils/IdealGraphVisualizer/Layout/src/main/java/com/sun/hotspot/igv/layout/Link.java line 37:
> 
>> 35:     public Port getFrom();
>> 36: 
>> 37:     public Cluster getFromCluster();
> 
> `public` can be removed for interface methods.

I declared it explicitly as `public` for consistency with the rest of the IGV project, see my earlier reply.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7817

From rcastanedalo at openjdk.java.net  Wed Mar 23 08:47:39 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 23 Mar 2022 08:47:39 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v2]
In-Reply-To: <2biNIQgrADSLZbAdbSDGvSpAnO8NdJLHRsRWHAhNYpw=.491f9738-9678-4412-b615-1b741b4364ed@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <2biNIQgrADSLZbAdbSDGvSpAnO8NdJLHRsRWHAhNYpw=.491f9738-9678-4412-b615-1b741b4364ed@github.com>
Message-ID: <FTJZ4F6MELOrIZlzsHXFDgk0Ns5V6I9pJYQNQ7E4AB0=.d6074900-ff00-4a98-b6d9-b151d109c776@github.com>

On Thu, 17 Mar 2022 08:38:07 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor code as suggested by Christian
>
> src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/FigureConnection.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2008, 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Should only be 2022 for a new file.

This file is not really new, only renamed from the old `Connection.java` and slightly updated, hence I think it makes sense to leave the original initial year.

> src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/FigureConnection.java line 35:
> 
>> 33: /**
>> 34:  *
>> 35:  * @author Thomas Wuerthinger
> 
> You should take credit of this class instead ;-)

The file is not really new but renamed, I only updated it slightly, so I think the author tag is still relevant.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7817

From rcastanedalo at openjdk.java.net  Wed Mar 23 09:00:33 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 23 Mar 2022 09:00:33 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v2]
In-Reply-To: <2biNIQgrADSLZbAdbSDGvSpAnO8NdJLHRsRWHAhNYpw=.491f9738-9678-4412-b615-1b741b4364ed@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <2biNIQgrADSLZbAdbSDGvSpAnO8NdJLHRsRWHAhNYpw=.491f9738-9678-4412-b615-1b741b4364ed@github.com>
Message-ID: <-HZVOA3gRrIK-0wfiFH4_XhJW5kfo_Bi9ev3bTwVIgE=.96261e75-bebc-4a8f-a74d-54a5945cd7ac@github.com>

On Wed, 16 Mar 2022 21:29:25 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor code as suggested by Christian
>
> src/utils/IdealGraphVisualizer/Graal/src/main/java/com/sun/hotspot/igv/graal/filters/GraalEdgeColorFilter.java line 63:
> 
>> 61:                     String type = null;
>> 62: 
>> 63:                     if (type != null) {
> 
> This block is dead since `type` is `null`. Is this intended?

I removed the method `Connection::getType()` and the code that depends on it in the Graal filters (the only place where this method was used). The Graal filters are not used and should just get removed, since HotSpot IGV does not support Graal anymore (a specific IGV variant is available for Graal, see https://www.graalvm.org/advanced-tools/). I will file a separate cleanup RFE for that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7817

From rcastanedalo at openjdk.java.net  Wed Mar 23 09:14:39 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 23 Mar 2022 09:14:39 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v2]
In-Reply-To: <2biNIQgrADSLZbAdbSDGvSpAnO8NdJLHRsRWHAhNYpw=.491f9738-9678-4412-b615-1b741b4364ed@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <2biNIQgrADSLZbAdbSDGvSpAnO8NdJLHRsRWHAhNYpw=.491f9738-9678-4412-b615-1b741b4364ed@github.com>
Message-ID: <uooewZZ6VkMc9mEFILnZwkEtbW8X5dzMEwY3DgvP4-U=.5009252a-f688-4a39-b497-f92e7c3a642c@github.com>

On Wed, 16 Mar 2022 15:33:20 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor code as suggested by Christian
>
> src/utils/IdealGraphVisualizer/ServerCompiler/src/main/resources/com/sun/hotspot/igv/servercompiler/filters/hideExceptionBlocks.filter line 4:
> 
>> 2: 
>> 3: var f = new RemoveBlockFilter("Hide exception blocks");
>> 4: f.addRule(
> 
> Could the rule object directly be passed to the constructor instead of going over `addRule()`? On top of that, all filters follow the pattern "create f + `f.apply(graph)`". This could be moved into a single method to simplify filters. But this would exceed the scope of this change and could be done in a separate RFE.

A filter can consist of multiple rules, see e.g. `ServerCompiler/src/main/resources/com/sun/hotspot/igv/servercompiler/filters/structural.filter`, so I think it makes sense to pass them separately. What could be done to reduce this complexity is to define more helper methods in `Filter/src/main/resources/com/sun/hotspot/igv/filter/helper.js`. As you suggest, I think this would be best done for all filters at once in a separate RFE.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7817

From rcastanedalo at openjdk.java.net  Wed Mar 23 09:26:31 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 23 Mar 2022 09:26:31 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v2]
In-Reply-To: <uC10KRDlMqu_NSFuCyjYxb8UKUAB6A6AKAaI428zacs=.5d160a52-f1f7-4d52-a0e9-a08db63b573f@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <uC10KRDlMqu_NSFuCyjYxb8UKUAB6A6AKAaI428zacs=.5d160a52-f1f7-4d52-a0e9-a08db63b573f@github.com>
Message-ID: <3P9LWndw6QnlVMbh8zrv8kxTI5MApnYTsS4nhUwGlHc=.3328e44e-2feb-482e-9e53-584ae6c59851@github.com>

On Wed, 23 Mar 2022 08:20:57 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change adds a new view to the Ideal Graph Visualizer showing a classic control-flow graph (CFG) where nodes are serialized within basic blocks and arcs across basic blocks represent control flow:
>> 
>> ![cfg](https://user-images.githubusercontent.com/8792647/158367227-1ccfb9e0-bba1-4a80-963e-3e8c5f23c1c4.png)
>> 
>> The CFG provides a higher-level, more compact view of the graph than the existing views, where it can be hard to see the overall structure for all but the smallest graphs:
>> 
>> ![sea-vs-cfg](https://user-images.githubusercontent.com/8792647/158366842-f32b1b22-f7ed-4404-bb43-9d5c58a98ec4.png)
>> 
>> ![clusters-vs-cfg](https://user-images.githubusercontent.com/8792647/158366861-64561cfa-2553-4c9e-ad59-25acce6b4961.png)
>> 
>> If a schedule is available in the input graph (because it corresponds to the _Global code motion_ phase or later), the CFG, including the serialization of nodes within basic blocks, is derived from it. Otherwise, the CFG is approximated by the C2-specific `ServerCompilerScheduler` class. Dependencies among nodes are shown textually, by extending the label of each node with a list of its inputs:
>> 
>> <p align="center">
>>     <img width="35%" src="https://user-images.githubusercontent.com/8792647/158367428-5aa222e9-6a5c-4e78-871f-853e5b918599.png">
>> </p>
>> 
>> The exact information shown about each input can be configured in Tools -> Options -> Tiny Node Text.
>> 
>> The new CFG view is available at the same level as the existing "sea of nodes" (default) and "clustered sea-of-nodes" views. The view can be selected from the main toolbar:
>> 
>> ![toolbar](https://user-images.githubusercontent.com/8792647/158367502-ac8d8a29-5f35-4604-acc3-9d563c60e917.png)
>> 
>> The default view shown when opening a new graph can be configured in Tools -> Options -> Default View.
>> 
>> The same functionality available for the existing views also applies to the new CFG:
>> 
>> - node extraction:
>> 
>> ![node-extraction](https://user-images.githubusercontent.com/8792647/158371016-f7988eb6-368f-4805-ac7a-2b5611d16d7a.png)
>> 
>> - pop-up information on edges:
>> 
>> ![popup](https://user-images.githubusercontent.com/8792647/158367664-495189d5-384c-4b86-a62b-08863420c531.png)
>> 
>> - filtering:
>> 
>> ![filtering](https://user-images.githubusercontent.com/8792647/158367690-47b95bcd-7e8e-466e-b71b-f3e7d04c60ac.png)
>> 
>> - quick node and basic block search:
>> 
>> ![quick-search](https://user-images.githubusercontent.com/8792647/158367717-8bc90027-8ce7-4071-be04-1d67de6c91dd.png)
>> 
>> - and exporting.
>> 
>> The list of custom filters is extended with three new block-hiding filters:
>> 
>> - `Hide root block`: remove root block and hide all back-edges from exiting blocks that clutter the CFG.
>> 
>> - `Hide uncommon trap blocks`: remove blocks with uncommon traps to simplify following the "hot paths" in the CFG.
>> 
>> - `Hide exception blocks`: remove blocks that create and throw exceptions to also simplify following the "hot paths" in the CFG.
>> 
>> When using the CFG view, it is important to keep in mind that, in graphs corresponding to phases earlier than _Global code motion_, the presented CFG is just one of many possible projections of the sea-of-nodes representation, and that this projection is computed by an approximation of what C2 would do if it scheduled the graph at that stage. The approximation has some known limitations ([JDK-8280568](https://bugs.openjdk.java.net/browse/JDK-8280568), [JDK-8282053](https://bugs.openjdk.java.net/browse/JDK-8282053)). Future work should address these and warn the user when the approximated CFG is known to be inaccurate.
>> 
>> ### Testing
>> 
>> #### Functionality
>> 
>> - Tested the above functionality manually on a small selection of graphs.
>> 
>> - Tested automatically that scheduling (approximating C2's GCM and LCM algorithms) and viewing thousands of graphs in the three views does not trigger any assertion failure (by instrumenting IGV to schedule and view graphs as they are loaded and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).
>> 
>> #### Performance
>> 
>> - Measured the scheduling and view creation time for each of the three views on a selection of 22 large graphs (between 2515 and 7329 nodes). On average:
>> 
>> - The change introduces a slight overhead when creating the existing views (2% and 5% for the clustered and non-clustered sea-of-nodes views). This overhead is due to the introduction of abstractions and data structures required by the CFG view.
>> 
>> - The new CFG view is considerably faster to create than the existing ones (4.2x and 2.5x faster than the clustered and non-clustered sea-of-nodes views), as it can be expected, since only basic blocks have to be laid out. Furthermore, the CFG view scales better as the size of the graph increases.
>> 
>> - The change slows down scheduling by 27%. This overhead corresponds to the additional work of approximating C2's LCM, and it is essential for the CFG view. Fortunately, scheduling takes only a fraction of the time needed to create a view (typically no more than a third), and it only needs to run once for each graph, whereas views have to be re-created on node extraction, filtering, etc.
>> 
>> The performance results are [attached](https://github.com/openjdk/jdk/files/8252786/performance-evaluation.ods) (note that each measurement in the sheet corresponds to the median of ten runs).
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor code as suggested by Christian

Thanks Christian for reviewing and providing so many suggestions! I have implemented all of them except a few for which I have provided separate answers.

> The only thing I've noticed in the compact CFG view: When extracting a node, it shows all the empty blocks of the entire graph. I would have expected that empty blocks that are neither in- nor outputs of the extracted node are hidden. But I think that could also be potentially handled in a separate RFE and should not block this change.

This is actually deliberate, I thought it would be useful to preserve the control-flow context, so that the user can at all times know e.g. whether a block she is looking at is within a loop. Having said that, I agree that sometimes, particularly for large graphs, it would be useful to hide the empty blocks. This behavior would also be more consistent with the clustered sea-of-nodes view. Would it make sense to add a toolbar button to hide/show empty blocks in the control-flow graph view? If you think so, I will create a RFE to do that separately.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7817

From ihse at openjdk.java.net  Wed Mar 23 09:35:28 2022
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 23 Mar 2022 09:35:28 GMT
Subject: RFR: 8283519: Hsdis with capstone should annotate output
In-Reply-To: <cFqhmme_HJNYQKvYv9gW3ADqO1NGEDsSWdRxiLgVL7E=.9afd0736-6ff3-4077-8372-c7d83cfa4875@github.com>
References: <cFqhmme_HJNYQKvYv9gW3ADqO1NGEDsSWdRxiLgVL7E=.9afd0736-6ff3-4077-8372-c7d83cfa4875@github.com>
Message-ID: <SBwHL-lAnACVEPVTuXkTKKYtidk5mK4nMU6Ogk5YCf0=.1de8e5fc-8527-4ad1-a5e8-57174392ed9d@github.com>

On Tue, 22 Mar 2022 15:20:38 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Sample output after the changes:
> 
> [Stub Code]
>   0x000001cd0a937e20:   nopl		(%rax, %rax)        ;   {no_reloc}
>   0x000001cd0a937e25:   movabsq		$0x0, %rbx          ;   {static_stub}
>   0x000001cd0a937e2f:   jmp		0x1cd0a937e2f       ;   {runtime_call}
> [Exception Handler]
>   0x000001cd0a937e34:   callq		0x1cd0a3ca480       ;   {runtime_call handle_exception_from_callee Runtime1 stub}
>   0x000001cd0a937e39:   movabsq		$0x7ff8df21a850, %rcx;   {external_word}
>   0x000001cd0a937e43:   andq		$0xfffffffffffffff0, %rsp
>   0x000001cd0a937e47:   movabsq		$0x7ff8deef30c0, %r10;   {runtime_call MacroAssembler::debug64}
>   0x000001cd0a937e51:   callq		*%r10
>   0x000001cd0a937e54:   hlt		
> [Deopt Handler Code]
>   0x000001cd0a937e55:   movabsq		$0x1cd0a937e55, %r10;   {section_word}
>   0x000001cd0a937e5f:   pushq		%r10
>   0x000001cd0a937e61:   jmp		0x1cd0a325ca0       ;   {runtime_call DeoptimizationBlob}
>   0x000001cd0a937e66:   hlt		
>   0x000001cd0a937e67:   hlt		
> 
> before the changes none of the annotations (like `[Stub Code]` or `;   {no_reloc}`) were present.

Thank you for fixing this! The original capstone implementation was mostly a stub.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7904

From duke at openjdk.java.net  Wed Mar 23 09:44:43 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 23 Mar 2022 09:44:43 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v12]
In-Reply-To: <ipzQF1uR_cuz1f7hI8RZ1HhokXaf6VGYGhx58h2VVQQ=.78863db8-b67f-4835-af92-e32c1a524353@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <ipzQF1uR_cuz1f7hI8RZ1HhokXaf6VGYGhx58h2VVQQ=.78863db8-b67f-4835-af92-e32c1a524353@github.com>
Message-ID: <3v5Yq9LMp56hI_ZkLFdGSrtavJCAa_1le502WfiNrW0=.e277fdb5-1b36-435e-91b2-3dd0e64f5605@github.com>

On Sat, 12 Mar 2022 04:52:41 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into leaIns
>  - reviews
>  - remove unreached rules
>  - remove 0x67 prefix
>  - address reviews
>  - remove irrelevent changes
>  - reviews
>  - address reviews
>  - add benchmark
>  - add predicate
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/0181756e...e0fd81f6

Thank you all very much for the really valuable discussions, I have learnt a lot from those.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From duke at openjdk.java.net  Wed Mar 23 09:48:40 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Wed, 23 Mar 2022 09:48:40 GMT
Subject: Integrated: 8282204: Use lea instructions for arithmetic operations on
 x86_64
In-Reply-To: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
Message-ID: <fftCIF72YnhJMGId-mrryQ_JjYZWkIb9dZ3bTR9HZ4E=.9207ae00-b95d-45ee-8d7c-62ea2a1f7ab4@github.com>

On Mon, 21 Feb 2022 15:54:47 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> Hi,
> 
> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
> 
> Thank you very much.

This pull request has now been integrated.

Changeset: d8c55725
Author:    Quan Anh Mai <anhmdq99 at gmail.com>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d8c55725e0f85e21c16bb81e3f1a9bcfacc59f87
Stats:     297 lines in 4 files changed: 271 ins; 15 del; 11 mod

8282204: Use lea instructions for arithmetic operations on x86_64

Reviewed-by: jiefu, sviswanathan, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From thartmann at openjdk.java.net  Wed Mar 23 12:02:38 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 23 Mar 2022 12:02:38 GMT
Subject: RFR: 8279888: Local variable independently used by multiple loops
 can interfere with loop optimizations [v4]
In-Reply-To: <YJhxTTOGOtTUtWTphu86IpfbSRsXEqvXxUHwwmbafuI=.cdbc0230-d32a-4da1-b1ca-e2a46a2e0b15@github.com>
References: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
 <YJhxTTOGOtTUtWTphu86IpfbSRsXEqvXxUHwwmbafuI=.cdbc0230-d32a-4da1-b1ca-e2a46a2e0b15@github.com>
Message-ID: <VEXGz4PU7VsMmt7aVt6BqBBgc21ofvEOtZmf9qVmtIs=.7961652c-456f-48dc-bc3d-3276ef0f2a4f@github.com>

On Tue, 22 Mar 2022 12:45:12 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The bytecode of the 2 methods of the benchmark is structured
>> differently: loopsWithSharedLocal(), the slowest one, has multiple
>> backedges with a single head while loopsWithScopedLocal() has a single
>> backedge and all the paths in the loop body merge before the
>> backedge. loopsWithSharedLocal() has its head cloned which results in
>> a 2 loops loop nest.
>> 
>> loopsWithSharedLocal() is slow when 2 of the backedges are most
>> commonly taken with one taken only 3 times as often as the other
>> one. So a thread executing that code only runs the inner loop for a
>> few iterations before exiting it and executing the outer loop. I think
>> what happens is that any time the inner loop is entered, some
>> predicates are executed and the overhead of the setup of loop strip
>> mining (if it's enabled) has to be paid. Also, if iteration
>> splitting/unrolling was applied, the main loop is likely never
>> executed and all time is spent in the pre/post loops where potentially
>> some range checks remain.
>> 
>> The fix I propose is that ciTypeFlow, when it clone heads, not only
>> rewires the most frequent loop but also all this other frequent loops
>> that share the same head. loopsWithSharedLocal() and
>> loopsWithScopedLocal() are then fairly similar once c2 parses them.
>> 
>> Without the patch I measure:
>> 
>> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.874 ? 250.463  ns/op
>> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1575.665 ?  70.372  ns/op
>> 
>> with it:
>> 
>> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.180 ? 245.873  ns/op
>> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1234.665 ? 157.912  ns/op
>> 
>> But this patch also causes a regression when running one of the
>> benchmarks added by 8278518. From:
>> 
>> SharedLoopHeader.sharedHeader  avgt    5  505.993 ? 44.126  ns/op
>> 
>> to:
>> 
>> SharedLoopHeader.sharedHeader  avgt    5  724.253 ? 1.664  ns/op
>> 
>> The hot method of this benchmark used to be compiled with 2 loops, the
>> inner one a counted loop. With the patch, it's now compiled with a
>> single one which can't be converted into a counted loop because the
>> loop variable is incremented by a different amount along the 2 paths
>> in the loop body. What I propose to fix this is to add a new loop
>> transformation that detects that, because of a merge point, a loop
>> can't be turned into a counted loop and transforms it into 2
>> loops. The benchmark performs better with this:
>> 
>> SharedLoopHeader.sharedHeader  avgt    5  567.150 ? 6.120  ns/op
>> 
>> Not quite on par with the previous score but AFAICT this is due to
>> code generation not being as good (the loop head can't be aligned in
>> particular).
>> 
>> In short, I propose:
>> 
>> - changing ciTypeFlow so that, when it pays off, a loop with
>> multiple backedges is compiled as a single loop with a merge point in
>> the loop body
>> 
>> - adding a new loop transformation so that, when it pays off, a loop
>> with a merge point in the loop body is converted into a 2 loops loop
>> nest, essentially the opposite transformation.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into JDK-8279888
>  - Merge commit '44327da170c57ccd31bfad379738c7f00e67f4c1' into JDK-8279888
>  - Update src/hotspot/share/opto/loopopts.cpp
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - Update src/hotspot/share/opto/loopopts.cpp
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - Merge branch 'master' into JDK-8279888
>  - Merge branch 'master' into JDK-8279888
>  - fix
>  - Merge branch 'master' into JDK-8279888
>  - whitespaces
>  - fix & test

`compiler/intrinsics/unsafe/HeapByteBufferTest.java` fails with `-XX:+StressDuplicateBackedge`:


# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (...workspace/open/src/hotspot/share/opto/macroArrayCopy.cpp:1277), pid=23931, tid=23946
#  assert(alloc != __null) failed: expect alloc
#
# JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-03-23-1109324.tobias.hartmann.jdk2)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-03-23-1109324.tobias.hartmann.jdk2, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x13f86f5]  PhaseMacroExpand::expand_arraycopy_node(ArrayCopyNode*)+0x10a

-------------

PR: https://git.openjdk.java.net/jdk/pull/7352

From jvernee at openjdk.java.net  Wed Mar 23 12:18:33 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 23 Mar 2022 12:18:33 GMT
Subject: RFR: 8283519: Hsdis with capstone should annotate output
In-Reply-To: <cFqhmme_HJNYQKvYv9gW3ADqO1NGEDsSWdRxiLgVL7E=.9afd0736-6ff3-4077-8372-c7d83cfa4875@github.com>
References: <cFqhmme_HJNYQKvYv9gW3ADqO1NGEDsSWdRxiLgVL7E=.9afd0736-6ff3-4077-8372-c7d83cfa4875@github.com>
Message-ID: <Hjy6D8zka6rRdWXcFAzFZFpjn_AYwVhJxwMbxxbALUQ=.264cd1bb-64db-44d3-8e4a-2f88c5f6f010@github.com>

On Tue, 22 Mar 2022 15:20:38 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Sample output after the changes:
> 
> [Stub Code]
>   0x000001cd0a937e20:   nopl		(%rax, %rax)        ;   {no_reloc}
>   0x000001cd0a937e25:   movabsq		$0x0, %rbx          ;   {static_stub}
>   0x000001cd0a937e2f:   jmp		0x1cd0a937e2f       ;   {runtime_call}
> [Exception Handler]
>   0x000001cd0a937e34:   callq		0x1cd0a3ca480       ;   {runtime_call handle_exception_from_callee Runtime1 stub}
>   0x000001cd0a937e39:   movabsq		$0x7ff8df21a850, %rcx;   {external_word}
>   0x000001cd0a937e43:   andq		$0xfffffffffffffff0, %rsp
>   0x000001cd0a937e47:   movabsq		$0x7ff8deef30c0, %r10;   {runtime_call MacroAssembler::debug64}
>   0x000001cd0a937e51:   callq		*%r10
>   0x000001cd0a937e54:   hlt		
> [Deopt Handler Code]
>   0x000001cd0a937e55:   movabsq		$0x1cd0a937e55, %r10;   {section_word}
>   0x000001cd0a937e5f:   pushq		%r10
>   0x000001cd0a937e61:   jmp		0x1cd0a325ca0       ;   {runtime_call DeoptimizationBlob}
>   0x000001cd0a937e66:   hlt		
>   0x000001cd0a937e67:   hlt		
> 
> before the changes none of the annotations (like `[Stub Code]` or `;   {no_reloc}`) were present.

LGTM

-------------

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7904

From roland at openjdk.java.net  Wed Mar 23 14:00:43 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 23 Mar 2022 14:00:43 GMT
Subject: RFR: 8283187: C2: loop candidate for superword not always unrolled
 fully if superword fails [v3]
In-Reply-To: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
References: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
Message-ID: <ffR0-Knjd8pvP1qsIjyRfhgSyaMyMI5TZj3xIqLlxTA=.117bf87f-3334-4e4c-b192-234a86745bd0@github.com>

> IdealLoopTree::policy_unroll_slp_analysis() restricts unrolling of
> loops that are found to be candidate for superword but if superword
> then fails, unrolling doesn't always resume. SuperWord::output() has
> logic for that in one of the failure paths but some other paths are
> not covered (for instance in the case of the test case). I propose
> that superword explictly returns whether it succeeded or not and that
> in case of failure, for a main loop, unrolling be attempted again.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge commit 'cac6704b8a1791c621918af316250e94047bff43' into JDK-8283187
 - Update test/hotspot/jtreg/compiler/c2/irTests/TestSuperwordFailsUnrolling.java
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - review
 - Merge branch 'master' into JDK-8283187
 - whitespaces
 - fix & test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7822/files
  - new: https://git.openjdk.java.net/jdk/pull/7822/files/cac6704b..8ae4fa52

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7822&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7822&range=01-02

  Stats: 9493 lines in 1121 files changed: 5162 ins; 1775 del; 2556 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7822/head:pull/7822

PR: https://git.openjdk.java.net/jdk/pull/7822

From roland at openjdk.java.net  Wed Mar 23 14:00:44 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 23 Mar 2022 14:00:44 GMT
Subject: RFR: 8283187: C2: loop candidate for superword not always unrolled
 fully if superword fails [v2]
In-Reply-To: <24nf6_yFViCZrIE1-nLB2tROTDAdh-vNR6wGePWCidY=.5a671739-34a4-42a7-a7e9-a3cc7243d1e3@github.com>
References: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
 <6etwB55nudBQgU6N-1hK35AO0h3uoZo_rnbseKrOUg4=.79af9aa5-3c64-48ff-93c3-81b7455169c8@github.com>
 <9EEYnVHi2cFqRTT6ZgtUptwxRi8c6n1NREAeCRoCuQA=.4fec6b58-2023-4253-8bee-d42e779d4911@github.com>
 <24nf6_yFViCZrIE1-nLB2tROTDAdh-vNR6wGePWCidY=.5a671739-34a4-42a7-a7e9-a3cc7243d1e3@github.com>
Message-ID: <OtPe7aKjRnl0kNgp5azJI0snwG3-8L_jPs2JvPZPRvQ=.81bad208-91dd-4cd0-9481-3c3426fe2187@github.com>

On Wed, 23 Mar 2022 07:42:59 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> This fixes the issue:
> 
> ```
> - * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI compiler.c2.irTests.TestSuperwordFailsUnrolling
> + * @run main/othervm -Xbootclasspath/a:. -DSkipWhiteBoxInstall=true -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI compiler.c2.irTests.TestSuperwordFailsUnrolling
> ```

New commit has this change

-------------

PR: https://git.openjdk.java.net/jdk/pull/7822

From roland at openjdk.java.net  Wed Mar 23 14:00:44 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 23 Mar 2022 14:00:44 GMT
Subject: RFR: 8283187: C2: loop candidate for superword not always unrolled
 fully if superword fails [v2]
In-Reply-To: <wKsip6CkZrs7gE-eTTFTN-Odpzbh5slWV8Cy4y2OnyE=.6af162f9-ea40-44ba-a52d-c5d45d2789b1@github.com>
References: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
 <6etwB55nudBQgU6N-1hK35AO0h3uoZo_rnbseKrOUg4=.79af9aa5-3c64-48ff-93c3-81b7455169c8@github.com>
 <wKsip6CkZrs7gE-eTTFTN-Odpzbh5slWV8Cy4y2OnyE=.6af162f9-ea40-44ba-a52d-c5d45d2789b1@github.com>
Message-ID: <0FGWR1qTxE4QdJ5seEWGwPKhIpVvhiagT4cZ6O-uk_c=.7d1390f8-d060-4342-9d4c-a8417e077705@github.com>

On Wed, 23 Mar 2022 07:08:11 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> That looks good!

Thanks for the review @chhagedorn

> src/hotspot/share/opto/superword.cpp line 129:
> 
>> 127:   // skip any loop that has not been assigned max unroll by analysis
>> 128:   if (do_optimization) {
>> 129:     if (SuperWordLoopUnrollAnalysis && cl->slp_max_unroll() == 0) return false;
> 
> While at it, you could also add braces for the one liner ifs.

Should be done in the new commit

-------------

PR: https://git.openjdk.java.net/jdk/pull/7822

From kvn at openjdk.java.net  Wed Mar 23 15:26:41 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 23 Mar 2022 15:26:41 GMT
Subject: RFR: 8282204: Use lea instructions for arithmetic operations on
 x86_64 [v12]
In-Reply-To: <ipzQF1uR_cuz1f7hI8RZ1HhokXaf6VGYGhx58h2VVQQ=.78863db8-b67f-4835-af92-e32c1a524353@github.com>
References: <jVafwAEBpVtcf2jBr9PKF_oex7kTJ4BqC3fnjoEbYHs=.05f8397d-813b-49e8-a099-9788ccbc2d33@github.com>
 <ipzQF1uR_cuz1f7hI8RZ1HhokXaf6VGYGhx58h2VVQQ=.78863db8-b67f-4835-af92-e32c1a524353@github.com>
Message-ID: <wAzOn_05jWUUAaES9KK9CBiTqyNSlvwfKTckyryQWVI=.d3d79e03-7286-4324-b395-b4c515c5f87c@github.com>

On Sat, 12 Mar 2022 04:52:41 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi,
>> 
>> This patch adds several matching rules for x86_64 backend to use `lea` instructions for several fused arithmetic operations. Also, `lea`s don't kill flags and allow different `dst` and `src`, so it is preferred over `sll` if possible, too. 
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into leaIns
>  - reviews
>  - remove unreached rules
>  - remove 0x67 prefix
>  - address reviews
>  - remove irrelevent changes
>  - reviews
>  - address reviews
>  - add benchmark
>  - add predicate
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/f7492774...e0fd81f6

Thank you for using predicates `supports_fast_*op_lea` for these optimizations!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7560

From roland at openjdk.java.net  Wed Mar 23 15:57:51 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 23 Mar 2022 15:57:51 GMT
Subject: RFR: 8279888: Local variable independently used by multiple loops
 can interfere with loop optimizations [v5]
In-Reply-To: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
References: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
Message-ID: <SU6truu67PgUmkn4bGPQ4WSplv7Q0J2GvfuHjYsr-Fk=.645ec4f3-dee6-4a8a-84c4-86380ed4d7a0@github.com>

> The bytecode of the 2 methods of the benchmark is structured
> differently: loopsWithSharedLocal(), the slowest one, has multiple
> backedges with a single head while loopsWithScopedLocal() has a single
> backedge and all the paths in the loop body merge before the
> backedge. loopsWithSharedLocal() has its head cloned which results in
> a 2 loops loop nest.
> 
> loopsWithSharedLocal() is slow when 2 of the backedges are most
> commonly taken with one taken only 3 times as often as the other
> one. So a thread executing that code only runs the inner loop for a
> few iterations before exiting it and executing the outer loop. I think
> what happens is that any time the inner loop is entered, some
> predicates are executed and the overhead of the setup of loop strip
> mining (if it's enabled) has to be paid. Also, if iteration
> splitting/unrolling was applied, the main loop is likely never
> executed and all time is spent in the pre/post loops where potentially
> some range checks remain.
> 
> The fix I propose is that ciTypeFlow, when it clone heads, not only
> rewires the most frequent loop but also all this other frequent loops
> that share the same head. loopsWithSharedLocal() and
> loopsWithScopedLocal() are then fairly similar once c2 parses them.
> 
> Without the patch I measure:
> 
> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.874 ? 250.463  ns/op
> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1575.665 ?  70.372  ns/op
> 
> with it:
> 
> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.180 ? 245.873  ns/op
> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1234.665 ? 157.912  ns/op
> 
> But this patch also causes a regression when running one of the
> benchmarks added by 8278518. From:
> 
> SharedLoopHeader.sharedHeader  avgt    5  505.993 ? 44.126  ns/op
> 
> to:
> 
> SharedLoopHeader.sharedHeader  avgt    5  724.253 ? 1.664  ns/op
> 
> The hot method of this benchmark used to be compiled with 2 loops, the
> inner one a counted loop. With the patch, it's now compiled with a
> single one which can't be converted into a counted loop because the
> loop variable is incremented by a different amount along the 2 paths
> in the loop body. What I propose to fix this is to add a new loop
> transformation that detects that, because of a merge point, a loop
> can't be turned into a counted loop and transforms it into 2
> loops. The benchmark performs better with this:
> 
> SharedLoopHeader.sharedHeader  avgt    5  567.150 ? 6.120  ns/op
> 
> Not quite on par with the previous score but AFAICT this is due to
> code generation not being as good (the loop head can't be aligned in
> particular).
> 
> In short, I propose:
> 
> - changing ciTypeFlow so that, when it pays off, a loop with
> multiple backedges is compiled as a single loop with a merge point in
> the loop body
> 
> - adding a new loop transformation so that, when it pays off, a loop
> with a merge point in the loop body is converted into a 2 loops loop
> nest, essentially the opposite transformation.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - review
 - Merge branch 'master' into JDK-8279888
 - Merge branch 'master' into JDK-8279888
 - Merge commit '44327da170c57ccd31bfad379738c7f00e67f4c1' into JDK-8279888
 - Update src/hotspot/share/opto/loopopts.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - Update src/hotspot/share/opto/loopopts.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - Merge branch 'master' into JDK-8279888
 - Merge branch 'master' into JDK-8279888
 - fix
 - Merge branch 'master' into JDK-8279888
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/91fab6ad...8b20e0cc

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7352/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7352&range=04
  Stats: 1087 lines in 9 files changed: 787 ins; 132 del; 168 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7352.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7352/head:pull/7352

PR: https://git.openjdk.java.net/jdk/pull/7352

From roland at openjdk.java.net  Wed Mar 23 15:57:52 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 23 Mar 2022 15:57:52 GMT
Subject: RFR: 8279888: Local variable independently used by multiple loops
 can interfere with loop optimizations [v4]
In-Reply-To: <VEXGz4PU7VsMmt7aVt6BqBBgc21ofvEOtZmf9qVmtIs=.7961652c-456f-48dc-bc3d-3276ef0f2a4f@github.com>
References: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
 <YJhxTTOGOtTUtWTphu86IpfbSRsXEqvXxUHwwmbafuI=.cdbc0230-d32a-4da1-b1ca-e2a46a2e0b15@github.com>
 <VEXGz4PU7VsMmt7aVt6BqBBgc21ofvEOtZmf9qVmtIs=.7961652c-456f-48dc-bc3d-3276ef0f2a4f@github.com>
Message-ID: <LvcgUv4Tdyj2qnDiQfHZaMm5yJAuUyzLHPgR5PAX34k=.6d4a2691-300f-448c-b601-bf18e7d019ff@github.com>

On Wed, 23 Mar 2022 11:59:40 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> compiler/intrinsics/unsafe/HeapByteBufferTest.java

Thanks for running tests. That one should be fixed now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7352

From duke at openjdk.java.net  Wed Mar 23 16:41:09 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Wed, 23 Mar 2022 16:41:09 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con [v4]
In-Reply-To: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
Message-ID: <qfTxESfX_WRE9ZVbve_hYoV4TU8xtxi73x8BCAAbT-4=.292dcc74-3bc9-46a4-b58a-bc5b1c44e0e4@github.com>

> Hello,
> 
> `x + (con - y)  -> (x - y) + con` is a widely seen pattern; however it is missing in current implementation, which prevents some obvious constant folding from happening, such as `x + (1 - y) + 2` will be not optimized at all, rather than into `x - y + 3`.
> 
> This pull request adds this transformation.

Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:

  rename test cases.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7795/files
  - new: https://git.openjdk.java.net/jdk/pull/7795/files/83c2ce8c..639913f3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7795&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7795&range=02-03

  Stats: 21 lines in 2 files changed: 0 ins; 1 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7795/head:pull/7795

PR: https://git.openjdk.java.net/jdk/pull/7795

From roland at openjdk.java.net  Wed Mar 23 16:41:14 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 23 Mar 2022 16:41:14 GMT
Subject: RFR: 8283187: C2: loop candidate for superword not always unrolled
 fully if superword fails [v4]
In-Reply-To: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
References: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
Message-ID: <_6OmC-dlVJJ6YYo_GRwseF-gad0824kVLOYzxFd8N70=.cceba25d-c2de-47ab-9d42-4d54909c5ca2@github.com>

> IdealLoopTree::policy_unroll_slp_analysis() restricts unrolling of
> loops that are found to be candidate for superword but if superword
> then fails, unrolling doesn't always resume. SuperWord::output() has
> logic for that in one of the failure paths but some other paths are
> not covered (for instance in the case of the test case). I propose
> that superword explictly returns whether it succeeded or not and that
> in case of failure, for a main loop, unrolling be attempted again.

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  test fix on x86

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7822/files
  - new: https://git.openjdk.java.net/jdk/pull/7822/files/8ae4fa52..757f0310

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7822&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7822&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7822.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7822/head:pull/7822

PR: https://git.openjdk.java.net/jdk/pull/7822

From duke at openjdk.java.net  Wed Mar 23 16:41:12 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Wed, 23 Mar 2022 16:41:12 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con [v3]
In-Reply-To: <PTWmXGwsOgvsAdlFQ1MogVOZXEAp-EIUKUdqx_-xT6E=.29474594-399f-4407-9cdf-811844440ffa@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
 <s210E9mQQT0SenSoO0rXeioNZY28eFTs4D18jEjfLLE=.bbeecb0f-0a32-4cda-ae40-8314a02d7941@github.com>
 <PTWmXGwsOgvsAdlFQ1MogVOZXEAp-EIUKUdqx_-xT6E=.29474594-399f-4407-9cdf-811844440ffa@github.com>
Message-ID: <_HK0GZp06XiIT_-NV99tSJhnAqOQbkBSp0rg6GRc7bk=.42721931-de54-4e47-8fc6-9ca9fa4dda01@github.com>

On Wed, 23 Mar 2022 06:13:12 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move tests to existing test classes.
>
> test/hotspot/jtreg/compiler/c2/irTests/AddINodeIdealizationTests.java line 47:
> 
>> 45:                  "test14", "test15", "test16",
>> 46:                  "test17", "test18", "test19",
>> 47:                  "testXPlus_PosConMinusY_", "testXPlus_NegConMinusY_",
> 
> Please make the name uniform and put them in correct order, thanks.

Renamed, does it look good to you now? Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7795

From nitinkashyapa at gmail.com  Wed Mar 23 08:02:49 2022
From: nitinkashyapa at gmail.com (Nithin Kashyap)
Date: Wed, 23 Mar 2022 13:32:49 +0530
Subject: Regarding contributing for JDK-8282024
Message-ID: <CADRELN9r69QnKSEwx=Bcy9nr1tTDPuh1JR+OR7i6Pkc+BvHDFQ@mail.gmail.com>

Hi

This is my first time trying to contribute on the OpenJDK and I picked the
starter bug https://bugs.openjdk.java.net/browse/JDK-8282024, Wanted to
contribute on this, if someone is actively contributing I can help them.
Please Let me know about this.

Thanks and Regards
Nithin

From serb at openjdk.java.net  Wed Mar 23 21:46:12 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 23 Mar 2022 21:46:12 GMT
Subject: RFR: 8283422: Create a new test for JDK-8254790
In-Reply-To: <z9N9yHqyi0qlTCZHirK6_xDtHeXLqwoa3_Ov7ANhmMQ=.a58b1227-b173-43be-a53e-8a0f4a4f56ec@github.com>
References: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
 <z9N9yHqyi0qlTCZHirK6_xDtHeXLqwoa3_Ov7ANhmMQ=.a58b1227-b173-43be-a53e-8a0f4a4f56ec@github.com>
Message-ID: <9S-dAZduMgQKTTsBKdt7_ItLA1vHw5Pk3kBMvSlpQNE=.b0266fa4-8b32-44ad-b1ac-c8d9fa6e2d32@github.com>

On Wed, 23 Mar 2022 07:13:09 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> I think the root cause is simply that there is not enough memory available to the VM to allocate such a large object. `MaxRAMPercentage` is set to 4 but the test could also be executed on a system with a small memory size. I think the test needs to be robust enough to account for all kinds of machines/settings.

It has a "guard" jtreg tag "os.maxMemory > 5G" which should prevent execution of this test on small systems. I'll bump this requirement in the next revision of the test.

> Do you know why the issue is only reproducible with a large heap and only if the heap is filled?

That's due to the nature of that [bug](https://bugs.openjdk.java.net/browse/JDK-8254790?focusedCommentId=14374611&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14374611) 
> the 32 bit arithmetic instruction used for 64-bit address

-------------

PR: https://git.openjdk.java.net/jdk/pull/7883

From xliu at openjdk.java.net  Thu Mar 24 00:14:15 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Thu, 24 Mar 2022 00:14:15 GMT
Subject: RFR: 8283541: Add Statical counters and some comments in
 PhaseStringOpts
Message-ID: <oM4fO5nHROEYBxZUP6H_ToI0OStMKR5nZWeyXoMazIc=.ee793147-075b-4504-b1a6-83f08d18715a@github.com>

8283541: Add Statical counters and some comments in PhaseStringOpts

-------------

Commit messages:
 - 8283541: Add Statical counters and some comments in PhaseStringOpts

Changes: https://git.openjdk.java.net/jdk/pull/7933/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7933&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283541
  Stats: 97 lines in 3 files changed: 48 ins; 41 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7933.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7933/head:pull/7933

PR: https://git.openjdk.java.net/jdk/pull/7933

From xgong at openjdk.java.net  Thu Mar 24 01:53:49 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Thu, 24 Mar 2022 01:53:49 GMT
Subject: RFR: 8282162: [vector] Optimize vector negation API [v2]
In-Reply-To: <QnpIqj1hBZz6GNQxOr72g8PEMH4uKtAzNyR-9tCX1b4=.797224d5-c5a6-4732-9323-3b64aa4fa12f@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
 <QnpIqj1hBZz6GNQxOr72g8PEMH4uKtAzNyR-9tCX1b4=.797224d5-c5a6-4732-9323-3b64aa4fa12f@github.com>
Message-ID: <sWSGN6TbFRxuwY_lAUWpktxte64jeEMUuu9B9QjK7Z4=.7588d429-47ee-406d-a8a4-ca7c34c53a70@github.com>

On Tue, 22 Mar 2022 09:58:23 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE.
>> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern.
>> 
>> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture:
>>   - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation.
>>   - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`.
>> 
>> So with this patch, the following transformations are applied:
>> 
>> For non-masked negation with NEON:
>> 
>>   movi    v16.4s, #0x0
>>   sub v17.4s, v16.4s, v17.4s       ==> neg v17.4s, v17.4s
>> 
>> and with SVE:
>> 
>>   mov z16.s, #0
>>   sub z18.s, z16.s, z17.s          ==> neg z16.s, p7/m, z16.s
>> 
>> For masked negation with NEON:
>> 
>>   movi    v17.4s, #0x1
>>   mvn v19.16b, v18.16b
>>   mov v20.16b, v16.16b             ==>  neg v18.4s, v17.4s
>>   bsl v20.16b, v19.16b, v18.16b         bsl v19.16b, v18.16b, v17.16b
>>   add v19.4s, v20.4s, v17.4s
>>   mov v18.16b, v16.16b
>>   bsl v18.16b, v19.16b, v20.16b
>> 
>> and with SVE:
>> 
>>   mov z16.s, #-1
>>   mov z17.s, #1                    ==> neg z16.s, p0/m, z16.s
>>   eor z18.s, p0/m, z18.s, z16.s
>>   add z18.s, p0/m, z18.s, z17.s
>> 
>> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed):
>> 
>> NEON:
>> Benchmark                Gain
>> Byte128Vector.NEG        1.029
>> Byte128Vector.NEGMasked  1.757
>> Short128Vector.NEG       1.041
>> Short128Vector.NEGMasked 1.659
>> Int128Vector.NEG         1.005
>> Int128Vector.NEGMasked   1.513
>> Long128Vector.NEG        1.003
>> Long128Vector.NEGMasked  1.878
>> 
>> SVE with 512-bits:
>> Benchmark                Gain
>> ByteMaxVector.NEG        1.10
>> ByteMaxVector.NEGMasked  1.165
>> ShortMaxVector.NEG       1.056
>> ShortMaxVector.NEGMasked 1.195
>> IntMaxVector.NEG         1.002
>> IntMaxVector.NEGMasked   1.239
>> LongMaxVector.NEG        1.031
>> LongMaxVector.NEGMasked  1.191
>> 
>> X86 (non AVX-512):
>> Benchmark                Gain
>> ByteMaxVector.NEGMasked  1.254
>> ShortMaxVector.NEGMasked 1.359
>> IntMaxVector.NEGMasked   1.431
>> LongMaxVector.NEGMasked  1.989
>> 
>> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a superclass for vector negation

Hi @PaulSandoz @jatin-bhateja, could you please help to take a look at this PR? Thanks so much!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From pli at openjdk.java.net  Thu Mar 24 01:53:55 2022
From: pli at openjdk.java.net (Pengfei Li)
Date: Thu, 24 Mar 2022 01:53:55 GMT
Subject: Integrated: 8283408: Fix a C2 crash when filling arrays with unsafe
In-Reply-To: <B6NUr4Mz47vDH3FSwshS2R5U33FutQxB2s-jYRcQG80=.c3dee38b-a74f-42cd-9c01-381906b4a4ac@github.com>
References: <B6NUr4Mz47vDH3FSwshS2R5U33FutQxB2s-jYRcQG80=.c3dee38b-a74f-42cd-9c01-381906b4a4ac@github.com>
Message-ID: <TC3hIMWLGVca5LBfyk3tvykSTfvaoM83wl34iMNZFMw=.0a780912-a449-4ba1-b56b-f78c13e04bff@github.com>

On Mon, 21 Mar 2022 06:00:31 GMT, Pengfei Li <pli at openjdk.org> wrote:

> We recently found a segmentation fault issue in C2 compiler with some
> code that uses Java Unsafe API to initialize an array in a loop. It can
> be reproduced by below code snippet compiled by C2 on AArch64. It's also
> reproducible on x86 with an additional VM option "-XX:+OptimizeFill".
> 
>   byte[] arr = new byte[size];
>   int offset = unsafe.arrayBaseOffset(byte[].class);
>   for (int i = offset; i < offset + size; i++) {
>     unsafe.putByte(arr, i, val);
>   }
> 
> This issue is caused by a NULL pointer in a C2 loop optimization phase
> called intrinsify_fill. In this phase, array filling loop patterns are
> recognized and replaced by some intrinsics. But filling operations with
> Unsafe API call are not handled very well. From C2 mid-end's point of
> view, a difference between an Unsafe call and a normal array access like
> `arr[i] = val` is element addressing. For normal array accesses, C2 uses
> two AddP nodes for computing an element's address - one for adding array
> header size and another for adding the element's relative offset from
> the header. But Unsafe calls may have only one AddP node for adding an
> absolute offset of an element from the array base. In current code, the
> intrinsify_fill phase creates an AddP node but with NULL input for above
> case and eventually causes a segmentation fault.
> 
> In this patch, we add a check to allow one AddP node in array filling
> patterns to be optional. After this fix, the case above can be optimized
> by intrinsify_fill as well. We know that the Unsafe call is rarely used
> in Java application code and developers should use it at their own risk.
> But we still propose this fix because C2 crashes even Unsafe is used in
> a correct way.
> 
> Jtreg hotspot::hotspot_all_no_apps, jdk::tier1~3 and langtools::tier1
> are tested and no issue is found. We also create a new jtreg case within
> this patch.

This pull request has now been integrated.

Changeset: a6740c01
Author:    Pengfei Li <pli at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a6740c010b7d37f991c8547be6ea72b198e9094f
Stats:     75 lines in 2 files changed: 72 ins; 2 del; 1 mod

8283408: Fix a C2 crash when filling arrays with unsafe

Reviewed-by: roland, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7884

From djelinski at openjdk.java.net  Thu Mar 24 07:56:42 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 24 Mar 2022 07:56:42 GMT
Subject: Integrated: 8283519: Hsdis with capstone should annotate output
In-Reply-To: <cFqhmme_HJNYQKvYv9gW3ADqO1NGEDsSWdRxiLgVL7E=.9afd0736-6ff3-4077-8372-c7d83cfa4875@github.com>
References: <cFqhmme_HJNYQKvYv9gW3ADqO1NGEDsSWdRxiLgVL7E=.9afd0736-6ff3-4077-8372-c7d83cfa4875@github.com>
Message-ID: <zt6NUeGKaMoKwcU5MQbrrx2Kl_eM2B9YMIn_ydXwpQU=.1469f1bd-1949-4e9e-84f3-e9544041bbf1@github.com>

On Tue, 22 Mar 2022 15:20:38 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Sample output after the changes:
> 
> [Stub Code]
>   0x000001cd0a937e20:   nopl		(%rax, %rax)        ;   {no_reloc}
>   0x000001cd0a937e25:   movabsq		$0x0, %rbx          ;   {static_stub}
>   0x000001cd0a937e2f:   jmp		0x1cd0a937e2f       ;   {runtime_call}
> [Exception Handler]
>   0x000001cd0a937e34:   callq		0x1cd0a3ca480       ;   {runtime_call handle_exception_from_callee Runtime1 stub}
>   0x000001cd0a937e39:   movabsq		$0x7ff8df21a850, %rcx;   {external_word}
>   0x000001cd0a937e43:   andq		$0xfffffffffffffff0, %rsp
>   0x000001cd0a937e47:   movabsq		$0x7ff8deef30c0, %r10;   {runtime_call MacroAssembler::debug64}
>   0x000001cd0a937e51:   callq		*%r10
>   0x000001cd0a937e54:   hlt		
> [Deopt Handler Code]
>   0x000001cd0a937e55:   movabsq		$0x1cd0a937e55, %r10;   {section_word}
>   0x000001cd0a937e5f:   pushq		%r10
>   0x000001cd0a937e61:   jmp		0x1cd0a325ca0       ;   {runtime_call DeoptimizationBlob}
>   0x000001cd0a937e66:   hlt		
>   0x000001cd0a937e67:   hlt		
> 
> before the changes none of the annotations (like `[Stub Code]` or `;   {no_reloc}`) were present.

This pull request has now been integrated.

Changeset: a35afe84
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a35afe84c3032cb10720bcd16498e2969cea0b86
Stats:     42 lines in 1 file changed: 41 ins; 0 del; 1 mod

8283519: Hsdis with capstone should annotate output

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.java.net/jdk/pull/7904

From rcastanedalo at openjdk.java.net  Thu Mar 24 08:19:51 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Thu, 24 Mar 2022 08:19:51 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v2]
In-Reply-To: <-HZVOA3gRrIK-0wfiFH4_XhJW5kfo_Bi9ev3bTwVIgE=.96261e75-bebc-4a8f-a74d-54a5945cd7ac@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <2biNIQgrADSLZbAdbSDGvSpAnO8NdJLHRsRWHAhNYpw=.491f9738-9678-4412-b615-1b741b4364ed@github.com>
 <-HZVOA3gRrIK-0wfiFH4_XhJW5kfo_Bi9ev3bTwVIgE=.96261e75-bebc-4a8f-a74d-54a5945cd7ac@github.com>
Message-ID: <3AMpC8Jd2GRtH6qpkvjuBnTg-m5lfRBl6W2UItG1ZeY=.d2ec005c-58b7-418e-a311-56884f90a4af@github.com>

On Wed, 23 Mar 2022 08:57:37 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> src/utils/IdealGraphVisualizer/Graal/src/main/java/com/sun/hotspot/igv/graal/filters/GraalEdgeColorFilter.java line 63:
>> 
>>> 61:                     String type = null;
>>> 62: 
>>> 63:                     if (type != null) {
>> 
>> This block is dead since `type` is `null`. Is this intended?
>
> I removed the method `Connection::getType()` and the code that depends on it in the Graal filters (the only place where this method was used). The Graal filters are not used and should just get removed, since HotSpot IGV does not support Graal anymore (a specific IGV variant is available for Graal, see https://www.graalvm.org/advanced-tools/). I will file a separate cleanup RFE for that.

I just filed [JDK-8283612](https://bugs.openjdk.java.net/browse/JDK-8283612) for removing the Graal module.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7817

From thartmann at openjdk.java.net  Thu Mar 24 09:36:42 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 24 Mar 2022 09:36:42 GMT
Subject: RFR: 8283187: C2: loop candidate for superword not always unrolled
 fully if superword fails [v4]
In-Reply-To: <_6OmC-dlVJJ6YYo_GRwseF-gad0824kVLOYzxFd8N70=.cceba25d-c2de-47ab-9d42-4d54909c5ca2@github.com>
References: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
 <_6OmC-dlVJJ6YYo_GRwseF-gad0824kVLOYzxFd8N70=.cceba25d-c2de-47ab-9d42-4d54909c5ca2@github.com>
Message-ID: <EhVy9OW7g0eCFikRoJRKOMEyUFIguEj9Dt7q7NQ_UCU=.9089fbcc-f0d6-4937-a202-82296f860e9a@github.com>

On Wed, 23 Mar 2022 16:41:14 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> IdealLoopTree::policy_unroll_slp_analysis() restricts unrolling of
>> loops that are found to be candidate for superword but if superword
>> then fails, unrolling doesn't always resume. SuperWord::output() has
>> logic for that in one of the failure paths but some other paths are
>> not covered (for instance in the case of the test case). I propose
>> that superword explictly returns whether it succeeded or not and that
>> in case of failure, for a main loop, unrolling be attempted again.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test fix on x86

Looks good.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7822

From chagedorn at openjdk.java.net  Thu Mar 24 10:30:43 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 24 Mar 2022 10:30:43 GMT
Subject: RFR: 8283187: C2: loop candidate for superword not always unrolled
 fully if superword fails [v4]
In-Reply-To: <_6OmC-dlVJJ6YYo_GRwseF-gad0824kVLOYzxFd8N70=.cceba25d-c2de-47ab-9d42-4d54909c5ca2@github.com>
References: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
 <_6OmC-dlVJJ6YYo_GRwseF-gad0824kVLOYzxFd8N70=.cceba25d-c2de-47ab-9d42-4d54909c5ca2@github.com>
Message-ID: <QlUMKcOP42SsjrufBObELKaSHT0bCPdEpJr0K8JXf4s=.69590c78-1fa7-43d2-a07f-258f05cbd222@github.com>

On Wed, 23 Mar 2022 16:41:14 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> IdealLoopTree::policy_unroll_slp_analysis() restricts unrolling of
>> loops that are found to be candidate for superword but if superword
>> then fails, unrolling doesn't always resume. SuperWord::output() has
>> logic for that in one of the failure paths but some other paths are
>> not covered (for instance in the case of the test case). I propose
>> that superword explictly returns whether it succeeded or not and that
>> in case of failure, for a main loop, unrolling be attempted again.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test fix on x86

Looks good, thanks for the updates!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7822

From chagedorn at openjdk.java.net  Thu Mar 24 10:30:44 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Thu, 24 Mar 2022 10:30:44 GMT
Subject: RFR: 8283187: C2: loop candidate for superword not always unrolled
 fully if superword fails [v2]
In-Reply-To: <6etwB55nudBQgU6N-1hK35AO0h3uoZo_rnbseKrOUg4=.79af9aa5-3c64-48ff-93c3-81b7455169c8@github.com>
References: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
 <6etwB55nudBQgU6N-1hK35AO0h3uoZo_rnbseKrOUg4=.79af9aa5-3c64-48ff-93c3-81b7455169c8@github.com>
Message-ID: <oCrthCQlyHg--26QhIM8xWLjrVHjE6xRM8Vo-MavRic=.3c0cbaf1-1caa-4143-950c-cef2cf0f3c25@github.com>

On Tue, 22 Mar 2022 12:18:22 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> IdealLoopTree::policy_unroll_slp_analysis() restricts unrolling of
>> loops that are found to be candidate for superword but if superword
>> then fails, unrolling doesn't always resume. SuperWord::output() has
>> logic for that in one of the failure paths but some other paths are
>> not covered (for instance in the case of the test case). I propose
>> that superword explictly returns whether it succeeded or not and that
>> in case of failure, for a main loop, unrolling be attempted again.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/hotspot/jtreg/compiler/c2/irTests/TestSuperwordFailsUnrolling.java
>   
>   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>

src/hotspot/share/opto/superword.cpp line 129:

> 127:   // skip any loop that has not been assigned max unroll by analysis
> 128:   if (do_optimization) {
> 129:     if (SuperWordLoopUnrollAnalysis && cl->slp_max_unroll() == 0) return false;

While at it, you could also add braces for the one liner ifs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7822

From thartmann at openjdk.java.net  Thu Mar 24 11:24:52 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Thu, 24 Mar 2022 11:24:52 GMT
Subject: RFR: 8279888: Local variable independently used by multiple loops
 can interfere with loop optimizations [v5]
In-Reply-To: <SU6truu67PgUmkn4bGPQ4WSplv7Q0J2GvfuHjYsr-Fk=.645ec4f3-dee6-4a8a-84c4-86380ed4d7a0@github.com>
References: <3PdTSVveILPXuy2hGHOheGuh3thK8Q5i0VTPqI_treA=.5182eb4b-75a1-4e68-b952-626cb3c6d046@github.com>
 <SU6truu67PgUmkn4bGPQ4WSplv7Q0J2GvfuHjYsr-Fk=.645ec4f3-dee6-4a8a-84c4-86380ed4d7a0@github.com>
Message-ID: <9Bvgje8RFnjlNDDFCvM_VcF_-LYPmig_6PWCZap29dM=.372e9256-d88c-41eb-ae65-c84444c2b000@github.com>

On Wed, 23 Mar 2022 15:57:51 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The bytecode of the 2 methods of the benchmark is structured
>> differently: loopsWithSharedLocal(), the slowest one, has multiple
>> backedges with a single head while loopsWithScopedLocal() has a single
>> backedge and all the paths in the loop body merge before the
>> backedge. loopsWithSharedLocal() has its head cloned which results in
>> a 2 loops loop nest.
>> 
>> loopsWithSharedLocal() is slow when 2 of the backedges are most
>> commonly taken with one taken only 3 times as often as the other
>> one. So a thread executing that code only runs the inner loop for a
>> few iterations before exiting it and executing the outer loop. I think
>> what happens is that any time the inner loop is entered, some
>> predicates are executed and the overhead of the setup of loop strip
>> mining (if it's enabled) has to be paid. Also, if iteration
>> splitting/unrolling was applied, the main loop is likely never
>> executed and all time is spent in the pre/post loops where potentially
>> some range checks remain.
>> 
>> The fix I propose is that ciTypeFlow, when it clone heads, not only
>> rewires the most frequent loop but also all this other frequent loops
>> that share the same head. loopsWithSharedLocal() and
>> loopsWithScopedLocal() are then fairly similar once c2 parses them.
>> 
>> Without the patch I measure:
>> 
>> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.874 ? 250.463  ns/op
>> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1575.665 ?  70.372  ns/op
>> 
>> with it:
>> 
>> LoopLocals.loopsWithScopedLocal      mixed  avgt    5  1108.180 ? 245.873  ns/op
>> LoopLocals.loopsWithSharedLocal      mixed  avgt    5  1234.665 ? 157.912  ns/op
>> 
>> But this patch also causes a regression when running one of the
>> benchmarks added by 8278518. From:
>> 
>> SharedLoopHeader.sharedHeader  avgt    5  505.993 ? 44.126  ns/op
>> 
>> to:
>> 
>> SharedLoopHeader.sharedHeader  avgt    5  724.253 ? 1.664  ns/op
>> 
>> The hot method of this benchmark used to be compiled with 2 loops, the
>> inner one a counted loop. With the patch, it's now compiled with a
>> single one which can't be converted into a counted loop because the
>> loop variable is incremented by a different amount along the 2 paths
>> in the loop body. What I propose to fix this is to add a new loop
>> transformation that detects that, because of a merge point, a loop
>> can't be turned into a counted loop and transforms it into 2
>> loops. The benchmark performs better with this:
>> 
>> SharedLoopHeader.sharedHeader  avgt    5  567.150 ? 6.120  ns/op
>> 
>> Not quite on par with the previous score but AFAICT this is due to
>> code generation not being as good (the loop head can't be aligned in
>> particular).
>> 
>> In short, I propose:
>> 
>> - changing ciTypeFlow so that, when it pays off, a loop with
>> multiple backedges is compiled as a single loop with a merge point in
>> the loop body
>> 
>> - adding a new loop transformation so that, when it pays off, a loop
>> with a merge point in the loop body is converted into a 2 loops loop
>> nest, essentially the opposite transformation.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - review
>  - Merge branch 'master' into JDK-8279888
>  - Merge branch 'master' into JDK-8279888
>  - Merge commit '44327da170c57ccd31bfad379738c7f00e67f4c1' into JDK-8279888
>  - Update src/hotspot/share/opto/loopopts.cpp
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - Update src/hotspot/share/opto/loopopts.cpp
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - Merge branch 'master' into JDK-8279888
>  - Merge branch 'master' into JDK-8279888
>  - fix
>  - Merge branch 'master' into JDK-8279888
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/91fab6ad...8b20e0cc

Thanks, I'll re-run testing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7352

From tobias.hartmann at oracle.com  Thu Mar 24 11:29:26 2022
From: tobias.hartmann at oracle.com (Tobias Hartmann)
Date: Thu, 24 Mar 2022 12:29:26 +0100
Subject: Regarding contributing for JDK-8282024
In-Reply-To: <CADRELN9r69QnKSEwx=Bcy9nr1tTDPuh1JR+OR7i6Pkc+BvHDFQ@mail.gmail.com>
References: <CADRELN9r69QnKSEwx=Bcy9nr1tTDPuh1JR+OR7i6Pkc+BvHDFQ@mail.gmail.com>
Message-ID: <ebe27eb1-3790-93ed-8049-b4061a017ce7@oracle.com>

Hi Nithin,

8282024 is currently assigned to Cesar and from the comments it looks like as if he has a prototype
ready. Please sync up with him before starting any work.

Thanks,
Tobias


On 23.03.22 09:02, Nithin Kashyap wrote:
> Hi
> 
> This is my first time trying to contribute on the OpenJDK and I picked the
> starter bug https://bugs.openjdk.java.net/browse/JDK-8282024, Wanted to
> contribute on this, if someone is actively contributing I can help them.
> Please Let me know about this.
> 
> Thanks and Regards
> Nithin

From roland at openjdk.java.net  Thu Mar 24 12:57:53 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 24 Mar 2022 12:57:53 GMT
Subject: Integrated: 8283187: C2: loop candidate for superword not always
 unrolled fully if superword fails
In-Reply-To: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
References: <yJBr0BfREMoq43QQw-264r2ID7Twl7lg1woMrG76SGk=.b762fd92-1d58-425e-928f-2175521456ab@github.com>
Message-ID: <dvZzTh1rRMIienzt_fRrkQi7-nsr3nvjzYO1h2C2L5o=.05b2982a-4ae1-4e97-86f1-03b95aae7ed6@github.com>

On Tue, 15 Mar 2022 15:45:08 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> IdealLoopTree::policy_unroll_slp_analysis() restricts unrolling of
> loops that are found to be candidate for superword but if superword
> then fails, unrolling doesn't always resume. SuperWord::output() has
> logic for that in one of the failure paths but some other paths are
> not covered (for instance in the case of the test case). I propose
> that superword explictly returns whether it succeeded or not and that
> in case of failure, for a main loop, unrolling be attempted again.

This pull request has now been integrated.

Changeset: 14c20bc0
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/14c20bc0e0ee32b82ffe653ae9e4a0be52d578cb
Stats:     135 lines in 5 files changed: 90 ins; 6 del; 39 mod

8283187: C2: loop candidate for superword not always unrolled fully if superword fails

Reviewed-by: thartmann, chagedorn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7822

From jbhateja at openjdk.java.net  Thu Mar 24 15:47:45 2022
From: jbhateja at openjdk.java.net (Jatin Bhateja)
Date: Thu, 24 Mar 2022 15:47:45 GMT
Subject: RFR: 8279508: Auto-vectorize Math.round API [v18]
In-Reply-To: <n4VayLGjH_E901Bt88BSj2Ll4VNoOV4r2fVY0kUHEtA=.0eeb0c75-ea9f-4135-83ad-e16551e577c5@github.com>
References: <iRtE5cC04m_648N-GqIn8FcaOIXiPjBTHgcr3rvZW2E=.146724a0-a18b-46e4-b4be-1ebbe37b9e4e@github.com>
 <KyoBFGrYKdHoGAWeNhM54eGA-AtOToazLOFg-zrnI9s=.a23c0299-ff24-44fb-aa13-e960d7b1f942@github.com>
 <n4VayLGjH_E901Bt88BSj2Ll4VNoOV4r2fVY0kUHEtA=.0eeb0c75-ea9f-4135-83ad-e16551e577c5@github.com>
Message-ID: <6Zb5Gbl88cEL8Ev2KqnwTpIwiUHTyijr1lOcc1sHrso=.ba487d91-0064-452a-b140-9c6b3022a221@github.com>

On Wed, 23 Mar 2022 06:55:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - 8279508: Using an explicit scratch register since rscratch1 is bound to r10 and its usage is transparent to compiler.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
>>  - 8279508: Windows build failure fix.
>>  - 8279508: Styling comments resolved.
>>  - 8279508: Creating separate test for round double under feature check.
>>  - 8279508: Reducing the invocation count and compile thresholds for RoundTests.java.
>>  - 8279508: Review comments resolution.
>>  - 8279508: Preventing domain switch-over penalty for Math.round(float) and constraining unrolling to prevent code bloating.
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508
>>  - 8279508: Removing +LogCompilation flag.
>>  - ... and 12 more: https://git.openjdk.java.net/jdk/compare/ff0b0927...c17440cf
>
> All tests passed.

Hi @TobiHartmann , thanks for confirming.
Hi @jddarcy , @theRealAph , kindly let me know if its good to integrate this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7094

From eliu at openjdk.java.net  Thu Mar 24 16:31:12 2022
From: eliu at openjdk.java.net (Eric Liu)
Date: Thu, 24 Mar 2022 16:31:12 GMT
Subject: RFR: 8283435: AArch64: [vectorapi] Optimize SVE lane/withLane
 operations for 64/128-bit vector sizes
Message-ID: <w973iyoymdw4xNRnCYR2YwTTJvLRvDt0rZT2gnGaafI=.0a0db0bd-6a3a-4560-9442-31cb3ccd9214@github.com>

This patch optimizes the SVE backend implementations of Vector.lane and
Vector.withLane for 64/128-bit vector size. The basic idea is to use
lower costs NEON instructions when the vector size is 64/128 bits.

1. Vector.lane(int i) (Gets the lane element at lane index i)

As SVE doesn?t have direct instruction support for extraction like
"pextr"[1] in x86, the final code was shown as below:


        Byte512Vector.lane(7)

        orr     x8, xzr, #0x7
        whilele p0.b, xzr, x8
        lastb   w10, p0, z16.b
        sxtb    w10, w10


This patch uses NEON instruction instead if the target lane is located
in the NEON 128b range. For the same example above, the generated code
now is much simpler:


        smov    x11, v16.b[7]


For those cases that target lane is located out of the NEON 128b range,
this patch uses EXT to shift the target to the lowest. The generated
code is as below:


        Byte512Vector.lane(63)

        mov     z17.d, z16.d
        ext     z17.b, z17.b, z17.b, #63
        smov    x10, v17.b[0]


2. Vector.withLane(int i, E e) (Replaces the lane element of this vector
                                at lane index i with value e)

For 64/128-bit vector, insert operation could be implemented by NEON
instructions to get better performance. E.g., for IntVector.SPECIES_128,
"IntVector.withLane(0, (int)4)" generates code as below:


        Before:
        orr     w10, wzr, #0x4
        index   z17.s, #-16, #1
        cmpeq   p0.s, p7/z, z17.s, #-16
        mov     z17.d, z16.d
        mov     z17.s, p0/m, w10

        After
        orr     w10, wzr, #0x4
        mov     v16.s[0], w10


This patch also does a small enhancement for vectors whose sizes are
greater than 128 bits. It can save 1 "DUP" if the target index is
smaller than 32. E.g., For ByteVector.SPECIES_512,
"ByteVector.withLane(0, (byte)4)" generates code as below:


        Before:
        index   z18.b, #0, #1
        mov     z17.b, #0
        cmpeq   p0.b, p7/z, z18.b, z17.b
        mov     z17.d, z16.d
        mov     z17.b, p0/m, w16

        After:
        index   z17.b, #-16, #1
        cmpeq   p0.b, p7/z, z17.b, #-16
        mov     z17.d, z16.d
        mov     z17.b, p0/m, w16


With this patch, we can see up to 200% performance gain for specific
vector micro benchmarks in my SVE testing system.

[TEST]
test/jdk/jdk/incubator/vector, test/hotspot/jtreg/compiler/vectorapi
passed without failure.

[1] https://www.felixcloutier.com/x86/pextrb:pextrd:pextrq

-------------

Commit messages:
 - 8283435: AArch64: [vectorapi] Optimize SVE lane/withLane operations for 64/128-bit vector sizes

Changes: https://git.openjdk.java.net/jdk/pull/7943/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7943&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283435
  Stats: 812 lines in 9 files changed: 385 ins; 102 del; 325 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7943.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7943/head:pull/7943

PR: https://git.openjdk.java.net/jdk/pull/7943

From vladimir.kozlov at oracle.com  Thu Mar 24 17:14:08 2022
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 24 Mar 2022 10:14:08 -0700
Subject: Regarding contributing for JDK-8282024
In-Reply-To: <ebe27eb1-3790-93ed-8049-b4061a017ce7@oracle.com>
References: <CADRELN9r69QnKSEwx=Bcy9nr1tTDPuh1JR+OR7i6Pkc+BvHDFQ@mail.gmail.com>
 <ebe27eb1-3790-93ed-8049-b4061a017ce7@oracle.com>
Message-ID: <b31a7581-16b1-3711-674f-c752416c13bb@oracle.com>

Nithin, please also follow [1] process to become OpenJDK contributor if you did not do it yet.

Thanks,
Vladimir K

[1] https://openjdk.java.net/contribute/

On 3/24/22 4:29 AM, Tobias Hartmann wrote:
> Hi Nithin,
> 
> 8282024 is currently assigned to Cesar and from the comments it looks like as if he has a prototype
> ready. Please sync up with him before starting any work.
> 
> Thanks,
> Tobias
> 
> 
> On 23.03.22 09:02, Nithin Kashyap wrote:
>> Hi
>>
>> This is my first time trying to contribute on the OpenJDK and I picked the
>> starter bug https://bugs.openjdk.java.net/browse/JDK-8282024, Wanted to
>> contribute on this, if someone is actively contributing I can help them.
>> Please Let me know about this.
>>
>> Thanks and Regards
>> Nithin

From iklam at openjdk.java.net  Thu Mar 24 17:28:04 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 24 Mar 2022 17:28:04 GMT
Subject: RFR: 8283641: Large value for CompileThresholdScaling causes assert
Message-ID: <zTbCxiNzpOy4GXaJSlEwflHqdFfu6LUT3wPJjJue52c=.ebc55adb-34f6-4932-ada8-e19c761850a9@github.com>

Please review this trivial fix that checks for overflow of `(intx)(threshold * scale)`

Before:

$ java -XX:CompileThresholdScaling=12345678901234567890.0 -version
...
# Internal Error (/jdk/open/src/hotspot/share/utilities/powerOfTwo.hpp:54), pid=4147940, tid=4147941
# assert(value > T(0)) failed: value must be > 0


After:


$ java -XX:CompileThresholdScaling=12345678901234567890.0 -version
intx Tier0InvokeNotifyFreqLog=32 is outside the allowed range [ 0 ... 30 ]
...
OnStackReplacePercentage cannot be validated because CompileThreshold value is invalid
CompileThreshold (9223372036854775807) must be between 0 and 1073741823
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.


Tested with tiers 1-2.

-------------

Commit messages:
 - 8283641: Large value for CompileThresholdScaling causes assert

Changes: https://git.openjdk.java.net/jdk/pull/7944/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7944&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283641
  Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7944.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7944/head:pull/7944

PR: https://git.openjdk.java.net/jdk/pull/7944

From kvn at openjdk.java.net  Thu Mar 24 17:45:43 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 24 Mar 2022 17:45:43 GMT
Subject: RFR: 8283641: Large value for CompileThresholdScaling causes
 assert
In-Reply-To: <zTbCxiNzpOy4GXaJSlEwflHqdFfu6LUT3wPJjJue52c=.ebc55adb-34f6-4932-ada8-e19c761850a9@github.com>
References: <zTbCxiNzpOy4GXaJSlEwflHqdFfu6LUT3wPJjJue52c=.ebc55adb-34f6-4932-ada8-e19c761850a9@github.com>
Message-ID: <Gw3MXLGJFN9apcWoUfjJnBvogM2DLcqePcvMvKBazJ0=.ffbfd665-c18b-4cc0-a2bc-62cd2f2d8e20@github.com>

On Thu, 24 Mar 2022 16:34:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial fix that checks for overflow of `(intx)(threshold * scale)`
> 
> Before:
> 
> $ java -XX:CompileThresholdScaling=12345678901234567890.0 -version
> ...
> # Internal Error (/jdk/open/src/hotspot/share/utilities/powerOfTwo.hpp:54), pid=4147940, tid=4147941
> # assert(value > T(0)) failed: value must be > 0
> 
> 
> After:
> 
> 
> $ java -XX:CompileThresholdScaling=12345678901234567890.0 -version
> intx Tier0InvokeNotifyFreqLog=32 is outside the allowed range [ 0 ... 30 ]
> ...
> OnStackReplacePercentage cannot be validated because CompileThreshold value is invalid
> CompileThreshold (9223372036854775807) must be between 0 and 1073741823
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> 
> Tested with tiers 1-2.

src/hotspot/share/compiler/compilerDefinitions.cpp line 133:

> 131:     if (v > max_intx) {
> 132:       return max_intx;
> 133:     } else if (v < min_intx) {

This check is meaningless since `v` can't be negative. If you want you can add assert.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7944

From iklam at openjdk.java.net  Thu Mar 24 18:00:34 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 24 Mar 2022 18:00:34 GMT
Subject: RFR: 8283641: Large value for CompileThresholdScaling causes
 assert [v2]
In-Reply-To: <zTbCxiNzpOy4GXaJSlEwflHqdFfu6LUT3wPJjJue52c=.ebc55adb-34f6-4932-ada8-e19c761850a9@github.com>
References: <zTbCxiNzpOy4GXaJSlEwflHqdFfu6LUT3wPJjJue52c=.ebc55adb-34f6-4932-ada8-e19c761850a9@github.com>
Message-ID: <V0hx85ALzFlXMl1qQXxbIonHMbfxG-0Zuy-rGrU1jEM=.fb30ff63-753a-489d-bddd-65d1cec98a41@github.com>

> Please review this trivial fix that checks for overflow of `(intx)(threshold * scale)`
> 
> Before:
> 
> $ java -XX:CompileThresholdScaling=12345678901234567890.0 -version
> ...
> # Internal Error (/jdk/open/src/hotspot/share/utilities/powerOfTwo.hpp:54), pid=4147940, tid=4147941
> # assert(value > T(0)) failed: value must be > 0
> 
> 
> After:
> 
> 
> $ java -XX:CompileThresholdScaling=12345678901234567890.0 -version
> intx Tier0InvokeNotifyFreqLog=32 is outside the allowed range [ 0 ... 30 ]
> ...
> OnStackReplacePercentage cannot be validated because CompileThreshold value is invalid
> CompileThreshold (9223372036854775807) must be between 0 and 1073741823
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> 
> Tested with tiers 1-2.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @vnkozlov comment: no need to check for min_intx

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7944/files
  - new: https://git.openjdk.java.net/jdk/pull/7944/files/b8aab7ac..f84f63be

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7944&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7944&range=00-01

  Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7944.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7944/head:pull/7944

PR: https://git.openjdk.java.net/jdk/pull/7944

From kvn at openjdk.java.net  Thu Mar 24 18:04:48 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 24 Mar 2022 18:04:48 GMT
Subject: RFR: 8283641: Large value for CompileThresholdScaling causes
 assert [v2]
In-Reply-To: <V0hx85ALzFlXMl1qQXxbIonHMbfxG-0Zuy-rGrU1jEM=.fb30ff63-753a-489d-bddd-65d1cec98a41@github.com>
References: <zTbCxiNzpOy4GXaJSlEwflHqdFfu6LUT3wPJjJue52c=.ebc55adb-34f6-4932-ada8-e19c761850a9@github.com>
 <V0hx85ALzFlXMl1qQXxbIonHMbfxG-0Zuy-rGrU1jEM=.fb30ff63-753a-489d-bddd-65d1cec98a41@github.com>
Message-ID: <M1xTUtd-UJX0R6zjlkKQI-t-X_vvbpLXecHPNLN3M0E=.ed99f379-f9f9-44f7-9ae9-96a71ed2afc7@github.com>

On Thu, 24 Mar 2022 18:00:34 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this trivial fix that checks for overflow of `(intx)(threshold * scale)`
>> 
>> Before:
>> 
>> $ java -XX:CompileThresholdScaling=12345678901234567890.0 -version
>> ...
>> # Internal Error (/jdk/open/src/hotspot/share/utilities/powerOfTwo.hpp:54), pid=4147940, tid=4147941
>> # assert(value > T(0)) failed: value must be > 0
>> 
>> 
>> After:
>> 
>> 
>> $ java -XX:CompileThresholdScaling=12345678901234567890.0 -version
>> intx Tier0InvokeNotifyFreqLog=32 is outside the allowed range [ 0 ... 30 ]
>> ...
>> OnStackReplacePercentage cannot be validated because CompileThreshold value is invalid
>> CompileThreshold (9223372036854775807) must be between 0 and 1073741823
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>> 
>> 
>> Tested with tiers 1-2.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @vnkozlov comment: no need to check for min_intx

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7944

From iklam at openjdk.java.net  Thu Mar 24 18:04:49 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 24 Mar 2022 18:04:49 GMT
Subject: RFR: 8283641: Large value for CompileThresholdScaling causes
 assert [v2]
In-Reply-To: <Gw3MXLGJFN9apcWoUfjJnBvogM2DLcqePcvMvKBazJ0=.ffbfd665-c18b-4cc0-a2bc-62cd2f2d8e20@github.com>
References: <zTbCxiNzpOy4GXaJSlEwflHqdFfu6LUT3wPJjJue52c=.ebc55adb-34f6-4932-ada8-e19c761850a9@github.com>
 <Gw3MXLGJFN9apcWoUfjJnBvogM2DLcqePcvMvKBazJ0=.ffbfd665-c18b-4cc0-a2bc-62cd2f2d8e20@github.com>
Message-ID: <fo_4fNZEJYsqqQRZQZeTN_BESeQR9cR6PWduzWdaVdc=.8a5a17e2-0235-4800-931c-0664a7c59ed1@github.com>

On Thu, 24 Mar 2022 17:42:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @vnkozlov comment: no need to check for min_intx
>
> src/hotspot/share/compiler/compilerDefinitions.cpp line 133:
> 
>> 131:     if (v > max_intx) {
>> 132:       return max_intx;
>> 133:     } else if (v < min_intx) {
> 
> This check is meaningless since `v` can't be negative. If you want you can add assert.

I removed the `min_intx` check and added the asserts. I ran with the following tests and it didn't trigger the asserts. I'll rerun tiers 1-3 again.


java -XX:CompileThreshold=-1         -XX:CompileThresholdScaling=1 -version
java -XX:Tier0InvokeNotifyFreqLog=-2 -XX:CompileThresholdScaling=1 -version
java -XX:Tier4BackEdgeThreshold=-2   -XX:CompileThresholdScaling=1 -version

-------------

PR: https://git.openjdk.java.net/jdk/pull/7944

From kvn at openjdk.java.net  Thu Mar 24 18:59:48 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 24 Mar 2022 18:59:48 GMT
Subject: RFR: 8283641: Large value for CompileThresholdScaling causes
 assert [v2]
In-Reply-To: <fo_4fNZEJYsqqQRZQZeTN_BESeQR9cR6PWduzWdaVdc=.8a5a17e2-0235-4800-931c-0664a7c59ed1@github.com>
References: <zTbCxiNzpOy4GXaJSlEwflHqdFfu6LUT3wPJjJue52c=.ebc55adb-34f6-4932-ada8-e19c761850a9@github.com>
 <Gw3MXLGJFN9apcWoUfjJnBvogM2DLcqePcvMvKBazJ0=.ffbfd665-c18b-4cc0-a2bc-62cd2f2d8e20@github.com>
 <fo_4fNZEJYsqqQRZQZeTN_BESeQR9cR6PWduzWdaVdc=.8a5a17e2-0235-4800-931c-0664a7c59ed1@github.com>
Message-ID: <M83anG-ZNEDs07KzsCalcd49TopGNizHqUYEwvpQzP8=.97149176-d242-4a80-83bd-92881f850d1c@github.com>

On Thu, 24 Mar 2022 18:00:32 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/compiler/compilerDefinitions.cpp line 133:
>> 
>>> 131:     if (v > max_intx) {
>>> 132:       return max_intx;
>>> 133:     } else if (v < min_intx) {
>> 
>> This check is meaningless since `v` can't be negative. If you want you can add assert.
>
> I removed the `min_intx` check and added the asserts. I ran with the following tests and it didn't trigger the asserts. I'll rerun tiers 1-3 again.
> 
> 
> java -XX:CompileThreshold=-1         -XX:CompileThresholdScaling=1 -version
> java -XX:Tier0InvokeNotifyFreqLog=-2 -XX:CompileThresholdScaling=1 -version
> java -XX:Tier4BackEdgeThreshold=-2   -XX:CompileThresholdScaling=1 -version

Yes, there is `range()` checks for these flags declarations:

java -XX:CompileThreshold=-1         -XX:CompileThresholdScaling=1 -version
OnStackReplacePercentage cannot be validated because CompileThreshold value is invalid
CompileThreshold (-1) must be between 0 and 1073741823
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.


You can't specify negative Threshold values on command line. The assert is for some future case if we pass incorrect value.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7944

From iklam at openjdk.java.net  Thu Mar 24 21:45:49 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 24 Mar 2022 21:45:49 GMT
Subject: RFR: 8283641: Large value for CompileThresholdScaling causes
 assert [v2]
In-Reply-To: <M1xTUtd-UJX0R6zjlkKQI-t-X_vvbpLXecHPNLN3M0E=.ed99f379-f9f9-44f7-9ae9-96a71ed2afc7@github.com>
References: <zTbCxiNzpOy4GXaJSlEwflHqdFfu6LUT3wPJjJue52c=.ebc55adb-34f6-4932-ada8-e19c761850a9@github.com>
 <V0hx85ALzFlXMl1qQXxbIonHMbfxG-0Zuy-rGrU1jEM=.fb30ff63-753a-489d-bddd-65d1cec98a41@github.com>
 <M1xTUtd-UJX0R6zjlkKQI-t-X_vvbpLXecHPNLN3M0E=.ed99f379-f9f9-44f7-9ae9-96a71ed2afc7@github.com>
Message-ID: <BKy3XETkoqli0SKH-1aw5Ggu0s1gEg19Fwt4DzU1A7E=.8d36d5af-631e-4180-8c58-0165f6ab0c76@github.com>

On Thu, 24 Mar 2022 18:01:46 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @vnkozlov comment: no need to check for min_intx
>
> Good.

Thanks @vnkozlov for the review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7944

From iklam at openjdk.java.net  Thu Mar 24 21:45:49 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 24 Mar 2022 21:45:49 GMT
Subject: Integrated: 8283641: Large value for CompileThresholdScaling causes
 assert
In-Reply-To: <zTbCxiNzpOy4GXaJSlEwflHqdFfu6LUT3wPJjJue52c=.ebc55adb-34f6-4932-ada8-e19c761850a9@github.com>
References: <zTbCxiNzpOy4GXaJSlEwflHqdFfu6LUT3wPJjJue52c=.ebc55adb-34f6-4932-ada8-e19c761850a9@github.com>
Message-ID: <4YkSfzkhp3-BJgqeaNe4Q7Q37jT_FOEugWSV6bKXSrk=.5ab3a3fc-bd29-4f63-a2d9-74d0fba43680@github.com>

On Thu, 24 Mar 2022 16:34:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial fix that checks for overflow of `(intx)(threshold * scale)`
> 
> Before:
> 
> $ java -XX:CompileThresholdScaling=12345678901234567890.0 -version
> ...
> # Internal Error (/jdk/open/src/hotspot/share/utilities/powerOfTwo.hpp:54), pid=4147940, tid=4147941
> # assert(value > T(0)) failed: value must be > 0
> 
> 
> After:
> 
> 
> $ java -XX:CompileThresholdScaling=12345678901234567890.0 -version
> intx Tier0InvokeNotifyFreqLog=32 is outside the allowed range [ 0 ... 30 ]
> ...
> OnStackReplacePercentage cannot be validated because CompileThreshold value is invalid
> CompileThreshold (9223372036854775807) must be between 0 and 1073741823
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> 
> Tested with tiers 1-2.

This pull request has now been integrated.

Changeset: c1048021
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c1048021fe57b78bb1f300b977588e1a93a284b6
Stats:     8 lines in 1 file changed: 7 ins; 0 del; 1 mod

8283641: Large value for CompileThresholdScaling causes assert

Reviewed-by: kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7944

From fgao at openjdk.java.net  Fri Mar 25 07:50:07 2022
From: fgao at openjdk.java.net (Fei Gao)
Date: Fri, 25 Mar 2022 07:50:07 GMT
Subject: RFR: 8282470: Eliminate useless sign extension before some subword
 integer operations
Message-ID: <jCwC-KIaz5ttdb0I7cFn_YGCoe84psQzk_o82IVVtl8=.6d2cf93e-17ae-46f6-8f21-f8b5856d19c1@github.com>

Some loop cases of subword types, including byte and short, can't be vectorized by C2's SLP. Here is an example:

short[] addShort(short[] a, short[] b, short[] c) {
  for (int i = 0; i < SIZE; i++) {
    b[i] = (short) (a[i] + 8); //  line A
    sres[i] = (short) (b[i] + c[i]); // line B
  }
}

However, similar cases of int/float/double/long/char type can be vectorized successfully.

The reason why SLP can't vectorize the short case above is that, as illustrated here[1], the result of the scalar add operation on *line A* has been promoted to int type. It needs to be narrowed to short type first before it can work as one of source operands of addition on *line B*. The demotion is done by left-shifting 16 bits then right-shifting 16 bits. The ideal graph for the process is showed like below.
![image](https://user-images.githubusercontent.com/39403138/160074255-c751f84b-6511-4b56-927b-53fb512cf51b.png)

In SLP, for most short-type cases, we can determine the precise type of the scalar int-type operation and finally execute it with short-type vector operations[2], except rshift opcode and abs in some situations[3]. But in this case, the source operand of RShiftI is from LShiftI rather than from any LoadS[4], so we can't determine its real type and conservatively assign it with int type rather than real short type. The int-type opearation RShiftI here can't be vectorized together with other short-type operations, like AddI(line B). The reason for byte loop cases is the same. Similar loop cases of char type could be vectorized because its demotion from int to char is done by `and` with mask rather than `lshift_rshift`.

Therefore, we try to remove the patterns like `RShiftI _ (LShiftI _ valIn1 conIL ) conIR` in the byte/short cases, to vectorize more scenarios. Optimizing it in the mid-end by i-GVN is more reasonable.

What we do in the mid-end is eliminating the sign extension before some subword integer operations like:


int x, y;
short s = (short) (((x << Imm) >> Imm) OP y); // Imm <= 16

to

short s = (short) (x OP y);


In the patch, assuming that `x` can be any int number, we need guarantee that the optimization doesn't have any impact on result. Not all arithmetic logic OPs meet the requirements. For example, assuming that `Imm` equals `16`, `x` equals `131068`,
`y` equals `50` and `OP` is division`/`, `short s = (short) (((131068 << 16) >> 16) / 50)` is not equal to `short s = (short) (131068 / 50)`. When OP is division, we may get different result with or without demotion before OP, because the upper 16 bits of division may have influence on the lower 16 bits of result, which can't be optimized. All optimizable opcodes are listed in StoreNode::no_need_sign_extension(), whose upper 16 bits of src operands don't influence the lower 16 bits of result for short
type and upper 24 bits of src operand don't influence the lower 8 bits of dst operand for byte.

After the patch, the short loop case above can be vectorized as:

movi    v18.8h, #0x8
...
ldr     q16, [x14, #32] // vector load a[i]
// vector add, a[i] + 8, no promotion or demotion
add     v17.8h, v16.8h, v18.8h
str     q17, [x6, #32]  // vector store a[i] + 8, b[i]
ldr     q17, [x0, #32]  // vector load c[i]
// vector add, a[i] + c[i], no promotion or demotion
add     v16.8h, v17.8h, v16.8h
// vector add, a[i] + c[i] + 8, no promotion or demotion
add     v16.8h, v16.8h, v18.8h
str     q16, [x11, #32]  //vector store sres[i]
...


The patch works for byte cases as well.

Here is the performance data for micro-benchmark before and after this patch on both AArch64 and x64 machines. We can observe about ~83% improvement with this patch.

on AArch64:
Before the patch:
Benchmark (length)  Mode  Cnt    Score    Error  Units
addB       523      avgt   15  401.521 ?  0.033  ns/op
addS       523      avgt   15  401.512 ?  0.021  ns/op

After the patch:
Benchmark (length)  Mode  Cnt    Score   Error  Units
addB       523      avgt   15   68.444 ? 0.318  ns/op
addS       523      avgt   15   69.847 ? 0.043  ns/op

on x86:
Before the patch:
Benchmark (length)  Mode  Cnt    Score    Error  Units
addB       523      avgt   15  454.102 ? 36.180  ns/op
addS       523      avgt   15  432.245 ? 22.640  ns/op

After the patch:
Benchmark (length)  Mode  Cnt    Score    Error  Units
addB       523      avgt   15   75.812 ?  5.063  ns/op
addS       523      avgt   15   72.839 ? 10.109  ns/op

[1]: https://github.com/openjdk/jdk/blob/6013d09e82693a1c07cf0bf6daffd95114b3cbfa/src/hotspot/share/opto/superword.cpp#L3241
[2]: https://github.com/openjdk/jdk/blob/6013d09e82693a1c07cf0bf6daffd95114b3cbfa/src/hotspot/share/opto/superword.cpp#L3206
[3]: https://github.com/openjdk/jdk/blob/6013d09e82693a1c07cf0bf6daffd95114b3cbfa/src/hotspot/share/opto/superword.cpp#L3249
[4]: https://github.com/openjdk/jdk/blob/6013d09e82693a1c07cf0bf6daffd95114b3cbfa/src/hotspot/share/opto/superword.cpp#L3251

-------------

Commit messages:
 - 8282470: Eliminate useless sign extension before some subword integer operations

Changes: https://git.openjdk.java.net/jdk/pull/7954/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7954&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282470
  Stats: 389 lines in 5 files changed: 340 ins; 13 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7954.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7954/head:pull/7954

PR: https://git.openjdk.java.net/jdk/pull/7954

From jiefu at openjdk.java.net  Fri Mar 25 09:07:45 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Fri, 25 Mar 2022 09:07:45 GMT
Subject: RFR: 8282162: [vector] Optimize vector negation API
In-Reply-To: <p3lkqI9cxLgVusyCGgnHKdvdKvHBEM7k4K05wVTogu4=.65b852ba-7d1c-4dd9-af68-f1a238050dd3@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
 <-E5E_NBci6gsGyOV5nWuTUNKLVnjiw2IiWjjgv2vFz0=.ebe7c447-ede9-4437-815c-a2004f9d6ce1@github.com>
 <UIbbi5W7BMv_b9IuzYdCQOCzSNfJuHEvOOuqqRyhHUE=.cc631985-5ef3-4d93-a6d6-c73db7903412@github.com>
 <p3lkqI9cxLgVusyCGgnHKdvdKvHBEM7k4K05wVTogu4=.65b852ba-7d1c-4dd9-af68-f1a238050dd3@github.com>
Message-ID: <DaEG8ot4I0ZF1H8rzwx0ZlXqEDRKp0Vc82n-bow_pRc=.2b4f2a70-fb84-4663-aa88-377204934970@github.com>

On Sat, 19 Mar 2022 03:11:12 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>>> Note that in terms of Java semantics, negation of floating point values needs to be implemented as subtraction from negative zero rather than positive zero:
>>> 
>>> double negate(double arg) {return -0.0 - arg; }
>>> 
>>> This is to handle signed zeros correctly.
>> 
>> Hi @jddarcy ,thanks for looking at this PR and thanks for the notes on the floating point negation! Yeah, this really makes sense to me. Kindly note that this patch didn't touch the negation of the floating point values. For Vector API, the vector floating point negation has been intrinsified to `NegVF/D` node by compiler that we directly generate the negation instructions for them. Thanks!
>
>> Note that in terms of Java semantics, negation of floating point values needs to be implemented as subtraction from negative zero rather than positive zero:
>> 
>> double negate(double arg) {return -0.0 - arg; }
>> 
>> This is to handle signed zeros correctly.
> 
> This seems easy to be broken by an opt enhancement.
> Just wondering do we have a jtreg test for this point? @jddarcy 
> Thanks.

> Hi @DamonFool , thanks for your review! All the comments have been addressed. Thanks!

Thanks @XiaohongGong for the update.
And sorry for the late (just a little busy this week).

I'll do some testing and feedback here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From chagedorn at openjdk.java.net  Fri Mar 25 10:05:53 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 25 Mar 2022 10:05:53 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v2]
In-Reply-To: <uC10KRDlMqu_NSFuCyjYxb8UKUAB6A6AKAaI428zacs=.5d160a52-f1f7-4d52-a0e9-a08db63b573f@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <uC10KRDlMqu_NSFuCyjYxb8UKUAB6A6AKAaI428zacs=.5d160a52-f1f7-4d52-a0e9-a08db63b573f@github.com>
Message-ID: <cGpDpdbEclNpu0RYdAOXyZr7B6vNB8u38CbPCO_3_p0=.02ccdd36-c198-4a5a-9dd3-7e0fe0752b7a@github.com>

On Wed, 23 Mar 2022 08:20:57 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change adds a new view to the Ideal Graph Visualizer showing a classic control-flow graph (CFG) where nodes are serialized within basic blocks and arcs across basic blocks represent control flow:
>> 
>> ![cfg](https://user-images.githubusercontent.com/8792647/158367227-1ccfb9e0-bba1-4a80-963e-3e8c5f23c1c4.png)
>> 
>> The CFG provides a higher-level, more compact view of the graph than the existing views, where it can be hard to see the overall structure for all but the smallest graphs:
>> 
>> ![sea-vs-cfg](https://user-images.githubusercontent.com/8792647/158366842-f32b1b22-f7ed-4404-bb43-9d5c58a98ec4.png)
>> 
>> ![clusters-vs-cfg](https://user-images.githubusercontent.com/8792647/158366861-64561cfa-2553-4c9e-ad59-25acce6b4961.png)
>> 
>> If a schedule is available in the input graph (because it corresponds to the _Global code motion_ phase or later), the CFG, including the serialization of nodes within basic blocks, is derived from it. Otherwise, the CFG is approximated by the C2-specific `ServerCompilerScheduler` class. Dependencies among nodes are shown textually, by extending the label of each node with a list of its inputs:
>> 
>> <p align="center">
>>     <img width="35%" src="https://user-images.githubusercontent.com/8792647/158367428-5aa222e9-6a5c-4e78-871f-853e5b918599.png">
>> </p>
>> 
>> The exact information shown about each input can be configured in Tools -> Options -> Tiny Node Text.
>> 
>> The new CFG view is available at the same level as the existing "sea of nodes" (default) and "clustered sea-of-nodes" views. The view can be selected from the main toolbar:
>> 
>> ![toolbar](https://user-images.githubusercontent.com/8792647/158367502-ac8d8a29-5f35-4604-acc3-9d563c60e917.png)
>> 
>> The default view shown when opening a new graph can be configured in Tools -> Options -> Default View.
>> 
>> The same functionality available for the existing views also applies to the new CFG:
>> 
>> - node extraction:
>> 
>> ![node-extraction](https://user-images.githubusercontent.com/8792647/158371016-f7988eb6-368f-4805-ac7a-2b5611d16d7a.png)
>> 
>> - pop-up information on edges:
>> 
>> ![popup](https://user-images.githubusercontent.com/8792647/158367664-495189d5-384c-4b86-a62b-08863420c531.png)
>> 
>> - filtering:
>> 
>> ![filtering](https://user-images.githubusercontent.com/8792647/158367690-47b95bcd-7e8e-466e-b71b-f3e7d04c60ac.png)
>> 
>> - quick node and basic block search:
>> 
>> ![quick-search](https://user-images.githubusercontent.com/8792647/158367717-8bc90027-8ce7-4071-be04-1d67de6c91dd.png)
>> 
>> - and exporting.
>> 
>> The list of custom filters is extended with three new block-hiding filters:
>> 
>> - `Hide root block`: remove root block and hide all back-edges from exiting blocks that clutter the CFG.
>> 
>> - `Hide uncommon trap blocks`: remove blocks with uncommon traps to simplify following the "hot paths" in the CFG.
>> 
>> - `Hide exception blocks`: remove blocks that create and throw exceptions to also simplify following the "hot paths" in the CFG.
>> 
>> When using the CFG view, it is important to keep in mind that, in graphs corresponding to phases earlier than _Global code motion_, the presented CFG is just one of many possible projections of the sea-of-nodes representation, and that this projection is computed by an approximation of what C2 would do if it scheduled the graph at that stage. The approximation has some known limitations ([JDK-8280568](https://bugs.openjdk.java.net/browse/JDK-8280568), [JDK-8282053](https://bugs.openjdk.java.net/browse/JDK-8282053)). Future work should address these and warn the user when the approximated CFG is known to be inaccurate.
>> 
>> ### Testing
>> 
>> #### Functionality
>> 
>> - Tested the above functionality manually on a small selection of graphs.
>> 
>> - Tested automatically that scheduling (approximating C2's GCM and LCM algorithms) and viewing thousands of graphs in the three views does not trigger any assertion failure (by instrumenting IGV to schedule and view graphs as they are loaded and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).
>> 
>> #### Performance
>> 
>> - Measured the scheduling and view creation time for each of the three views on a selection of 22 large graphs (between 2515 and 7329 nodes). On average:
>> 
>> - The change introduces a slight overhead when creating the existing views (2% and 5% for the clustered and non-clustered sea-of-nodes views). This overhead is due to the introduction of abstractions and data structures required by the CFG view.
>> 
>> - The new CFG view is considerably faster to create than the existing ones (4.2x and 2.5x faster than the clustered and non-clustered sea-of-nodes views), as it can be expected, since only basic blocks have to be laid out. Furthermore, the CFG view scales better as the size of the graph increases.
>> 
>> - The change slows down scheduling by 27%. This overhead corresponds to the additional work of approximating C2's LCM, and it is essential for the CFG view. Fortunately, scheduling takes only a fraction of the time needed to create a view (typically no more than a third), and it only needs to run once for each graph, whereas views have to be re-created on node extraction, filtering, etc.
>> 
>> The performance results are [attached](https://github.com/openjdk/jdk/files/8252786/performance-evaluation.ods) (note that each measurement in the sheet corresponds to the median of ten runs).
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor code as suggested by Christian

> Thanks Christian for reviewing and providing so many suggestions! I have implemented all of them except a few for which I have provided separate answers.

Thanks for coming back with the updates - they look good!

> This is actually deliberate, I thought it would be useful to preserve the control-flow context, so that the user can at all times know e.g. whether a block she is looking at is within a loop.

I see that this can be valuable.

> Having said that, I agree that sometimes, particularly for large graphs, it would be useful to hide the empty blocks. This behavior would also be more consistent with the clustered sea-of-nodes view.

Yes, that was the problem I was experiencing when I was testing your new change with such a large graph. Among hundreds of empty blocks, the actually selected nodes were too widely spread such that the view became hard to use.

Thanks,
Christian

> Would it make sense to add a toolbar button to hide/show empty blocks in the control-flow graph view? If you think so, I will create a RFE to do that separately.

I think that would be great, thanks for considering it :-) And as you've mentioned above, for small graphs it helps to show the empty blocks as well. So, a toggle button would be a good choice.

src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Figure.java line 61:

> 59:     private int widthCash = -1;
> 60:     private InputBlock block;
> 61:     private FontMetrics metrics;

Can be made `final`.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7817

From chagedorn at openjdk.java.net  Fri Mar 25 10:05:54 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 25 Mar 2022 10:05:54 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v2]
In-Reply-To: <DVZNOdv_9InW27gwCRhDdia6KHCPFgGauVRMwXebz5Q=.965a7380-6441-4576-8663-63fcb1e4c193@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <2biNIQgrADSLZbAdbSDGvSpAnO8NdJLHRsRWHAhNYpw=.491f9738-9678-4412-b615-1b741b4364ed@github.com>
 <DVZNOdv_9InW27gwCRhDdia6KHCPFgGauVRMwXebz5Q=.965a7380-6441-4576-8663-63fcb1e4c193@github.com>
Message-ID: <Ji85i_T8QsNb9fSs2SfArthTelB9h7_v3UYNL6WOETo=.2ff00d4d-ff90-4219-813a-7a90240907f6@github.com>

On Wed, 23 Mar 2022 08:24:11 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/Connection.java line 38:
>> 
>>> 36:     }
>>> 37: 
>>> 38:     public ConnectionStyle getStyle();
>> 
>> `public` is implied for interface methods and does not need to be stated explicitly.
>
> I declared it explicitly as `public` for consistency with the rest of the IGV project. Updating all interfaces would be better addressed in a separate cleanup RFE, I think.

I agree, better change it all together in one go and keep the consistency for now.

>> src/utils/IdealGraphVisualizer/Graph/src/main/java/com/sun/hotspot/igv/graph/FigureConnection.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2008, 2022, Oracle and/or its affiliates. All rights reserved.
>> 
>> Should only be 2022 for a new file.
>
> This file is not really new, only renamed from the old `Connection.java` and slightly updated, hence I think it makes sense to leave the original initial year.

Okay, then it's fine.

>> src/utils/IdealGraphVisualizer/ServerCompiler/src/main/resources/com/sun/hotspot/igv/servercompiler/filters/hideExceptionBlocks.filter line 4:
>> 
>>> 2: 
>>> 3: var f = new RemoveBlockFilter("Hide exception blocks");
>>> 4: f.addRule(
>> 
>> Could the rule object directly be passed to the constructor instead of going over `addRule()`? On top of that, all filters follow the pattern "create f + `f.apply(graph)`". This could be moved into a single method to simplify filters. But this would exceed the scope of this change and could be done in a separate RFE.
>
> A filter can consist of multiple rules, see e.g. `ServerCompiler/src/main/resources/com/sun/hotspot/igv/servercompiler/filters/structural.filter`, so I think it makes sense to pass them separately. What could be done to reduce this complexity is to define more helper methods in `Filter/src/main/resources/com/sun/hotspot/igv/filter/helper.js`. As you suggest, I think this would be best done for all filters at once in a separate RFE.

Ah I see, I missed that. That would be a good option to provide more helper functions in an RFE to simplify the creation of new user filters.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7817

From rcastanedalo at openjdk.java.net  Fri Mar 25 10:29:00 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 25 Mar 2022 10:29:00 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v3]
In-Reply-To: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
Message-ID: <NQtRiYFx2_FiLpAUDa8qx96T27jFZt1yM0nk56rluno=.d9bc7262-4c90-4664-ba6b-88d5a1427f06@github.com>

> This change adds a new view to the Ideal Graph Visualizer showing a classic control-flow graph (CFG) where nodes are serialized within basic blocks and arcs across basic blocks represent control flow:
> 
> ![cfg](https://user-images.githubusercontent.com/8792647/158367227-1ccfb9e0-bba1-4a80-963e-3e8c5f23c1c4.png)
> 
> The CFG provides a higher-level, more compact view of the graph than the existing views, where it can be hard to see the overall structure for all but the smallest graphs:
> 
> ![sea-vs-cfg](https://user-images.githubusercontent.com/8792647/158366842-f32b1b22-f7ed-4404-bb43-9d5c58a98ec4.png)
> 
> ![clusters-vs-cfg](https://user-images.githubusercontent.com/8792647/158366861-64561cfa-2553-4c9e-ad59-25acce6b4961.png)
> 
> If a schedule is available in the input graph (because it corresponds to the _Global code motion_ phase or later), the CFG, including the serialization of nodes within basic blocks, is derived from it. Otherwise, the CFG is approximated by the C2-specific `ServerCompilerScheduler` class. Dependencies among nodes are shown textually, by extending the label of each node with a list of its inputs:
> 
> <p align="center">
>     <img width="35%" src="https://user-images.githubusercontent.com/8792647/158367428-5aa222e9-6a5c-4e78-871f-853e5b918599.png">
> </p>
> 
> The exact information shown about each input can be configured in Tools -> Options -> Tiny Node Text.
> 
> The new CFG view is available at the same level as the existing "sea of nodes" (default) and "clustered sea-of-nodes" views. The view can be selected from the main toolbar:
> 
> ![toolbar](https://user-images.githubusercontent.com/8792647/158367502-ac8d8a29-5f35-4604-acc3-9d563c60e917.png)
> 
> The default view shown when opening a new graph can be configured in Tools -> Options -> Default View.
> 
> The same functionality available for the existing views also applies to the new CFG:
> 
> - node extraction:
> 
> ![node-extraction](https://user-images.githubusercontent.com/8792647/158371016-f7988eb6-368f-4805-ac7a-2b5611d16d7a.png)
> 
> - pop-up information on edges:
> 
> ![popup](https://user-images.githubusercontent.com/8792647/158367664-495189d5-384c-4b86-a62b-08863420c531.png)
> 
> - filtering:
> 
> ![filtering](https://user-images.githubusercontent.com/8792647/158367690-47b95bcd-7e8e-466e-b71b-f3e7d04c60ac.png)
> 
> - quick node and basic block search:
> 
> ![quick-search](https://user-images.githubusercontent.com/8792647/158367717-8bc90027-8ce7-4071-be04-1d67de6c91dd.png)
> 
> - and exporting.
> 
> The list of custom filters is extended with three new block-hiding filters:
> 
> - `Hide root block`: remove root block and hide all back-edges from exiting blocks that clutter the CFG.
> 
> - `Hide uncommon trap blocks`: remove blocks with uncommon traps to simplify following the "hot paths" in the CFG.
> 
> - `Hide exception blocks`: remove blocks that create and throw exceptions to also simplify following the "hot paths" in the CFG.
> 
> When using the CFG view, it is important to keep in mind that, in graphs corresponding to phases earlier than _Global code motion_, the presented CFG is just one of many possible projections of the sea-of-nodes representation, and that this projection is computed by an approximation of what C2 would do if it scheduled the graph at that stage. The approximation has some known limitations ([JDK-8280568](https://bugs.openjdk.java.net/browse/JDK-8280568), [JDK-8282053](https://bugs.openjdk.java.net/browse/JDK-8282053)). Future work should address these and warn the user when the approximated CFG is known to be inaccurate.
> 
> ### Testing
> 
> #### Functionality
> 
> - Tested the above functionality manually on a small selection of graphs.
> 
> - Tested automatically that scheduling (approximating C2's GCM and LCM algorithms) and viewing thousands of graphs in the three views does not trigger any assertion failure (by instrumenting IGV to schedule and view graphs as they are loaded and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).
> 
> #### Performance
> 
> - Measured the scheduling and view creation time for each of the three views on a selection of 22 large graphs (between 2515 and 7329 nodes). On average:
> 
> - The change introduces a slight overhead when creating the existing views (2% and 5% for the clustered and non-clustered sea-of-nodes views). This overhead is due to the introduction of abstractions and data structures required by the CFG view.
> 
> - The new CFG view is considerably faster to create than the existing ones (4.2x and 2.5x faster than the clustered and non-clustered sea-of-nodes views), as it can be expected, since only basic blocks have to be laid out. Furthermore, the CFG view scales better as the size of the graph increases.
> 
> - The change slows down scheduling by 27%. This overhead corresponds to the additional work of approximating C2's LCM, and it is essential for the CFG view. Fortunately, scheduling takes only a fraction of the time needed to create a view (typically no more than a third), and it only needs to run once for each graph, whereas views have to be re-created on node extraction, filtering, etc.
> 
> The performance results are [attached](https://github.com/openjdk/jdk/files/8252786/performance-evaluation.ods) (note that each measurement in the sheet corresponds to the median of ten runs).

Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:

  Addressed last suggestion by Christian

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7817/files
  - new: https://git.openjdk.java.net/jdk/pull/7817/files/7b78cd7f..ae622849

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7817&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7817&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7817.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7817/head:pull/7817

PR: https://git.openjdk.java.net/jdk/pull/7817

From rcastanedalo at openjdk.java.net  Fri Mar 25 10:29:03 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Fri, 25 Mar 2022 10:29:03 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v2]
In-Reply-To: <cGpDpdbEclNpu0RYdAOXyZr7B6vNB8u38CbPCO_3_p0=.02ccdd36-c198-4a5a-9dd3-7e0fe0752b7a@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <uC10KRDlMqu_NSFuCyjYxb8UKUAB6A6AKAaI428zacs=.5d160a52-f1f7-4d52-a0e9-a08db63b573f@github.com>
 <cGpDpdbEclNpu0RYdAOXyZr7B6vNB8u38CbPCO_3_p0=.02ccdd36-c198-4a5a-9dd3-7e0fe0752b7a@github.com>
Message-ID: <gBMbG69IUUuVmwAjRX3dSaTCKbcNWhA86AqqH8vgxR0=.5e0ae3b2-cff4-4028-9e07-b0b0f947df7b@github.com>

On Fri, 25 Mar 2022 10:02:15 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> > Thanks Christian for reviewing and providing so many suggestions! I have implemented all of them except a few for which I have provided separate answers.
> 
> Thanks for coming back with the updates - they look good!
> 
> > This is actually deliberate, I thought it would be useful to preserve the control-flow context, so that the user can at all times know e.g. whether a block she is looking at is within a loop.
> 
> I see that this can be valuable.
> 
> > Having said that, I agree that sometimes, particularly for large graphs, it would be useful to hide the empty blocks. This behavior would also be more consistent with the clustered sea-of-nodes view.
> 
> Yes, that was the problem I was experiencing when I was testing your new change with such a large graph. Among hundreds of empty blocks, the actually selected nodes were too widely spread such that the view became hard to use.
> 
> > Would it make sense to add a toolbar button to hide/show empty blocks in the control-flow graph view? If you think so, I will create a RFE to do that separately.
> 
> I think that would be great, thanks for considering it :-) And as you've mentioned above, for small graphs it helps to show the empty blocks as well. So, a toggle button would be a good choice.
> 
> Thanks, Christian

Thanks again for reviewing! I just addressed your latest comment, will file a RFE for hiding/showing empty blocks as soon as this PR gets a second approval.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7817

From chagedorn at openjdk.java.net  Fri Mar 25 10:38:41 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Fri, 25 Mar 2022 10:38:41 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v3]
In-Reply-To: <NQtRiYFx2_FiLpAUDa8qx96T27jFZt1yM0nk56rluno=.d9bc7262-4c90-4664-ba6b-88d5a1427f06@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <NQtRiYFx2_FiLpAUDa8qx96T27jFZt1yM0nk56rluno=.d9bc7262-4c90-4664-ba6b-88d5a1427f06@github.com>
Message-ID: <82DjWD_Mt-uL214NhKN1GjvPjdbX1nwcn3njGUFK-XI=.35f683bf-ba69-4a00-b1d3-1ec5e93955fc@github.com>

On Fri, 25 Mar 2022 10:29:00 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change adds a new view to the Ideal Graph Visualizer showing a classic control-flow graph (CFG) where nodes are serialized within basic blocks and arcs across basic blocks represent control flow:
>> 
>> ![cfg](https://user-images.githubusercontent.com/8792647/158367227-1ccfb9e0-bba1-4a80-963e-3e8c5f23c1c4.png)
>> 
>> The CFG provides a higher-level, more compact view of the graph than the existing views, where it can be hard to see the overall structure for all but the smallest graphs:
>> 
>> ![sea-vs-cfg](https://user-images.githubusercontent.com/8792647/158366842-f32b1b22-f7ed-4404-bb43-9d5c58a98ec4.png)
>> 
>> ![clusters-vs-cfg](https://user-images.githubusercontent.com/8792647/158366861-64561cfa-2553-4c9e-ad59-25acce6b4961.png)
>> 
>> If a schedule is available in the input graph (because it corresponds to the _Global code motion_ phase or later), the CFG, including the serialization of nodes within basic blocks, is derived from it. Otherwise, the CFG is approximated by the C2-specific `ServerCompilerScheduler` class. Dependencies among nodes are shown textually, by extending the label of each node with a list of its inputs:
>> 
>> <p align="center">
>>     <img width="35%" src="https://user-images.githubusercontent.com/8792647/158367428-5aa222e9-6a5c-4e78-871f-853e5b918599.png">
>> </p>
>> 
>> The exact information shown about each input can be configured in Tools -> Options -> Tiny Node Text.
>> 
>> The new CFG view is available at the same level as the existing "sea of nodes" (default) and "clustered sea-of-nodes" views. The view can be selected from the main toolbar:
>> 
>> ![toolbar](https://user-images.githubusercontent.com/8792647/158367502-ac8d8a29-5f35-4604-acc3-9d563c60e917.png)
>> 
>> The default view shown when opening a new graph can be configured in Tools -> Options -> Default View.
>> 
>> The same functionality available for the existing views also applies to the new CFG:
>> 
>> - node extraction:
>> 
>> ![node-extraction](https://user-images.githubusercontent.com/8792647/158371016-f7988eb6-368f-4805-ac7a-2b5611d16d7a.png)
>> 
>> - pop-up information on edges:
>> 
>> ![popup](https://user-images.githubusercontent.com/8792647/158367664-495189d5-384c-4b86-a62b-08863420c531.png)
>> 
>> - filtering:
>> 
>> ![filtering](https://user-images.githubusercontent.com/8792647/158367690-47b95bcd-7e8e-466e-b71b-f3e7d04c60ac.png)
>> 
>> - quick node and basic block search:
>> 
>> ![quick-search](https://user-images.githubusercontent.com/8792647/158367717-8bc90027-8ce7-4071-be04-1d67de6c91dd.png)
>> 
>> - and exporting.
>> 
>> The list of custom filters is extended with three new block-hiding filters:
>> 
>> - `Hide root block`: remove root block and hide all back-edges from exiting blocks that clutter the CFG.
>> 
>> - `Hide uncommon trap blocks`: remove blocks with uncommon traps to simplify following the "hot paths" in the CFG.
>> 
>> - `Hide exception blocks`: remove blocks that create and throw exceptions to also simplify following the "hot paths" in the CFG.
>> 
>> When using the CFG view, it is important to keep in mind that, in graphs corresponding to phases earlier than _Global code motion_, the presented CFG is just one of many possible projections of the sea-of-nodes representation, and that this projection is computed by an approximation of what C2 would do if it scheduled the graph at that stage. The approximation has some known limitations ([JDK-8280568](https://bugs.openjdk.java.net/browse/JDK-8280568), [JDK-8282053](https://bugs.openjdk.java.net/browse/JDK-8282053)). Future work should address these and warn the user when the approximated CFG is known to be inaccurate.
>> 
>> ### Testing
>> 
>> #### Functionality
>> 
>> - Tested the above functionality manually on a small selection of graphs.
>> 
>> - Tested automatically that scheduling (approximating C2's GCM and LCM algorithms) and viewing thousands of graphs in the three views does not trigger any assertion failure (by instrumenting IGV to schedule and view graphs as they are loaded and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).
>> 
>> #### Performance
>> 
>> - Measured the scheduling and view creation time for each of the three views on a selection of 22 large graphs (between 2515 and 7329 nodes). On average:
>> 
>> - The change introduces a slight overhead when creating the existing views (2% and 5% for the clustered and non-clustered sea-of-nodes views). This overhead is due to the introduction of abstractions and data structures required by the CFG view.
>> 
>> - The new CFG view is considerably faster to create than the existing ones (4.2x and 2.5x faster than the clustered and non-clustered sea-of-nodes views), as it can be expected, since only basic blocks have to be laid out. Furthermore, the CFG view scales better as the size of the graph increases.
>> 
>> - The change slows down scheduling by 27%. This overhead corresponds to the additional work of approximating C2's LCM, and it is essential for the CFG view. Fortunately, scheduling takes only a fraction of the time needed to create a view (typically no more than a third), and it only needs to run once for each graph, whereas views have to be re-created on node extraction, filtering, etc.
>> 
>> The performance results are [attached](https://github.com/openjdk/jdk/files/8252786/performance-evaluation.ods) (note that each measurement in the sheet corresponds to the median of ten runs).
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed last suggestion by Christian

> will file a RFE for hiding/showing empty blocks as soon as this PR gets a second approval.

Thanks!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7817

From neliasso at openjdk.java.net  Fri Mar 25 16:27:51 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 25 Mar 2022 16:27:51 GMT
Subject: RFR: 8283692: Add PrintIdealPhase that includes block scheduling
Message-ID: <PshDgWdf8qtkdZQdJCMJK3Mo-5zxN5sbW59nEtcoEz4=.c1ffc2db-a1aa-4ae5-bcb3-d445d6a58e08@github.com>

Hi,

This patch adds:
1) A new method Output::print_scheduling() that encapsulates the ir node printing on blocks
2) Modifying print_ideal_ir to use the print_scheduling() when there is a scheduling available
3) A new compiler phase MACH_ANALYSIS after the mach dependent optimizations.

Motivation:
This is used by the IR-test framework when testing optimizations on mach-nodes, and is a requirement to be able to test peephole-optimizations (because peephole-removed nodes are only removed from the scheduling, not from the graph.)

Having a method for print_scheduling() is also very useful when debugging.

Please review,
Nils Eliasson

-------------

Commit messages:
 - 8283692: Add PrintIdealPhase that includes block scheduling

Changes: https://git.openjdk.java.net/jdk/pull/7960/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7960&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283692
  Stats: 40 lines in 4 files changed: 28 ins; 9 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7960.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7960/head:pull/7960

PR: https://git.openjdk.java.net/jdk/pull/7960

From kvn at openjdk.java.net  Fri Mar 25 19:46:50 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 25 Mar 2022 19:46:50 GMT
Subject: RFR: 8283692: Add PrintIdealPhase that includes block scheduling
In-Reply-To: <PshDgWdf8qtkdZQdJCMJK3Mo-5zxN5sbW59nEtcoEz4=.c1ffc2db-a1aa-4ae5-bcb3-d445d6a58e08@github.com>
References: <PshDgWdf8qtkdZQdJCMJK3Mo-5zxN5sbW59nEtcoEz4=.c1ffc2db-a1aa-4ae5-bcb3-d445d6a58e08@github.com>
Message-ID: <p2DFQvv1697_MrfbzhK4j-7HLRX9qufPEtK_JRruVAA=.ddf830be-229e-4b32-a516-c2e99149f77e@github.com>

On Fri, 25 Mar 2022 14:47:44 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Hi,
> 
> This patch adds:
> 1) A new method Output::print_scheduling() that encapsulates the ir node printing on blocks
> 2) Modifying print_ideal_ir to use the print_scheduling() when there is a scheduling available
> 3) A new compiler phase MACH_ANALYSIS after the mach dependent optimizations.
> 
> Motivation:
> This is used by the IR-test framework when testing optimizations on mach-nodes, and is a requirement to be able to test peephole-optimizations (because peephole-removed nodes are only removed from the scheduling, not from the graph.)
> 
> Having a method for print_scheduling() is also very useful when debugging.
> 
> Please review,
> Nils Eliasson

okay

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7960

From duke at openjdk.java.net  Fri Mar 25 21:05:16 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Fri, 25 Mar 2022 21:05:16 GMT
Subject: RFR: 8281453: New optimization: convert "c-(~x)" into "x+(c+1)"
 and "~(c-x)" into "x+(-c-1)" [v5]
In-Reply-To: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
References: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
Message-ID: <bRQUzCFYOO7j1E0AJgVcIBYQjO2gbV4M-4tJsw0GZFo=.6fcc0b71-edea-4773-9557-f54280280528@github.com>

> Similar to `(~x)+c` -> `(c-1)-x` and `~(x+c)` -> `(-c-1)-x` in #6858, we can also introduce similar optimizations for subtraction, `c-(~x)` -> `x+(c+1)` and `~(c-x)` -> `x+(-c-1)`.
> 
> The results of the microbenchmark are as follows:
> 
> Baseline:                                                                                                                                         
> Benchmark                        Mode  Cnt  Score   Error  Units
> SubIdealCMinusNotX.baselineInt   avgt   60  0.504 ? 0.011  ns/op
> SubIdealCMinusNotX.baselineLong  avgt   60  0.484 ? 0.004  ns/op
> SubIdealCMinusNotX.testInt1      avgt   60  0.779 ? 0.004  ns/op
> SubIdealCMinusNotX.testInt2      avgt   60  0.896 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong1     avgt   60  0.722 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong2     avgt   60  0.720 ? 0.005  ns/op
> 
> Patch:
> Benchmark                        Mode  Cnt  Score   Error  Units
> SubIdealCMinusNotX.baselineInt   avgt   60  0.487 ? 0.009  ns/op
> SubIdealCMinusNotX.baselineLong  avgt   60  0.486 ? 0.009  ns/op
> SubIdealCMinusNotX.testInt1      avgt   60  0.372 ? 0.010  ns/op
> SubIdealCMinusNotX.testInt2      avgt   60  0.365 ? 0.003  ns/op
> SubIdealCMinusNotX.testLong1     avgt   60  0.369 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong2     avgt   60  0.399 ? 0.016  ns/op

Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:

  merge tests into XXXINodeIdealizationTests

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7376/files
  - new: https://git.openjdk.java.net/jdk/pull/7376/files/5f1939c9..3f0d6a50

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7376&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7376&range=03-04

  Stats: 802 lines in 7 files changed: 169 ins; 629 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7376/head:pull/7376

PR: https://git.openjdk.java.net/jdk/pull/7376

From duke at openjdk.java.net  Fri Mar 25 21:11:54 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Fri, 25 Mar 2022 21:11:54 GMT
Subject: RFR: 8281453: New optimization: convert "c-(~x)" into "x+(c+1)"
 and "~(c-x)" into "x+(-c-1)"
In-Reply-To: <JxLShkjYwqKV0ECiSmpz_R7Za5SNLRLvd6HNw-R0Fsk=.dad28be6-4cc5-4d1e-b51c-ed5d4a243c88@github.com>
References: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
 <JxLShkjYwqKV0ECiSmpz_R7Za5SNLRLvd6HNw-R0Fsk=.dad28be6-4cc5-4d1e-b51c-ed5d4a243c88@github.com>
Message-ID: <wPI5XbeH9dsPVuIU15eR_8hJiFKcet9iv6BTKC7ybIQ=.dc8bfd09-f57c-4d3c-b4cc-40dec84918b5@github.com>

On Wed, 9 Feb 2022 16:12:30 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Similar to `(~x)+c` -> `(c-1)-x` and `~(x+c)` -> `(-c-1)-x` in #6858, we can also introduce similar optimizations for subtraction, `c-(~x)` -> `x+(c+1)` and `~(c-x)` -> `x+(-c-1)`.
>> 
>> The results of the microbenchmark are as follows:
>> 
>> Baseline:                                                                                                                                         
>> Benchmark                        Mode  Cnt  Score   Error  Units
>> SubIdealCMinusNotX.baselineInt   avgt   60  0.504 ? 0.011  ns/op
>> SubIdealCMinusNotX.baselineLong  avgt   60  0.484 ? 0.004  ns/op
>> SubIdealCMinusNotX.testInt1      avgt   60  0.779 ? 0.004  ns/op
>> SubIdealCMinusNotX.testInt2      avgt   60  0.896 ? 0.004  ns/op
>> SubIdealCMinusNotX.testLong1     avgt   60  0.722 ? 0.004  ns/op
>> SubIdealCMinusNotX.testLong2     avgt   60  0.720 ? 0.005  ns/op
>> 
>> Patch:
>> Benchmark                        Mode  Cnt  Score   Error  Units
>> SubIdealCMinusNotX.baselineInt   avgt   60  0.487 ? 0.009  ns/op
>> SubIdealCMinusNotX.baselineLong  avgt   60  0.486 ? 0.009  ns/op
>> SubIdealCMinusNotX.testInt1      avgt   60  0.372 ? 0.010  ns/op
>> SubIdealCMinusNotX.testInt2      avgt   60  0.365 ? 0.003  ns/op
>> SubIdealCMinusNotX.testLong1     avgt   60  0.369 ? 0.004  ns/op
>> SubIdealCMinusNotX.testLong2     avgt   60  0.399 ? 0.016  ns/op
>
> Since `~x == -1 - x` and these 2 operations' costs are essentially the same. It would be much easier if you just check whether the not result is used in an arithmetic operation and transform the former to the latter. The reverse is also true, if you find a `-1 - x` being fed into a bitwise just transform it to a `~x` then.
> Thanks.

Hello @merykitty I finished converting `~x` to `-1-x` when it appears in any add or sub nodes, as you suggested; so now it can really support a wide list of transformation: `c-(~x) => x + (c+1)`, `~x - ~y => y - x`, `(x+1) + ~y => x - y`, etc, which are all created as new tests. Can you help review again thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7376

From duke at openjdk.java.net  Fri Mar 25 21:16:03 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Fri, 25 Mar 2022 21:16:03 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con [v5]
In-Reply-To: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
Message-ID: <eDPR1Pnhl7pkWG3Epsc2X4sQWfOOPloJmZd9wy1SxLA=.8d7572bf-0a91-4c56-bb6a-ff580d6979e0@github.com>

> Hello,
> 
> `x + (con - y)  -> (x - y) + con` is a widely seen pattern; however it is missing in current implementation, which prevents some obvious constant folding from happening, such as `x + (1 - y) + 2` will be not optimized at all, rather than into `x - y + 3`.
> 
> This pull request adds this transformation.

Zhiqiang Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge master.
 - rename test cases.
 - move tests to existing test classes.
 - comment out "x+(0-y)" -> "(x-y)" and "(0-y)+x" -> "(x-y)" because they
   are covered already.
 - Merge master.
 - include transformation from (con - y) + x into (x - y) + con and x + (con - y) into (x - y) + con.

-------------

Changes: https://git.openjdk.java.net/jdk/pull/7795/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7795&range=04
  Stats: 133 lines in 5 files changed: 105 ins; 0 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7795/head:pull/7795

PR: https://git.openjdk.java.net/jdk/pull/7795

From duke at openjdk.java.net  Sat Mar 26 03:25:25 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Sat, 26 Mar 2022 03:25:25 GMT
Subject: RFR: 8281453: New optimization: convert "c-(~x)" into "x+(c+1)"
 and "~(c-x)" into "x+(-c-1)" [v6]
In-Reply-To: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
References: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
Message-ID: <yHuxfOsTW17PJOCaqnOMrpYetl4KB7KX8CpS7Fe-GYE=.d62fe529-a0ae-41ad-94ac-614bdcf381f5@github.com>

> Similar to `(~x)+c` -> `(c-1)-x` and `~(x+c)` -> `(-c-1)-x` in #6858, we can also introduce similar optimizations for subtraction, `c-(~x)` -> `x+(c+1)` and `~(c-x)` -> `x+(-c-1)`.
> 
> The results of the microbenchmark are as follows:
> 
> Baseline:                                                                                                                                         
> Benchmark                        Mode  Cnt  Score   Error  Units
> SubIdealCMinusNotX.baselineInt   avgt   60  0.504 ? 0.011  ns/op
> SubIdealCMinusNotX.baselineLong  avgt   60  0.484 ? 0.004  ns/op
> SubIdealCMinusNotX.testInt1      avgt   60  0.779 ? 0.004  ns/op
> SubIdealCMinusNotX.testInt2      avgt   60  0.896 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong1     avgt   60  0.722 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong2     avgt   60  0.720 ? 0.005  ns/op
> 
> Patch:
> Benchmark                        Mode  Cnt  Score   Error  Units
> SubIdealCMinusNotX.baselineInt   avgt   60  0.487 ? 0.009  ns/op
> SubIdealCMinusNotX.baselineLong  avgt   60  0.486 ? 0.009  ns/op
> SubIdealCMinusNotX.testInt1      avgt   60  0.372 ? 0.010  ns/op
> SubIdealCMinusNotX.testInt2      avgt   60  0.365 ? 0.003  ns/op
> SubIdealCMinusNotX.testLong1     avgt   60  0.369 ? 0.004  ns/op
> SubIdealCMinusNotX.testLong2     avgt   60  0.399 ? 0.016  ns/op

Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:

  clean.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7376/files
  - new: https://git.openjdk.java.net/jdk/pull/7376/files/3f0d6a50..666be2d8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7376&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7376&range=04-05

  Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7376/head:pull/7376

PR: https://git.openjdk.java.net/jdk/pull/7376

From duke at openjdk.java.net  Sat Mar 26 06:25:16 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sat, 26 Mar 2022 06:25:16 GMT
Subject: RFR: 8283694: Improve several operations on x86
Message-ID: <DoBINdgdk3jTGJbAbvWDdBDKXSqJujJQ6G9sPobENAI=.3f5ba9d3-f0c3-4786-ad16-2bfd05a3354a@github.com>

Hi, this patch improves some operations on x86_64:

- Base variable scalar shifts have bad performance implications and should be replaced by their bmi2 counterparts if possible:
  + Bounded operands
  + Multiple uops both in fused and unfused domains
  + May result in flag stall since the operations have unpredictable flag output

- Flag to general-purpose registers operation currently uses `cmovcc`, which requires set up and 1 more spare register for constant, this could be replaced by set, which transforms the sequence:

        xorl dst, dst
        sometest
        movl tmp, 0x01
        cmovlcc dst, tmp

        into:

        sometest
        setbcc dst
        movzbl dst, dst

This sequence does not need a spare register and without any drawbacks.
(Note: `movzx` is often elided and thus has 0 latency)

- Some small improvements:
  + Add memory variances to `tzcnt` and `lzcnt`
  + Add memory variances to `rolx` and `rorx`
  + Add missing `rolx` rules (note that `rolx dst, imm` is actually `rorx dst, size - imm`)

The speedup can be observed for variable shift instructions

        Before:
        Benchmark               (size)  Mode  Cnt   Score   Error  Units
        Integers.shiftLeft         500  avgt    5   0.836 ? 0.030  us/op
        Integers.shiftRight        500  avgt    5   0.843 ? 0.056  us/op
        Integers.shiftURight       500  avgt    5   0.830 ? 0.057  us/op
        Longs.shiftLeft            500  avgt    5   0.827 ? 0.026  us/op
        Longs.shiftRight           500  avgt    5   0.828 ? 0.018  us/op
        Longs.shiftURight          500  avgt    5   0.829 ? 0.038  us/op

        After:
        Benchmark               (size)  Mode  Cnt   Score   Error  Units
        Integers.shiftLeft         500  avgt    5   0.761 ? 0.016  us/op
        Integers.shiftRight        500  avgt    5   0.762 ? 0.071  us/op
        Integers.shiftURight       500  avgt    5   0.765 ? 0.056  us/op
        Longs.shiftLeft            500  avgt    5   0.755 ? 0.026  us/op
        Longs.shiftRight           500  avgt    5   0.753 ? 0.017  us/op
        Longs.shiftURight          500  avgt    5   0.759 ? 0.031  us/op

For `cmovcc 1, 0`, I have not been able to create a reliable microbenchmark since the benefits are mostly regarding register allocation.

Thank you very much.

-------------

Commit messages:
 - pipe
 - fix, benchmarks
 - pipe_class
 - reduce register pressure
 - cmov fix
 - operand
 - setcc for long
 - initial commit

Changes: https://git.openjdk.java.net/jdk/pull/7968/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7968&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283694
  Stats: 603 lines in 8 files changed: 566 ins; 4 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7968.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7968/head:pull/7968

PR: https://git.openjdk.java.net/jdk/pull/7968

From duke at openjdk.java.net  Sat Mar 26 07:35:25 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sat, 26 Mar 2022 07:35:25 GMT
Subject: RFR: 8283694: Improve several operations on x86 [v2]
In-Reply-To: <DoBINdgdk3jTGJbAbvWDdBDKXSqJujJQ6G9sPobENAI=.3f5ba9d3-f0c3-4786-ad16-2bfd05a3354a@github.com>
References: <DoBINdgdk3jTGJbAbvWDdBDKXSqJujJQ6G9sPobENAI=.3f5ba9d3-f0c3-4786-ad16-2bfd05a3354a@github.com>
Message-ID: <K2XNl7fEYX2HPLAvw56Y3IcP5iPSV6xAWA2q-b74MvM=.32f5109a-4448-47bc-afd5-4a830247a91d@github.com>

> Hi, this patch improves some operations on x86_64:
> 
> - Base variable scalar shifts have bad performance implications and should be replaced by their bmi2 counterparts if possible:
>   + Bounded operands
>   + Multiple uops both in fused and unfused domains
>   + May result in flag stall since the operations have unpredictable flag output
> 
> - Flag to general-purpose registers operation currently uses `cmovcc`, which requires set up and 1 more spare register for constant, this could be replaced by set, which transforms the sequence:
> 
>         xorl dst, dst
>         sometest
>         movl tmp, 0x01
>         cmovlcc dst, tmp
> 
>         into:
> 
>         sometest
>         setbcc dst
>         movzbl dst, dst
> 
> This sequence does not need a spare register and without any drawbacks.
> (Note: `movzx` is often elided and thus has 0 latency)
> 
> - Some small improvements:
>   + Add memory variances to `tzcnt` and `lzcnt`
>   + Add memory variances to `rolx` and `rorx`
>   + Add missing `rolx` rules (note that `rolx dst, imm` is actually `rorx dst, size - imm`)
> 
> The speedup can be observed for variable shift instructions
> 
>         Before:
>         Benchmark               (size)  Mode  Cnt   Score   Error  Units
>         Integers.shiftLeft         500  avgt    5   0.836 ? 0.030  us/op
>         Integers.shiftRight        500  avgt    5   0.843 ? 0.056  us/op
>         Integers.shiftURight       500  avgt    5   0.830 ? 0.057  us/op
>         Longs.shiftLeft            500  avgt    5   0.827 ? 0.026  us/op
>         Longs.shiftRight           500  avgt    5   0.828 ? 0.018  us/op
>         Longs.shiftURight          500  avgt    5   0.829 ? 0.038  us/op
> 
>         After:
>         Benchmark               (size)  Mode  Cnt   Score   Error  Units
>         Integers.shiftLeft         500  avgt    5   0.761 ? 0.016  us/op
>         Integers.shiftRight        500  avgt    5   0.762 ? 0.071  us/op
>         Integers.shiftURight       500  avgt    5   0.765 ? 0.056  us/op
>         Longs.shiftLeft            500  avgt    5   0.755 ? 0.026  us/op
>         Longs.shiftRight           500  avgt    5   0.753 ? 0.017  us/op
>         Longs.shiftURight          500  avgt    5   0.759 ? 0.031  us/op
> 
> For `cmovcc 1, 0`, I have not been able to create a reliable microbenchmark since the benefits are mostly regarding register allocation.
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  delete benchmark command

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7968/files
  - new: https://git.openjdk.java.net/jdk/pull/7968/files/ae8f3717..e970a2a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7968&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7968&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7968.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7968/head:pull/7968

PR: https://git.openjdk.java.net/jdk/pull/7968

From duke at openjdk.java.net  Sat Mar 26 15:17:24 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sat, 26 Mar 2022 15:17:24 GMT
Subject: RFR: 8283694: Improve several operations on x86 [v3]
In-Reply-To: <DoBINdgdk3jTGJbAbvWDdBDKXSqJujJQ6G9sPobENAI=.3f5ba9d3-f0c3-4786-ad16-2bfd05a3354a@github.com>
References: <DoBINdgdk3jTGJbAbvWDdBDKXSqJujJQ6G9sPobENAI=.3f5ba9d3-f0c3-4786-ad16-2bfd05a3354a@github.com>
Message-ID: <b73N22g6Y5KVfWjAt5vd6RszTP0gglDmcPQIED7iqMU=.9918d538-13cf-4b6e-b93d-a10ff8908de0@github.com>

> Hi, this patch improves some operations on x86_64:
> 
> - Base variable scalar shifts have bad performance implications and should be replaced by their bmi2 counterparts if possible:
>   + Bounded operands
>   + Multiple uops both in fused and unfused domains
>   + May result in flag stall since the operations have unpredictable flag output
> 
> - Flag to general-purpose registers operation currently uses `cmovcc`, which requires set up and 1 more spare register for constant, this could be replaced by set, which transforms the sequence:
> 
>         xorl dst, dst
>         sometest
>         movl tmp, 0x01
>         cmovlcc dst, tmp
> 
>         into:
> 
>         sometest
>         setbcc dst
>         movzbl dst, dst
> 
> This sequence does not need a spare register and without any drawbacks.
> (Note: `movzx` is often elided and thus has 0 latency)
> 
> - Some small improvements:
>   + Add memory variances to `tzcnt` and `lzcnt`
>   + Add memory variances to `rolx` and `rorx`
>   + Add missing `rolx` rules (note that `rolx dst, imm` is actually `rorx dst, size - imm`)
> 
> The speedup can be observed for variable shift instructions
> 
>         Before:
>         Benchmark               (size)  Mode  Cnt   Score   Error  Units
>         Integers.shiftLeft         500  avgt    5   0.836 ? 0.030  us/op
>         Integers.shiftRight        500  avgt    5   0.843 ? 0.056  us/op
>         Integers.shiftURight       500  avgt    5   0.830 ? 0.057  us/op
>         Longs.shiftLeft            500  avgt    5   0.827 ? 0.026  us/op
>         Longs.shiftRight           500  avgt    5   0.828 ? 0.018  us/op
>         Longs.shiftURight          500  avgt    5   0.829 ? 0.038  us/op
> 
>         After:
>         Benchmark               (size)  Mode  Cnt   Score   Error  Units
>         Integers.shiftLeft         500  avgt    5   0.761 ? 0.016  us/op
>         Integers.shiftRight        500  avgt    5   0.762 ? 0.071  us/op
>         Integers.shiftURight       500  avgt    5   0.765 ? 0.056  us/op
>         Longs.shiftLeft            500  avgt    5   0.755 ? 0.026  us/op
>         Longs.shiftRight           500  avgt    5   0.753 ? 0.017  us/op
>         Longs.shiftURight          500  avgt    5   0.759 ? 0.031  us/op
> 
> For `cmovcc 1, 0`, I have not been able to create a reliable microbenchmark since the benefits are mostly regarding register allocation.
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  cisc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7968/files
  - new: https://git.openjdk.java.net/jdk/pull/7968/files/e970a2a5..2e537bf2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7968&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7968&range=01-02

  Stats: 12 lines in 1 file changed: 6 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7968.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7968/head:pull/7968

PR: https://git.openjdk.java.net/jdk/pull/7968

From iklam at openjdk.java.net  Sat Mar 26 17:45:40 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 26 Mar 2022 17:45:40 GMT
Subject: RFR: 8283694: Improve several operations on x86 [v3]
In-Reply-To: <b73N22g6Y5KVfWjAt5vd6RszTP0gglDmcPQIED7iqMU=.9918d538-13cf-4b6e-b93d-a10ff8908de0@github.com>
References: <DoBINdgdk3jTGJbAbvWDdBDKXSqJujJQ6G9sPobENAI=.3f5ba9d3-f0c3-4786-ad16-2bfd05a3354a@github.com>
 <b73N22g6Y5KVfWjAt5vd6RszTP0gglDmcPQIED7iqMU=.9918d538-13cf-4b6e-b93d-a10ff8908de0@github.com>
Message-ID: <2xOl3I0pd_-zT0DBr2jRm6GtRuBiIO3Z4bnsyBV8DOs=.28b9320d-7a74-41a3-8955-923fe9983e1c@github.com>

On Sat, 26 Mar 2022 15:17:24 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi, this patch improves some operations on x86_64:
>> 
>> - Base variable scalar shifts have bad performance implications and should be replaced by their bmi2 counterparts if possible:
>>   + Bounded operands
>>   + Multiple uops both in fused and unfused domains
>>   + May result in flag stall since the operations have unpredictable flag output
>> 
>> - Flag to general-purpose registers operation currently uses `cmovcc`, which requires set up and 1 more spare register for constant, this could be replaced by set, which transforms the sequence:
>> 
>>         xorl dst, dst
>>         sometest
>>         movl tmp, 0x01
>>         cmovlcc dst, tmp
>> 
>>         into:
>> 
>>         sometest
>>         setbcc dst
>>         movzbl dst, dst
>> 
>> This sequence does not need a spare register and without any drawbacks.
>> (Note: `movzx` is often elided and thus has 0 latency)
>> 
>> - Some small improvements:
>>   + Add memory variances to `tzcnt` and `lzcnt`
>>   + Add memory variances to `rolx` and `rorx`
>>   + Add missing `rolx` rules (note that `rolx dst, imm` is actually `rorx dst, size - imm`)
>> 
>> The speedup can be observed for variable shift instructions
>> 
>>         Before:
>>         Benchmark               (size)  Mode  Cnt   Score   Error  Units
>>         Integers.shiftLeft         500  avgt    5   0.836 ? 0.030  us/op
>>         Integers.shiftRight        500  avgt    5   0.843 ? 0.056  us/op
>>         Integers.shiftURight       500  avgt    5   0.830 ? 0.057  us/op
>>         Longs.shiftLeft            500  avgt    5   0.827 ? 0.026  us/op
>>         Longs.shiftRight           500  avgt    5   0.828 ? 0.018  us/op
>>         Longs.shiftURight          500  avgt    5   0.829 ? 0.038  us/op
>> 
>>         After:
>>         Benchmark               (size)  Mode  Cnt   Score   Error  Units
>>         Integers.shiftLeft         500  avgt    5   0.761 ? 0.016  us/op
>>         Integers.shiftRight        500  avgt    5   0.762 ? 0.071  us/op
>>         Integers.shiftURight       500  avgt    5   0.765 ? 0.056  us/op
>>         Longs.shiftLeft            500  avgt    5   0.755 ? 0.026  us/op
>>         Longs.shiftRight           500  avgt    5   0.753 ? 0.017  us/op
>>         Longs.shiftURight          500  avgt    5   0.759 ? 0.031  us/op
>> 
>> For `cmovcc 1, 0`, I have not been able to create a reliable microbenchmark since the benefits are mostly regarding register allocation.
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cisc

Is it possible to change the RFE title to something more specific? The current title "Improve several operations on x86" makes it difficult to look up similar issues in the future.

Also, does any of the operations apply on 32-bit x86? If not, the RFE title should say x86_64.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7968

From duke at openjdk.java.net  Sun Mar 27 01:41:35 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sun, 27 Mar 2022 01:41:35 GMT
Subject: RFR: 8283694: Improve several operations on x86 [v4]
In-Reply-To: <DoBINdgdk3jTGJbAbvWDdBDKXSqJujJQ6G9sPobENAI=.3f5ba9d3-f0c3-4786-ad16-2bfd05a3354a@github.com>
References: <DoBINdgdk3jTGJbAbvWDdBDKXSqJujJQ6G9sPobENAI=.3f5ba9d3-f0c3-4786-ad16-2bfd05a3354a@github.com>
Message-ID: <WknzXBIelgVDYWf2CTe_N3qIThE3vkJuVamVx8AuxVU=.67109ba6-955f-4087-bfdb-72cdd75cf47e@github.com>

> Hi, this patch improves some operations on x86_64:
> 
> - Base variable scalar shifts have bad performance implications and should be replaced by their bmi2 counterparts if possible:
>   + Bounded operands
>   + Multiple uops both in fused and unfused domains
>   + May result in flag stall since the operations have unpredictable flag output
> 
> - Flag to general-purpose registers operation currently uses `cmovcc`, which requires set up and 1 more spare register for constant, this could be replaced by set, which transforms the sequence:
> 
>         xorl dst, dst
>         sometest
>         movl tmp, 0x01
>         cmovlcc dst, tmp
> 
>         into:
> 
>         sometest
>         setbcc dst
>         movzbl dst, dst
> 
> This sequence does not need a spare register and without any drawbacks.
> (Note: `movzx` is often elided and thus has 0 latency)
> 
> - Some small improvements:
>   + Add memory variances to `tzcnt` and `lzcnt`
>   + Add memory variances to `rolx` and `rorx`
>   + Add missing `rolx` rules (note that `rolx dst, imm` is actually `rorx dst, size - imm`)
> 
> The speedup can be observed for variable shift instructions
> 
>         Before:
>         Benchmark               (size)  Mode  Cnt   Score   Error  Units
>         Integers.shiftLeft         500  avgt    5   0.836 ? 0.030  us/op
>         Integers.shiftRight        500  avgt    5   0.843 ? 0.056  us/op
>         Integers.shiftURight       500  avgt    5   0.830 ? 0.057  us/op
>         Longs.shiftLeft            500  avgt    5   0.827 ? 0.026  us/op
>         Longs.shiftRight           500  avgt    5   0.828 ? 0.018  us/op
>         Longs.shiftURight          500  avgt    5   0.829 ? 0.038  us/op
> 
>         After:
>         Benchmark               (size)  Mode  Cnt   Score   Error  Units
>         Integers.shiftLeft         500  avgt    5   0.761 ? 0.016  us/op
>         Integers.shiftRight        500  avgt    5   0.762 ? 0.071  us/op
>         Integers.shiftURight       500  avgt    5   0.765 ? 0.056  us/op
>         Longs.shiftLeft            500  avgt    5   0.755 ? 0.026  us/op
>         Longs.shiftRight           500  avgt    5   0.753 ? 0.017  us/op
>         Longs.shiftURight          500  avgt    5   0.759 ? 0.031  us/op
> 
> For `cmovcc 1, 0`, I have not been able to create a reliable microbenchmark since the benefits are mostly regarding register allocation.
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:

 - fix only the needs
 - fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7968/files
  - new: https://git.openjdk.java.net/jdk/pull/7968/files/2e537bf2..75eb44ee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7968&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7968&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7968.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7968/head:pull/7968

PR: https://git.openjdk.java.net/jdk/pull/7968

From duke at openjdk.java.net  Sun Mar 27 01:45:44 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sun, 27 Mar 2022 01:45:44 GMT
Subject: RFR: 8283694: Improve bit manipulation and boolean to integer
 conversion operations on x86_64 [v4]
In-Reply-To: <WknzXBIelgVDYWf2CTe_N3qIThE3vkJuVamVx8AuxVU=.67109ba6-955f-4087-bfdb-72cdd75cf47e@github.com>
References: <DoBINdgdk3jTGJbAbvWDdBDKXSqJujJQ6G9sPobENAI=.3f5ba9d3-f0c3-4786-ad16-2bfd05a3354a@github.com>
 <WknzXBIelgVDYWf2CTe_N3qIThE3vkJuVamVx8AuxVU=.67109ba6-955f-4087-bfdb-72cdd75cf47e@github.com>
Message-ID: <_V7Q2URlUMlRsfPlLSx5v2gaYnuPyHrkcBAc50GDUPE=.42e7a4d5-d443-47ea-8fb3-dfc7d843af62@github.com>

On Sun, 27 Mar 2022 01:41:35 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

>> Hi, this patch improves some operations on x86_64:
>> 
>> - Base variable scalar shifts have bad performance implications and should be replaced by their bmi2 counterparts if possible:
>>   + Bounded operands
>>   + Multiple uops both in fused and unfused domains
>>   + May result in flag stall since the operations have unpredictable flag output
>> 
>> - Flag to general-purpose registers operation currently uses `cmovcc`, which requires set up and 1 more spare register for constant, this could be replaced by set, which transforms the sequence:
>> 
>>         xorl dst, dst
>>         sometest
>>         movl tmp, 0x01
>>         cmovlcc dst, tmp
>> 
>>         into:
>> 
>>         sometest
>>         setbcc dst
>>         movzbl dst, dst
>> 
>> This sequence does not need a spare register and without any drawbacks.
>> (Note: `movzx` is often elided and thus has 0 latency)
>> 
>> - Some small improvements:
>>   + Add memory variances to `tzcnt` and `lzcnt`
>>   + Add memory variances to `rolx` and `rorx`
>>   + Add missing `rolx` rules (note that `rolx dst, imm` is actually `rorx dst, size - imm`)
>> 
>> The speedup can be observed for variable shift instructions
>> 
>>         Before:
>>         Benchmark               (size)  Mode  Cnt   Score   Error  Units
>>         Integers.shiftLeft         500  avgt    5   0.836 ? 0.030  us/op
>>         Integers.shiftRight        500  avgt    5   0.843 ? 0.056  us/op
>>         Integers.shiftURight       500  avgt    5   0.830 ? 0.057  us/op
>>         Longs.shiftLeft            500  avgt    5   0.827 ? 0.026  us/op
>>         Longs.shiftRight           500  avgt    5   0.828 ? 0.018  us/op
>>         Longs.shiftURight          500  avgt    5   0.829 ? 0.038  us/op
>> 
>>         After:
>>         Benchmark               (size)  Mode  Cnt   Score   Error  Units
>>         Integers.shiftLeft         500  avgt    5   0.761 ? 0.016  us/op
>>         Integers.shiftRight        500  avgt    5   0.762 ? 0.071  us/op
>>         Integers.shiftURight       500  avgt    5   0.765 ? 0.056  us/op
>>         Longs.shiftLeft            500  avgt    5   0.755 ? 0.026  us/op
>>         Longs.shiftRight           500  avgt    5   0.753 ? 0.017  us/op
>>         Longs.shiftURight          500  avgt    5   0.759 ? 0.031  us/op
>> 
>> For `cmovcc 1, 0`, I have not been able to create a reliable microbenchmark since the benefits are mostly regarding register allocation.
>> 
>> Thank you very much.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix only the needs
>  - fix

I have adjusted the title to be more specific and accurate. Thank you very much.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7968

From duke at openjdk.java.net  Sun Mar 27 09:40:27 2022
From: duke at openjdk.java.net (Quan Anh Mai)
Date: Sun, 27 Mar 2022 09:40:27 GMT
Subject: RFR: 8283694: Improve bit manipulation and boolean to integer
 conversion operations on x86_64 [v5]
In-Reply-To: <DoBINdgdk3jTGJbAbvWDdBDKXSqJujJQ6G9sPobENAI=.3f5ba9d3-f0c3-4786-ad16-2bfd05a3354a@github.com>
References: <DoBINdgdk3jTGJbAbvWDdBDKXSqJujJQ6G9sPobENAI=.3f5ba9d3-f0c3-4786-ad16-2bfd05a3354a@github.com>
Message-ID: <57qegxzx9yzK_pkW7KMkN1l-Ip3YTSbK1LWITO1xRr8=.e8ceb9c4-5ec2-456f-94ac-1f834ff3aead@github.com>

> Hi, this patch improves some operations on x86_64:
> 
> - Base variable scalar shifts have bad performance implications and should be replaced by their bmi2 counterparts if possible:
>   + Bounded operands
>   + Multiple uops both in fused and unfused domains
>   + May result in flag stall since the operations have unpredictable flag output
> 
> - Flag to general-purpose registers operation currently uses `cmovcc`, which requires set up and 1 more spare register for constant, this could be replaced by set, which transforms the sequence:
> 
>         xorl dst, dst
>         sometest
>         movl tmp, 0x01
>         cmovlcc dst, tmp
> 
>         into:
> 
>         xorl dst, dst
>         sometest
>         setbcc dst
> 
> This sequence does not need a spare register and without any drawbacks.
> (Note: `movzx` does not work since move elision only occurs with different registers for input and output)
> 
> - Some small improvements:
>   + Add memory variances to `tzcnt` and `lzcnt`
>   + Add memory variances to `rolx` and `rorx`
>   + Add missing `rolx` rules (note that `rolx dst, imm` is actually `rorx dst, size - imm`)
> 
> The speedup can be observed for variable shift instructions
> 
>         Before:
>         Benchmark               (size)  Mode  Cnt   Score   Error  Units
>         Integers.shiftLeft         500  avgt    5   0.836 ? 0.030  us/op
>         Integers.shiftRight        500  avgt    5   0.843 ? 0.056  us/op
>         Integers.shiftURight       500  avgt    5   0.830 ? 0.057  us/op
>         Longs.shiftLeft            500  avgt    5   0.827 ? 0.026  us/op
>         Longs.shiftRight           500  avgt    5   0.828 ? 0.018  us/op
>         Longs.shiftURight          500  avgt    5   0.829 ? 0.038  us/op
> 
>         After:
>         Benchmark               (size)  Mode  Cnt   Score   Error  Units
>         Integers.shiftLeft         500  avgt    5   0.761 ? 0.016  us/op
>         Integers.shiftRight        500  avgt    5   0.762 ? 0.071  us/op
>         Integers.shiftURight       500  avgt    5   0.765 ? 0.056  us/op
>         Longs.shiftLeft            500  avgt    5   0.755 ? 0.026  us/op
>         Longs.shiftRight           500  avgt    5   0.753 ? 0.017  us/op
>         Longs.shiftURight          500  avgt    5   0.759 ? 0.031  us/op
> 
> For `cmovcc 1, 0`, I have not been able to create a reliable microbenchmark since the benefits are mostly regarding register allocation.
> 
> Thank you very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  movzx is not elided with same input and output

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7968/files
  - new: https://git.openjdk.java.net/jdk/pull/7968/files/75eb44ee..52bf8a41

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7968&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7968&range=03-04

  Stats: 60 lines in 1 file changed: 8 ins; 14 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7968.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7968/head:pull/7968

PR: https://git.openjdk.java.net/jdk/pull/7968

From xliu at openjdk.java.net  Sun Mar 27 19:23:49 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Sun, 27 Mar 2022 19:23:49 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v3]
In-Reply-To: <NQtRiYFx2_FiLpAUDa8qx96T27jFZt1yM0nk56rluno=.d9bc7262-4c90-4664-ba6b-88d5a1427f06@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <NQtRiYFx2_FiLpAUDa8qx96T27jFZt1yM0nk56rluno=.d9bc7262-4c90-4664-ba6b-88d5a1427f06@github.com>
Message-ID: <3N0OdUbNtd3eyA1LlC4PVwrq4vFqUafxIeBPV2UZBRM=.17036fc8-a133-4658-8bd0-5290f04fd212@github.com>

On Fri, 25 Mar 2022 10:29:00 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change adds a new view to the Ideal Graph Visualizer showing a classic control-flow graph (CFG) where nodes are serialized within basic blocks and arcs across basic blocks represent control flow:
>> 
>> ![cfg](https://user-images.githubusercontent.com/8792647/158367227-1ccfb9e0-bba1-4a80-963e-3e8c5f23c1c4.png)
>> 
>> The CFG provides a higher-level, more compact view of the graph than the existing views, where it can be hard to see the overall structure for all but the smallest graphs:
>> 
>> ![sea-vs-cfg](https://user-images.githubusercontent.com/8792647/158366842-f32b1b22-f7ed-4404-bb43-9d5c58a98ec4.png)
>> 
>> ![clusters-vs-cfg](https://user-images.githubusercontent.com/8792647/158366861-64561cfa-2553-4c9e-ad59-25acce6b4961.png)
>> 
>> If a schedule is available in the input graph (because it corresponds to the _Global code motion_ phase or later), the CFG, including the serialization of nodes within basic blocks, is derived from it. Otherwise, the CFG is approximated by the C2-specific `ServerCompilerScheduler` class. Dependencies among nodes are shown textually, by extending the label of each node with a list of its inputs:
>> 
>> <p align="center">
>>     <img width="35%" src="https://user-images.githubusercontent.com/8792647/158367428-5aa222e9-6a5c-4e78-871f-853e5b918599.png">
>> </p>
>> 
>> The exact information shown about each input can be configured in Tools -> Options -> Tiny Node Text.
>> 
>> The new CFG view is available at the same level as the existing "sea of nodes" (default) and "clustered sea-of-nodes" views. The view can be selected from the main toolbar:
>> 
>> ![toolbar](https://user-images.githubusercontent.com/8792647/158367502-ac8d8a29-5f35-4604-acc3-9d563c60e917.png)
>> 
>> The default view shown when opening a new graph can be configured in Tools -> Options -> Default View.
>> 
>> The same functionality available for the existing views also applies to the new CFG:
>> 
>> - node extraction:
>> 
>> ![node-extraction](https://user-images.githubusercontent.com/8792647/158371016-f7988eb6-368f-4805-ac7a-2b5611d16d7a.png)
>> 
>> - pop-up information on edges:
>> 
>> ![popup](https://user-images.githubusercontent.com/8792647/158367664-495189d5-384c-4b86-a62b-08863420c531.png)
>> 
>> - filtering:
>> 
>> ![filtering](https://user-images.githubusercontent.com/8792647/158367690-47b95bcd-7e8e-466e-b71b-f3e7d04c60ac.png)
>> 
>> - quick node and basic block search:
>> 
>> ![quick-search](https://user-images.githubusercontent.com/8792647/158367717-8bc90027-8ce7-4071-be04-1d67de6c91dd.png)
>> 
>> - and exporting.
>> 
>> The list of custom filters is extended with three new block-hiding filters:
>> 
>> - `Hide root block`: remove root block and hide all back-edges from exiting blocks that clutter the CFG.
>> 
>> - `Hide uncommon trap blocks`: remove blocks with uncommon traps to simplify following the "hot paths" in the CFG.
>> 
>> - `Hide exception blocks`: remove blocks that create and throw exceptions to also simplify following the "hot paths" in the CFG.
>> 
>> When using the CFG view, it is important to keep in mind that, in graphs corresponding to phases earlier than _Global code motion_, the presented CFG is just one of many possible projections of the sea-of-nodes representation, and that this projection is computed by an approximation of what C2 would do if it scheduled the graph at that stage. The approximation has some known limitations ([JDK-8280568](https://bugs.openjdk.java.net/browse/JDK-8280568), [JDK-8282053](https://bugs.openjdk.java.net/browse/JDK-8282053)). Future work should address these and warn the user when the approximated CFG is known to be inaccurate.
>> 
>> ### Testing
>> 
>> #### Functionality
>> 
>> - Tested the above functionality manually on a small selection of graphs.
>> 
>> - Tested automatically that scheduling (approximating C2's GCM and LCM algorithms) and viewing thousands of graphs in the three views does not trigger any assertion failure (by instrumenting IGV to schedule and view graphs as they are loaded and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).
>> 
>> #### Performance
>> 
>> - Measured the scheduling and view creation time for each of the three views on a selection of 22 large graphs (between 2515 and 7329 nodes). On average:
>> 
>> - The change introduces a slight overhead when creating the existing views (2% and 5% for the clustered and non-clustered sea-of-nodes views). This overhead is due to the introduction of abstractions and data structures required by the CFG view.
>> 
>> - The new CFG view is considerably faster to create than the existing ones (4.2x and 2.5x faster than the clustered and non-clustered sea-of-nodes views), as it can be expected, since only basic blocks have to be laid out. Furthermore, the CFG view scales better as the size of the graph increases.
>> 
>> - The change slows down scheduling by 27%. This overhead corresponds to the additional work of approximating C2's LCM, and it is essential for the CFG view. Fortunately, scheduling takes only a fraction of the time needed to create a view (typically no more than a third), and it only needs to run once for each graph, whereas views have to be re-created on node extraction, filtering, etc.
>> 
>> The performance results are [attached](https://github.com/openjdk/jdk/files/8252786/performance-evaluation.ods) (note that each measurement in the sheet corresponds to the median of ten runs).
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed last suggestion by Christian

src/utils/IdealGraphVisualizer/ServerCompiler/src/main/resources/com/sun/hotspot/igv/servercompiler/filters/hideUncommonTrapBlocks.filter line 8:

> 6:     new AnySelector(
> 7:       new MatcherSelector(
> 8:         new Properties.RegexpPropertyMatcher("dump_spec", ".*uncommon_trap.*")

I have this filter too! It's very helpful to reduce clutter!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7817

From xliu at openjdk.java.net  Sun Mar 27 22:02:48 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Sun, 27 Mar 2022 22:02:48 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v3]
In-Reply-To: <NQtRiYFx2_FiLpAUDa8qx96T27jFZt1yM0nk56rluno=.d9bc7262-4c90-4664-ba6b-88d5a1427f06@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <NQtRiYFx2_FiLpAUDa8qx96T27jFZt1yM0nk56rluno=.d9bc7262-4c90-4664-ba6b-88d5a1427f06@github.com>
Message-ID: <Eb2qPoutYxdhJODLCcot4XYLM_YSk7RnlOwRVHvWxsw=.8648f783-c45e-4106-8bb7-00455f5a722e@github.com>

On Fri, 25 Mar 2022 10:29:00 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change adds a new view to the Ideal Graph Visualizer showing a classic control-flow graph (CFG) where nodes are serialized within basic blocks and arcs across basic blocks represent control flow:
>> 
>> ![cfg](https://user-images.githubusercontent.com/8792647/158367227-1ccfb9e0-bba1-4a80-963e-3e8c5f23c1c4.png)
>> 
>> The CFG provides a higher-level, more compact view of the graph than the existing views, where it can be hard to see the overall structure for all but the smallest graphs:
>> 
>> ![sea-vs-cfg](https://user-images.githubusercontent.com/8792647/158366842-f32b1b22-f7ed-4404-bb43-9d5c58a98ec4.png)
>> 
>> ![clusters-vs-cfg](https://user-images.githubusercontent.com/8792647/158366861-64561cfa-2553-4c9e-ad59-25acce6b4961.png)
>> 
>> If a schedule is available in the input graph (because it corresponds to the _Global code motion_ phase or later), the CFG, including the serialization of nodes within basic blocks, is derived from it. Otherwise, the CFG is approximated by the C2-specific `ServerCompilerScheduler` class. Dependencies among nodes are shown textually, by extending the label of each node with a list of its inputs:
>> 
>> <p align="center">
>>     <img width="35%" src="https://user-images.githubusercontent.com/8792647/158367428-5aa222e9-6a5c-4e78-871f-853e5b918599.png">
>> </p>
>> 
>> The exact information shown about each input can be configured in Tools -> Options -> Tiny Node Text.
>> 
>> The new CFG view is available at the same level as the existing "sea of nodes" (default) and "clustered sea-of-nodes" views. The view can be selected from the main toolbar:
>> 
>> ![toolbar](https://user-images.githubusercontent.com/8792647/158367502-ac8d8a29-5f35-4604-acc3-9d563c60e917.png)
>> 
>> The default view shown when opening a new graph can be configured in Tools -> Options -> Default View.
>> 
>> The same functionality available for the existing views also applies to the new CFG:
>> 
>> - node extraction:
>> 
>> ![node-extraction](https://user-images.githubusercontent.com/8792647/158371016-f7988eb6-368f-4805-ac7a-2b5611d16d7a.png)
>> 
>> - pop-up information on edges:
>> 
>> ![popup](https://user-images.githubusercontent.com/8792647/158367664-495189d5-384c-4b86-a62b-08863420c531.png)
>> 
>> - filtering:
>> 
>> ![filtering](https://user-images.githubusercontent.com/8792647/158367690-47b95bcd-7e8e-466e-b71b-f3e7d04c60ac.png)
>> 
>> - quick node and basic block search:
>> 
>> ![quick-search](https://user-images.githubusercontent.com/8792647/158367717-8bc90027-8ce7-4071-be04-1d67de6c91dd.png)
>> 
>> - and exporting.
>> 
>> The list of custom filters is extended with three new block-hiding filters:
>> 
>> - `Hide root block`: remove root block and hide all back-edges from exiting blocks that clutter the CFG.
>> 
>> - `Hide uncommon trap blocks`: remove blocks with uncommon traps to simplify following the "hot paths" in the CFG.
>> 
>> - `Hide exception blocks`: remove blocks that create and throw exceptions to also simplify following the "hot paths" in the CFG.
>> 
>> When using the CFG view, it is important to keep in mind that, in graphs corresponding to phases earlier than _Global code motion_, the presented CFG is just one of many possible projections of the sea-of-nodes representation, and that this projection is computed by an approximation of what C2 would do if it scheduled the graph at that stage. The approximation has some known limitations ([JDK-8280568](https://bugs.openjdk.java.net/browse/JDK-8280568), [JDK-8282053](https://bugs.openjdk.java.net/browse/JDK-8282053)). Future work should address these and warn the user when the approximated CFG is known to be inaccurate.
>> 
>> ### Testing
>> 
>> #### Functionality
>> 
>> - Tested the above functionality manually on a small selection of graphs.
>> 
>> - Tested automatically that scheduling (approximating C2's GCM and LCM algorithms) and viewing thousands of graphs in the three views does not trigger any assertion failure (by instrumenting IGV to schedule and view graphs as they are loaded and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).
>> 
>> #### Performance
>> 
>> - Measured the scheduling and view creation time for each of the three views on a selection of 22 large graphs (between 2515 and 7329 nodes). On average:
>> 
>> - The change introduces a slight overhead when creating the existing views (2% and 5% for the clustered and non-clustered sea-of-nodes views). This overhead is due to the introduction of abstractions and data structures required by the CFG view.
>> 
>> - The new CFG view is considerably faster to create than the existing ones (4.2x and 2.5x faster than the clustered and non-clustered sea-of-nodes views), as it can be expected, since only basic blocks have to be laid out. Furthermore, the CFG view scales better as the size of the graph increases.
>> 
>> - The change slows down scheduling by 27%. This overhead corresponds to the additional work of approximating C2's LCM, and it is essential for the CFG view. Fortunately, scheduling takes only a fraction of the time needed to create a view (typically no more than a third), and it only needs to run once for each graph, whereas views have to be re-created on node extraction, filtering, etc.
>> 
>> The performance results are [attached](https://github.com/openjdk/jdk/files/8252786/performance-evaluation.ods) (note that each measurement in the sheet corresponds to the median of ten runs).
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed last suggestion by Christian

src/utils/IdealGraphVisualizer/ServerCompiler/src/main/java/com/sun/hotspot/igv/servercompiler/ServerCompilerScheduler.java line 61:

> 59:             inputNode = n;
> 60:             String p = n.getProperties().get("is_block_proj");
> 61:             isBlockProjection = (p != null && p.equals("true"));

is it easy to flip equals here? 
"true".equals(p) can avoid nullcheck.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7817

From fgao at openjdk.java.net  Mon Mar 28 02:19:11 2022
From: fgao at openjdk.java.net (Fei Gao)
Date: Mon, 28 Mar 2022 02:19:11 GMT
Subject: RFR: 8283307: Vectorize unsigned shift right on signed subword types
Message-ID: <EyCdo1mIa3_Nkn29y-f11hs2EJ1WstGs8vEfuAKhszI=.fcee79c5-566b-47fa-a7af-a44a48fe3cf6@github.com>

public short[] vectorUnsignedShiftRight(short[] shorts) {
    short[] res = new short[SIZE];
    for (int i = 0; i < SIZE; i++) {
        res[i] = (short) (shorts[i] >>> 3);
    }
    return res;
}

In C2's SLP, vectorization of unsigned shift right on signed subword types (byte/short) like the case above is intentionally disabled[1]. Because the vector unsigned shift on signed subword types behaves differently from the Java spec. It's worthy to vectorize more cases in quite low cost. Also, unsigned shift right on signed subword is not uncommon and we may find similar cases in Lucene benchmark[2].

Taking unsigned right shift on short type as an example,
![image](https://user-images.githubusercontent.com/39403138/160313924-6bded802-c135-48db-98b8-7c5f43d8ff54.png)

when the shift amount is a constant not greater than the number of sign extended bits, 16 higher bits for short type shown like
above, the unsigned shift on signed subword types can be transformed into a signed shift and hence becomes vectorizable. Here is the transformation:
![image](https://user-images.githubusercontent.com/39403138/160314151-30249bfc-bdfc-4700-b4fb-97617b45184b.png)

This patch does the transformation in `SuperWord::implemented()` and `SuperWord::output()`. It helps vectorize the short cases above. We can handle unsigned right shift on byte type in a similar way. The generated assembly code for one iteration on aarch64 is like:

...
sbfiz   x13, x10, #1, #32
add     x15, x11, x13
ldr     q16, [x15, #16]
sshr    v16.8h, v16.8h, #3
add     x13, x17, x13
str     q16, [x13, #16]
...


Here is the performance data for micro-benchmark before and after this patch on both AArch64 and x64 machines. We can observe about ~80% improvement with this patch.

The perf data on AArch64:
Before the patch:
Benchmark        (SIZE)  (shiftCount)  Mode  Cnt    Score   Error  Units
urShiftImmByte    1024         3       avgt    5  295.711 ? 0.117  ns/op
urShiftImmShort   1024         3       avgt    5  284.559 ? 0.148  ns/op

after the patch:
Benchmark         (SIZE) (shiftCount)  Mode  Cnt    Score   Error  Units
urShiftImmByte     1024        3       avgt    5   45.111 ? 0.047  ns/op
urShiftImmShort    1024        3       avgt    5   55.294 ? 0.072  ns/op

The perf data on X86:
Before the patch:
Benchmark        (SIZE) (shiftCount)  Mode  Cnt    Score    Error  Units
urShiftImmByte    1024        3       avgt    5  361.374 ?  4.621  ns/op
urShiftImmShort   1024        3       avgt    5  365.390 ?  3.595  ns/op

After the patch:
Benchmark        (SIZE) (shiftCount)  Mode  Cnt    Score    Error  Units
urShiftImmByte    1024        3       avgt    5  105.489 ?  0.488  ns/op
urShiftImmShort   1024        3       avgt    5   43.400 ?  0.394  ns/op

[1] https://github.com/openjdk/jdk/blob/002e3667443d94e2303c875daf72cf1ccbbb0099/src/hotspot/share/opto/vectornode.cpp#L190
[2] https://github.com/jpountz/decode-128-ints-benchmark/

-------------

Commit messages:
 - 8283307: Vectorize unsigned shift right on signed subword types

Changes: https://git.openjdk.java.net/jdk/pull/7979/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7979&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283307
  Stats: 203 lines in 6 files changed: 203 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7979.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7979/head:pull/7979

PR: https://git.openjdk.java.net/jdk/pull/7979

From xliu at openjdk.java.net  Mon Mar 28 03:39:51 2022
From: xliu at openjdk.java.net (Xin Liu)
Date: Mon, 28 Mar 2022 03:39:51 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v3]
In-Reply-To: <NQtRiYFx2_FiLpAUDa8qx96T27jFZt1yM0nk56rluno=.d9bc7262-4c90-4664-ba6b-88d5a1427f06@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <NQtRiYFx2_FiLpAUDa8qx96T27jFZt1yM0nk56rluno=.d9bc7262-4c90-4664-ba6b-88d5a1427f06@github.com>
Message-ID: <ryLuyZpNXUfQG5NjLlN6i8_xYmxGtbVOjWVqObNPGY8=.206bc9b8-43c5-4b51-a11f-54fc1a516d08@github.com>

On Fri, 25 Mar 2022 10:29:00 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change adds a new view to the Ideal Graph Visualizer showing a classic control-flow graph (CFG) where nodes are serialized within basic blocks and arcs across basic blocks represent control flow:
>> 
>> ![cfg](https://user-images.githubusercontent.com/8792647/158367227-1ccfb9e0-bba1-4a80-963e-3e8c5f23c1c4.png)
>> 
>> The CFG provides a higher-level, more compact view of the graph than the existing views, where it can be hard to see the overall structure for all but the smallest graphs:
>> 
>> ![sea-vs-cfg](https://user-images.githubusercontent.com/8792647/158366842-f32b1b22-f7ed-4404-bb43-9d5c58a98ec4.png)
>> 
>> ![clusters-vs-cfg](https://user-images.githubusercontent.com/8792647/158366861-64561cfa-2553-4c9e-ad59-25acce6b4961.png)
>> 
>> If a schedule is available in the input graph (because it corresponds to the _Global code motion_ phase or later), the CFG, including the serialization of nodes within basic blocks, is derived from it. Otherwise, the CFG is approximated by the C2-specific `ServerCompilerScheduler` class. Dependencies among nodes are shown textually, by extending the label of each node with a list of its inputs:
>> 
>> <p align="center">
>>     <img width="35%" src="https://user-images.githubusercontent.com/8792647/158367428-5aa222e9-6a5c-4e78-871f-853e5b918599.png">
>> </p>
>> 
>> The exact information shown about each input can be configured in Tools -> Options -> Tiny Node Text.
>> 
>> The new CFG view is available at the same level as the existing "sea of nodes" (default) and "clustered sea-of-nodes" views. The view can be selected from the main toolbar:
>> 
>> ![toolbar](https://user-images.githubusercontent.com/8792647/158367502-ac8d8a29-5f35-4604-acc3-9d563c60e917.png)
>> 
>> The default view shown when opening a new graph can be configured in Tools -> Options -> Default View.
>> 
>> The same functionality available for the existing views also applies to the new CFG:
>> 
>> - node extraction:
>> 
>> ![node-extraction](https://user-images.githubusercontent.com/8792647/158371016-f7988eb6-368f-4805-ac7a-2b5611d16d7a.png)
>> 
>> - pop-up information on edges:
>> 
>> ![popup](https://user-images.githubusercontent.com/8792647/158367664-495189d5-384c-4b86-a62b-08863420c531.png)
>> 
>> - filtering:
>> 
>> ![filtering](https://user-images.githubusercontent.com/8792647/158367690-47b95bcd-7e8e-466e-b71b-f3e7d04c60ac.png)
>> 
>> - quick node and basic block search:
>> 
>> ![quick-search](https://user-images.githubusercontent.com/8792647/158367717-8bc90027-8ce7-4071-be04-1d67de6c91dd.png)
>> 
>> - and exporting.
>> 
>> The list of custom filters is extended with three new block-hiding filters:
>> 
>> - `Hide root block`: remove root block and hide all back-edges from exiting blocks that clutter the CFG.
>> 
>> - `Hide uncommon trap blocks`: remove blocks with uncommon traps to simplify following the "hot paths" in the CFG.
>> 
>> - `Hide exception blocks`: remove blocks that create and throw exceptions to also simplify following the "hot paths" in the CFG.
>> 
>> When using the CFG view, it is important to keep in mind that, in graphs corresponding to phases earlier than _Global code motion_, the presented CFG is just one of many possible projections of the sea-of-nodes representation, and that this projection is computed by an approximation of what C2 would do if it scheduled the graph at that stage. The approximation has some known limitations ([JDK-8280568](https://bugs.openjdk.java.net/browse/JDK-8280568), [JDK-8282053](https://bugs.openjdk.java.net/browse/JDK-8282053)). Future work should address these and warn the user when the approximated CFG is known to be inaccurate.
>> 
>> ### Testing
>> 
>> #### Functionality
>> 
>> - Tested the above functionality manually on a small selection of graphs.
>> 
>> - Tested automatically that scheduling (approximating C2's GCM and LCM algorithms) and viewing thousands of graphs in the three views does not trigger any assertion failure (by instrumenting IGV to schedule and view graphs as they are loaded and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).
>> 
>> #### Performance
>> 
>> - Measured the scheduling and view creation time for each of the three views on a selection of 22 large graphs (between 2515 and 7329 nodes). On average:
>> 
>> - The change introduces a slight overhead when creating the existing views (2% and 5% for the clustered and non-clustered sea-of-nodes views). This overhead is due to the introduction of abstractions and data structures required by the CFG view.
>> 
>> - The new CFG view is considerably faster to create than the existing ones (4.2x and 2.5x faster than the clustered and non-clustered sea-of-nodes views), as it can be expected, since only basic blocks have to be laid out. Furthermore, the CFG view scales better as the size of the graph increases.
>> 
>> - The change slows down scheduling by 27%. This overhead corresponds to the additional work of approximating C2's LCM, and it is essential for the CFG view. Fortunately, scheduling takes only a fraction of the time needed to create a view (typically no more than a third), and it only needs to run once for each graph, whereas views have to be re-created on node extraction, filtering, etc.
>> 
>> The performance results are [attached](https://github.com/openjdk/jdk/files/8252786/performance-evaluation.ods) (note that each measurement in the sheet corresponds to the median of ten runs).
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed last suggestion by Christian

This looks good to me. I am not a reviewer. I even don't think I understand IGV completely.
I just read the patch and also try it out.  I think this compact view of sea-of-node is really useful.

-------------

Marked as reviewed by xliu (Committer).

PR: https://git.openjdk.java.net/jdk/pull/7817

From iklam at openjdk.java.net  Mon Mar 28 03:44:43 2022
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 28 Mar 2022 03:44:43 GMT
Subject: RFR: 8283694: Improve bit manipulation and boolean to integer
 conversion operations on x86_64 [v4]
In-Reply-To: <_V7Q2URlUMlRsfPlLSx5v2gaYnuPyHrkcBAc50GDUPE=.42e7a4d5-d443-47ea-8fb3-dfc7d843af62@github.com>
References: <DoBINdgdk3jTGJbAbvWDdBDKXSqJujJQ6G9sPobENAI=.3f5ba9d3-f0c3-4786-ad16-2bfd05a3354a@github.com>
 <WknzXBIelgVDYWf2CTe_N3qIThE3vkJuVamVx8AuxVU=.67109ba6-955f-4087-bfdb-72cdd75cf47e@github.com>
 <_V7Q2URlUMlRsfPlLSx5v2gaYnuPyHrkcBAc50GDUPE=.42e7a4d5-d443-47ea-8fb3-dfc7d843af62@github.com>
Message-ID: <e2vCy90P2eWcjYUwv-thj9HLJjquRnr7_i2TAYG2Ghw=.28eb2dee-4e55-4d6b-a048-62d2c20c0df9@github.com>

On Sun, 27 Mar 2022 01:42:50 GMT, Quan Anh Mai <duke at openjdk.java.net> wrote:

> I have adjusted the title to be more specific and accurate. Thank you very much.

Thanks for fixing the title. I am not familiar with the code so I'll let others review it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7968

From fgao at openjdk.java.net  Mon Mar 28 06:13:42 2022
From: fgao at openjdk.java.net (Fei Gao)
Date: Mon, 28 Mar 2022 06:13:42 GMT
Subject: RFR: 8283091: Support type conversion between different data sizes
 in SLP [v3]
In-Reply-To: <nbsp68JympAQ3Dnrr8vCnMvCybc3hAhax96CnsOO0fc=.ccb20d24-a2b1-4f4d-8d42-5dbd861d1007@github.com>
References: <4qFrtxwRHZfnzJbdVl2z7l6XENvxR3N8Sruc2fraKkw=.1391f639-1514-4e50-899a-d56cdd4afa99@github.com>
 <nbsp68JympAQ3Dnrr8vCnMvCybc3hAhax96CnsOO0fc=.ccb20d24-a2b1-4f4d-8d42-5dbd861d1007@github.com>
Message-ID: <Da6i6dzsJXPFtCpFDz96V-vD4zJ9m9nFE0L8Dsstalc=.b25ea40b-2337-44d0-8300-32b35c1ceab3@github.com>

On Tue, 15 Mar 2022 08:09:27 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> After JDK-8275317, C2's SLP vectorizer has supported type conversion between the same data size. We can also support conversions between different data sizes like:
>> int <-> double
>> float <-> long
>> int <-> long
>> float <-> double
>> 
>> A typical test case:
>> 
>> int[] a;
>> double[] b;
>> for (int i = start; i < limit; i++) {
>>     b[i] = (double) a[i];
>> }
>> 
>> Our expected OptoAssembly code for one iteration is like below:
>> 
>> add R12, R2, R11, LShiftL #2
>> vector_load   V16,[R12, #16]
>> vectorcast_i2d  V16, V16  # convert I to D vector
>> add R11, R1, R11, LShiftL #3	# ptr
>> add R13, R11, #16	# ptr
>> vector_store [R13], V16
>> 
>> To enable the vectorization, the patch solves the following problems in the SLP.
>> 
>> There are three main operations in the case above, LoadI, ConvI2D and StoreD. Assuming that the vector length is 128 bits, how many scalar nodes should be packed together to a vector? If we decide it separately for each operation node, like what we did before the patch in SuperWord::combine_packs(), a 128-bit vector will support 4 LoadI or 2 ConvI2D or 2 StoreD nodes. However, if we put these packed nodes in a vector node sequence, like loading 4 elements to a vector, then typecasting 2 elements and lastly storing these 2 elements, they become invalid. As a result, we should look through the whole def-use chain
>> and then pick up the minimum of these element sizes, like function SuperWord::max_vector_size_in_ud_chain() do in the superword.cpp. In this case, we pack 2 LoadI, 2 ConvI2D and 2 StoreD nodes, and then generate valid vector node sequence, like loading 2 elements, converting the 2 elements to another type and storing the 2 elements with new type.
>> 
>> After this, LoadI nodes don't make full use of the whole vector and only occupy part of it. So we adapt the code in SuperWord::get_vw_bytes_special() to the situation.
>> 
>> In SLP, we calculate a kind of alignment as position trace for each scalar node in the whole vector. In this case, the alignments for 2 LoadI nodes are 0, 4 while the alignment for 2 ConvI2D nodes are 0, 8. Sometimes, 4 for LoadI and 8 for ConvI2D work the same, both of which mark that this node is the second node in the whole vector, while the difference between 4 and 8 are just because of their own data sizes. In this situation, we should try to remove the impact caused by different data size in SLP. For example, in the stage of SuperWord::extend_packlist(), while determining if it's potential to pack a pair of def nodes in the function SuperWord::follow_use_defs(), we remove the side effect of different data size by transforming the target alignment from the use node. Because we believe that, assuming that the vector length is 512 bits, if the ConvI2D use nodes have alignments of 16-24 and their def nodes, LoadI, have alignments of 8-12, these two LoadI nodes should be packed a
 s a pair as well.
>> 
>> Similarly, when determining if the vectorization is profitable, type conversion between different data size takes a type of one size and produces a type of another size, hence the special checks on alignment and size should be applied, like what we do in SuperWord::is_vector_use().
>> 
>> After solving these problems, we successfully implemented the vectorization of type conversion between different data sizes.
>> 
>> Here is the test data  (-XX:+UseSuperWord) on NEON:
>> 
>> Before the patch:
>> Benchmark   (length)  Mode  Cnt    Score   Error  Units
>> convertD2F       523  avgt   15  216.431 ? 0.131  ns/op
>> convertD2I       523  avgt   15  220.522 ? 0.311  ns/op
>> convertF2D       523  avgt   15  217.034 ? 0.292  ns/op
>> convertF2L       523  avgt   15  231.634 ? 1.881  ns/op
>> convertI2D       523  avgt   15  229.538 ? 0.095  ns/op
>> convertI2L       523  avgt   15  214.822 ? 0.131  ns/op
>> convertL2F       523  avgt   15  230.188 ? 0.217  ns/op
>> convertL2I       523  avgt   15  162.234 ? 0.235  ns/op
>> 
>> After the patch:
>> Benchmark   (length)  Mode  Cnt    Score    Error  Units
>> convertD2F       523  avgt   15  124.352 ?  1.079  ns/op
>> convertD2I       523  avgt   15  557.388 ?  8.166  ns/op
>> convertF2D       523  avgt   15  118.082 ?  4.026  ns/op
>> convertF2L       523  avgt   15  225.810 ? 11.180  ns/op
>> convertI2D       523  avgt   15  166.247 ?  0.120  ns/op
>> convertI2L       523  avgt   15  119.699 ?  2.925  ns/op
>> convertL2F       523  avgt   15  220.847 ?  0.053  ns/op
>> convertL2I       523  avgt   15  122.339 ?  2.738  ns/op
>> 
>> perf data on X86:
>> Before the patch:
>> Benchmark      (length)  Mode  Cnt    Score   Error  Units
>>   convertD2F       523  avgt   15  279.466 ? 0.069  ns/op
>>   convertD2I       523  avgt   15  551.009 ? 7.459  ns/op
>>   convertF2D       523  avgt   15  276.066 ? 0.117  ns/op
>>   convertF2L       523  avgt   15  545.108 ? 5.697  ns/op
>>   convertI2D       523  avgt   15  745.303 ? 0.185  ns/op
>>   convertI2L       523  avgt   15  260.878 ? 0.044  ns/op
>>   convertL2F       523  avgt   15  502.016 ? 0.172  ns/op
>>   convertL2I       523  avgt   15  261.654 ? 3.326  ns/op
>> 
>> After the patch:
>> Benchmark      (length)  Mode  Cnt    Score   Error  Units
>>   convertD2F       523  avgt   15  106.975 ? 0.045  ns/op
>>   convertD2I       523  avgt   15  546.866 ? 9.287  ns/op
>>   convertF2D       523  avgt   15   82.414 ? 0.340  ns/op
>>   convertF2L       523  avgt   15  542.235 ? 2.785  ns/op
>>   convertI2D       523  avgt   15   92.966 ? 1.400  ns/op
>>   convertI2L       523  avgt   15   79.960 ? 0.528  ns/op
>>   convertL2F       523  avgt   15  504.712 ? 4.794  ns/op
>>   convertL2I       523  avgt   15  129.753 ? 0.094  ns/op
>> 
>> perf data on AVX512:
>> Before the patch:
>> Benchmark      (length)  Mode  Cnt    Score   Error  Units
>>   convertD2F       523  avgt   15  282.984 ? 4.022  ns/op
>>   convertD2I       523  avgt   15  543.080 ? 3.873  ns/op
>>   convertF2D       523  avgt   15  273.950 ? 0.131  ns/op
>>   convertF2L       523  avgt   15  539.568 ? 2.747  ns/op
>>   convertI2D       523  avgt   15  745.238 ? 0.069  ns/op
>>   convertI2L       523  avgt   15  260.935 ? 0.169  ns/op
>>   convertL2F       523  avgt   15  501.870 ? 0.359  ns/op
>>   convertL2I       523  avgt   15  257.508 ? 0.174  ns/op
>> 
>> After the patch:
>> Benchmark  (length)  Mode  Cnt    Score   Error  Units
>>   convertD2F       523  avgt   15   76.687 ? 0.530  ns/op
>>   convertD2I       523  avgt   15  545.408 ? 4.657  ns/op
>>   convertF2D       523  avgt   15  273.935 ? 0.099  ns/op
>>   convertF2L       523  avgt   15  540.534 ? 3.032  ns/op
>>   convertI2D       523  avgt   15  745.234 ? 0.053  ns/op
>>   convertI2L       523  avgt   15  260.865 ? 0.104  ns/op
>>   convertL2F       523  avgt   15   63.834 ? 4.777  ns/op
>>   convertL2I       523  avgt   15   48.183 ? 0.990  ns/op
>
> Fei Gao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Add micro-benchmark cases
>    
>    Change-Id: I3c741255804ce410c8b6dcbdec974fa2c9051fd8
>  - Merge branch 'master' into fg8283091
>    
>    Change-Id: I674581135fd0844accc65520574fcef161eededa
>  - 8283091: Support type conversion between different data sizes in SLP
>    
>    After JDK-8275317, C2's SLP vectorizer has supported type conversion
>    between the same data size. We can also support conversions between
>    different data sizes like:
>    int <-> double
>    float <-> long
>    int <-> long
>    float <-> double
>    
>    A typical test case:
>    
>    int[] a;
>    double[] b;
>    for (int i = start; i < limit; i++) {
>        b[i] = (double) a[i];
>    }
>    
>    Our expected OptoAssembly code for one iteration is like below:
>    
>    add R12, R2, R11, LShiftL #2
>    vector_load   V16,[R12, #16]
>    vectorcast_i2d  V16, V16  # convert I to D vector
>    add R11, R1, R11, LShiftL #3	# ptr
>    add R13, R11, #16	# ptr
>    vector_store [R13], V16
>    
>    To enable the vectorization, the patch solves the following problems
>    in the SLP.
>    
>    There are three main operations in the case above, LoadI, ConvI2D and
>    StoreD. Assuming that the vector length is 128 bits, how many scalar
>    nodes should be packed together to a vector? If we decide it
>    separately for each operation node, like what we did before the patch
>    in SuperWord::combine_packs(), a 128-bit vector will support 4 LoadI
>    or 2 ConvI2D or 2 StoreD nodes. However, if we put these packed nodes
>    in a vector node sequence, like loading 4 elements to a vector, then
>    typecasting 2 elements and lastly storing these 2 elements, they become
>    invalid. As a result, we should look through the whole def-use chain
>    and then pick up the minimum of these element sizes, like function
>    SuperWord::max_vector_size_in_ud_chain() do in the superword.cpp.
>    In this case, we pack 2 LoadI, 2 ConvI2D and 2 StoreD nodes, and then
>    generate valid vector node sequence, like loading 2 elements,
>    converting the 2 elements to another type and storing the 2 elements
>    with new type.
>    
>    After this, LoadI nodes don't make full use of the whole vector and
>    only occupy part of it. So we adapt the code in
>    SuperWord::get_vw_bytes_special() to the situation.
>    
>    In SLP, we calculate a kind of alignment as position trace for each
>    scalar node in the whole vector. In this case, the alignments for 2
>    LoadI nodes are 0, 4 while the alignment for 2 ConvI2D nodes are 0, 8.
>    Sometimes, 4 for LoadI and 8 for ConvI2D work the same, both of which
>    mark that this node is the second node in the whole vector, while the
>    difference between 4 and 8 are just because of their own data sizes. In
>    this situation, we should try to remove the impact caused by different
>    data size in SLP. For example, in the stage of
>    SuperWord::extend_packlist(), while determining if it's potential to
>    pack a pair of def nodes in the function SuperWord::follow_use_defs(),
>    we remove the side effect of different data size by transforming the
>    target alignment from the use node. Because we believe that, assuming
>    that the vector length is 512 bits, if the ConvI2D use nodes have
>    alignments of 16-24 and their def nodes, LoadI, have alignments of 8-12,
>    these two LoadI nodes should be packed as a pair as well.
>    
>    Similarly, when determining if the vectorization is profitable, type
>    conversion between different data size takes a type of one size and
>    produces a type of another size, hence the special checks on alignment
>    and size should be applied, like what we do in SuperWord::is_vector_use.
>    
>    After solving these problems, we successfully implemented the
>    vectorization of type conversion between different data sizes.
>    
>    Here is the test data on NEON:
>    
>    Before the patch:
>    Benchmark              (length)  Mode  Cnt    Score   Error  Units
>      VectorLoop.convertD2F       523  avgt   15  216.431 ? 0.131  ns/op
>      VectorLoop.convertD2I       523  avgt   15  220.522 ? 0.311  ns/op
>      VectorLoop.convertF2D       523  avgt   15  217.034 ? 0.292  ns/op
>      VectorLoop.convertF2L       523  avgt   15  231.634 ? 1.881  ns/op
>      VectorLoop.convertI2D       523  avgt   15  229.538 ? 0.095  ns/op
>      VectorLoop.convertI2L       523  avgt   15  214.822 ? 0.131  ns/op
>      VectorLoop.convertL2F       523  avgt   15  230.188 ? 0.217  ns/op
>      VectorLoop.convertL2I       523  avgt   15  162.234 ? 0.235  ns/op
>    
>    After the patch:
>    Benchmark              (length)  Mode  Cnt    Score    Error  Units
>      VectorLoop.convertD2F       523  avgt   15  124.352 ?  1.079  ns/op
>      VectorLoop.convertD2I       523  avgt   15  557.388 ?  8.166  ns/op
>      VectorLoop.convertF2D       523  avgt   15  118.082 ?  4.026  ns/op
>      VectorLoop.convertF2L       523  avgt   15  225.810 ? 11.180  ns/op
>      VectorLoop.convertI2D       523  avgt   15  166.247 ?  0.120  ns/op
>      VectorLoop.convertI2L       523  avgt   15  119.699 ?  2.925  ns/op
>      VectorLoop.convertL2F       523  avgt   15  220.847 ?  0.053  ns/op
>      VectorLoop.convertL2I       523  avgt   15  122.339 ?  2.738  ns/op
>    
>    perf data on X86:
>    Before the patch:
>    Benchmark              (length)  Mode  Cnt    Score   Error  Units
>      VectorLoop.convertD2F       523  avgt   15  279.466 ? 0.069  ns/op
>      VectorLoop.convertD2I       523  avgt   15  551.009 ? 7.459  ns/op
>      VectorLoop.convertF2D       523  avgt   15  276.066 ? 0.117  ns/op
>      VectorLoop.convertF2L       523  avgt   15  545.108 ? 5.697  ns/op
>      VectorLoop.convertI2D       523  avgt   15  745.303 ? 0.185  ns/op
>      VectorLoop.convertI2L       523  avgt   15  260.878 ? 0.044  ns/op
>      VectorLoop.convertL2F       523  avgt   15  502.016 ? 0.172  ns/op
>      VectorLoop.convertL2I       523  avgt   15  261.654 ? 3.326  ns/op
>    
>    After the patch:
>    Benchmark              (length)  Mode  Cnt    Score   Error  Units
>      VectorLoop.convertD2F       523  avgt   15  106.975 ? 0.045  ns/op
>      VectorLoop.convertD2I       523  avgt   15  546.866 ? 9.287  ns/op
>      VectorLoop.convertF2D       523  avgt   15   82.414 ? 0.340  ns/op
>      VectorLoop.convertF2L       523  avgt   15  542.235 ? 2.785  ns/op
>      VectorLoop.convertI2D       523  avgt   15   92.966 ? 1.400  ns/op
>      VectorLoop.convertI2L       523  avgt   15   79.960 ? 0.528  ns/op
>      VectorLoop.convertL2F       523  avgt   15  504.712 ? 4.794  ns/op
>      VectorLoop.convertL2I       523  avgt   15  129.753 ? 0.094  ns/op
>    
>    perf data on AVX512:
>    Before the patch:
>    Benchmark              (length)  Mode  Cnt    Score   Error  Units
>      VectorLoop.convertD2F       523  avgt   15  282.984 ? 4.022  ns/op
>      VectorLoop.convertD2I       523  avgt   15  543.080 ? 3.873  ns/op
>      VectorLoop.convertF2D       523  avgt   15  273.950 ? 0.131  ns/op
>      VectorLoop.convertF2L       523  avgt   15  539.568 ? 2.747  ns/op
>      VectorLoop.convertI2D       523  avgt   15  745.238 ? 0.069  ns/op
>      VectorLoop.convertI2L       523  avgt   15  260.935 ? 0.169  ns/op
>      VectorLoop.convertL2F       523  avgt   15  501.870 ? 0.359  ns/op
>      VectorLoop.convertL2I       523  avgt   15  257.508 ? 0.174  ns/op
>    
>    After the patch:
>    Benchmark              (length)  Mode  Cnt    Score   Error  Units
>      VectorLoop.convertD2F       523  avgt   15   76.687 ? 0.530  ns/op
>      VectorLoop.convertD2I       523  avgt   15  545.408 ? 4.657  ns/op
>      VectorLoop.convertF2D       523  avgt   15  273.935 ? 0.099  ns/op
>      VectorLoop.convertF2L       523  avgt   15  540.534 ? 3.032  ns/op
>      VectorLoop.convertI2D       523  avgt   15  745.234 ? 0.053  ns/op
>      VectorLoop.convertI2L       523  avgt   15  260.865 ? 0.104  ns/op
>      VectorLoop.convertL2F       523  avgt   15   63.834 ? 4.777  ns/op
>      VectorLoop.convertL2I       523  avgt   15   48.183 ? 0.990  ns/op
>    
>    Change-Id: I93e60fd956547dad9204ceec90220145c58a72ef

The patch is to support type conversion between different data sizes like ConvL2F and ConvL2I. Anybody can help review it? Thanks :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/7806

From roland at openjdk.java.net  Mon Mar 28 07:29:20 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 28 Mar 2022 07:29:20 GMT
Subject: RFR: 8281429: PhiNode::Value() is too conservative for tripcount
 of CountedLoop [v4]
In-Reply-To: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
References: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
Message-ID: <_s5u6Mo55DSKvhPuAGSu0S64yFZH52q0quClp8NUoqw=.8fffa2d8-b92a-4f80-a600-656116abf542@github.com>

> The type for the iv phi of a counted loop is computed from the types
> of the phi on loop entry and the type of the limit from the exit
> test. Because the exit test is applied to the iv after increment, the
> type of the iv phi is at least one less than the limit (for a positive
> stride, one more for a negative stride).
> 
> Also, for a stride whose absolute value is not 1 and constant init and
> limit values, it's possible to compute accurately the iv phi type.
> 
> This change caused a few failures and I had to make a few adjustments
> to loop opts code as well.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - test fix
 - more test
 - test & fix
 - other fix
 - Merge branch 'master' into JDK-8281429
 - exp
 - review
 - Merge branch 'master' into JDK-8281429
 - Update src/hotspot/share/opto/cfgnode.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - Update src/hotspot/share/opto/cfgnode.cpp
   
   Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/98710e7d...3a087b2c

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7823/files
  - new: https://git.openjdk.java.net/jdk/pull/7823/files/ed91dd8e..3a087b2c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7823&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7823&range=02-03

  Stats: 823 lines in 41 files changed: 669 ins; 67 del; 87 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7823.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7823/head:pull/7823

PR: https://git.openjdk.java.net/jdk/pull/7823

From roland at openjdk.java.net  Mon Mar 28 07:35:58 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 28 Mar 2022 07:35:58 GMT
Subject: RFR: 8281429: PhiNode::Value() is too conservative for tripcount
 of CountedLoop [v3]
In-Reply-To: <YdS_vJ-n7bCZfYG0cVgSPgF-DrJ5GZSowPCjhzXTm2A=.08613d8a-6117-4844-a059-293c48ac9ff2@github.com>
References: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
 <yQBdmbDtfQ0j88ZmjXatbThlIaiCt_pdGEpf9zy7ajE=.fce1a178-9a6b-471a-b4f5-79eceadfbc51@github.com>
 <YdS_vJ-n7bCZfYG0cVgSPgF-DrJ5GZSowPCjhzXTm2A=.08613d8a-6117-4844-a059-293c48ac9ff2@github.com>
Message-ID: <NDEPhjud8vdtx-zSCq_aAAFfuN89ldOH49qTuiE_qKY=.05a81a2d-5f67-4e1e-9c0d-9bfb34f4e180@github.com>

On Wed, 23 Mar 2022 07:50:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Please add it as regression test.

Done in the updated change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7823

From roland at openjdk.java.net  Mon Mar 28 07:35:59 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 28 Mar 2022 07:35:59 GMT
Subject: RFR: 8281429: PhiNode::Value() is too conservative for tripcount
 of CountedLoop [v4]
In-Reply-To: <_1zw-Ms3Da8_EwtlmTdH7QesA1-BmzzvkXcxIC45UnE=.ab7ec74c-4d8b-47b6-a810-1a072e128226@github.com>
References: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
 <9sYg3nlxZcukMcDoqB1r52bqOqMvuqom8K-iqTflX9w=.dfc952bd-060c-4287-a666-6d0db41afdca@github.com>
 <_1zw-Ms3Da8_EwtlmTdH7QesA1-BmzzvkXcxIC45UnE=.ab7ec74c-4d8b-47b6-a810-1a072e128226@github.com>
Message-ID: <011G_jPgrZdEsMHI4Cx2_6aO1rNHatdpojKQ8PSCVfI=.49636109-52f8-4a78-b2b6-46cd7f491e6e@github.com>

On Tue, 22 Mar 2022 12:58:14 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> src/hotspot/share/opto/loopPredicate.cpp line 1069:
>> 
>>> 1067:                 inner_loop = inner_loop->_child;
>>> 1068:                 inner_head = inner_loop->_head->as_Loop();
>>> 1069:                 inner_head->verify_strip_mined(1);
>> 
>> Why did you remove the verification code?
>
> I hit a failure in that code for an inner loop that no longer has the shape of a counted loop. Let me double check if I can still reproduce it.

In the update I just pushed, I reverted that change, added a test that causes the failure that this was supposed to fix. The new fix is the new cast in in PhaseIdealLoop::do_unroll(). Without it, c2 can't remove the back branch of a main loop and the graph contains a counted loop that doesn't have the right shape anymore (the exit test doesn't depend on the iv phi after transformation but doesn't constant fold).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7823

From rbackman at openjdk.java.net  Mon Mar 28 07:36:47 2022
From: rbackman at openjdk.java.net (Rickard =?UTF-8?B?QsOkY2ttYW4=?=)
Date: Mon, 28 Mar 2022 07:36:47 GMT
Subject: Integrated: 8281222: ciTypeFlow::profiled_count fails
 "assert(0 <= i && i < _len) failed: illegal index"
In-Reply-To: <TsG0o1zrQRvR93tubXro8EBe2KOvuEmEHVsSci5iiek=.05c25bab-4a8e-4141-827c-5d9cde29cb06@github.com>
References: <TsG0o1zrQRvR93tubXro8EBe2KOvuEmEHVsSci5iiek=.05c25bab-4a8e-4141-827c-5d9cde29cb06@github.com>
Message-ID: <aSRlR9WZnJcr6-8nYexh-DJqYTdmmfnHjrILm_NXPwg=.7ec05624-666c-4271-9cbb-d920cd426725@github.com>

On Mon, 21 Mar 2022 14:45:40 GMT, Rickard B?ckman <rbackman at openjdk.org> wrote:

> This failed in Project Loom with a specific version of TestNG. 
> 
> The root cause is that the block that is considered tail doesn't have any _successors, but a couple of _exception "successors".

This pull request has now been integrated.

Changeset: 66f1da18
Author:    Rickard B?ckman <rbackman at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/66f1da188514dc111e417c7e8071f051a9c9cc9e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8281222: ciTypeFlow::profiled_count fails "assert(0 <= i && i < _len) failed: illegal index"

Reviewed-by: roland, chagedorn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7892

From jiefu at openjdk.java.net  Mon Mar 28 07:49:49 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 28 Mar 2022 07:49:49 GMT
Subject: RFR: 8282162: [vector] Optimize vector negation API [v2]
In-Reply-To: <NdmL_GlhtLXdoO7sDPA-5bcLzke6udfzqmOmIRq9jyI=.a8a5a012-d758-4836-86f0-38d852f49707@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
 <wcfhjAG9qX5jS9Sl70R59cGtCBbIT2W_nqompdTHaCU=.690af3d0-c3ab-4a5f-a264-df92f8022eeb@github.com>
 <NdmL_GlhtLXdoO7sDPA-5bcLzke6udfzqmOmIRq9jyI=.a8a5a012-d758-4836-86f0-38d852f49707@github.com>
Message-ID: <eZvivB2zu1dXBGZQnhvReNDYu6Ppnl_YNvSLtyb6Oms=.256342bc-1d28-4aab-a720-4c2efe842f64@github.com>

On Mon, 21 Mar 2022 01:19:57 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The compiler can get the real type info from `Op_NegVI` that can also handle the `BYTE ` and `SHORT ` basic type. I just don't want to add more new IRs which also need more match rules in the ad files.
> 
> > Is there any performance drop for byte/short negation operation if both of them are handled as a NegVI vector?
> 
> From the benchmark results I showed in the commit message, I didn't see not any performance drop for byte/short. Thanks!

There seems no vectorized negation instructions for {byte, short, int, long} on x86, so this should be fine on x86.
I tested the patch on x86 and the performance number looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From xgong at openjdk.java.net  Mon Mar 28 07:49:49 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 28 Mar 2022 07:49:49 GMT
Subject: RFR: 8282162: [vector] Optimize vector negation API [v2]
In-Reply-To: <eZvivB2zu1dXBGZQnhvReNDYu6Ppnl_YNvSLtyb6Oms=.256342bc-1d28-4aab-a720-4c2efe842f64@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
 <wcfhjAG9qX5jS9Sl70R59cGtCBbIT2W_nqompdTHaCU=.690af3d0-c3ab-4a5f-a264-df92f8022eeb@github.com>
 <NdmL_GlhtLXdoO7sDPA-5bcLzke6udfzqmOmIRq9jyI=.a8a5a012-d758-4836-86f0-38d852f49707@github.com>
 <eZvivB2zu1dXBGZQnhvReNDYu6Ppnl_YNvSLtyb6Oms=.256342bc-1d28-4aab-a720-4c2efe842f64@github.com>
Message-ID: <v0m8uR-kA3yXhR3qOSvPVTn9Pny0eT5mugMtiD4yGGA=.1c5747fe-ef5e-4ff9-ad3c-6cd95e740040@github.com>

On Mon, 28 Mar 2022 07:40:48 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> The compiler can get the real type info from `Op_NegVI` that can also handle the `BYTE ` and `SHORT ` basic type. I just don't want to add more new IRs which also need more match rules in the ad files.
>> 
>>> Is there any performance drop for byte/short negation operation if both of them are handled as a NegVI vector?
>> 
>> From the benchmark results I showed in the commit message, I didn't see not any performance drop for byte/short.  Thanks!
>
>> The compiler can get the real type info from `Op_NegVI` that can also handle the `BYTE ` and `SHORT ` basic type. I just don't want to add more new IRs which also need more match rules in the ad files.
>> 
>> > Is there any performance drop for byte/short negation operation if both of them are handled as a NegVI vector?
>> 
>> From the benchmark results I showed in the commit message, I didn't see not any performance drop for byte/short. Thanks!
> 
> There seems no vectorized negation instructions for {byte, short, int, long} on x86, so this should be fine on x86.
> I tested the patch on x86 and the performance number looks good.

Thanks for doing this! Yeah, I think the performance for masked negation operations might improve on non avx-512 systems.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From jiefu at openjdk.java.net  Mon Mar 28 07:49:50 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 28 Mar 2022 07:49:50 GMT
Subject: RFR: 8282162: [vector] Optimize vector negation API [v2]
In-Reply-To: <QnpIqj1hBZz6GNQxOr72g8PEMH4uKtAzNyR-9tCX1b4=.797224d5-c5a6-4732-9323-3b64aa4fa12f@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
 <QnpIqj1hBZz6GNQxOr72g8PEMH4uKtAzNyR-9tCX1b4=.797224d5-c5a6-4732-9323-3b64aa4fa12f@github.com>
Message-ID: <l-osKuZN6L16ZR0CL5KbSlyhjBvIpnbJjxTvO9ccpVw=.7864ef37-50b7-4551-92ce-accbb7a0e407@github.com>

On Tue, 22 Mar 2022 09:58:23 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE.
>> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern.
>> 
>> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture:
>>   - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation.
>>   - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`.
>> 
>> So with this patch, the following transformations are applied:
>> 
>> For non-masked negation with NEON:
>> 
>>   movi    v16.4s, #0x0
>>   sub v17.4s, v16.4s, v17.4s       ==> neg v17.4s, v17.4s
>> 
>> and with SVE:
>> 
>>   mov z16.s, #0
>>   sub z18.s, z16.s, z17.s          ==> neg z16.s, p7/m, z16.s
>> 
>> For masked negation with NEON:
>> 
>>   movi    v17.4s, #0x1
>>   mvn v19.16b, v18.16b
>>   mov v20.16b, v16.16b             ==>  neg v18.4s, v17.4s
>>   bsl v20.16b, v19.16b, v18.16b         bsl v19.16b, v18.16b, v17.16b
>>   add v19.4s, v20.4s, v17.4s
>>   mov v18.16b, v16.16b
>>   bsl v18.16b, v19.16b, v20.16b
>> 
>> and with SVE:
>> 
>>   mov z16.s, #-1
>>   mov z17.s, #1                    ==> neg z16.s, p0/m, z16.s
>>   eor z18.s, p0/m, z18.s, z16.s
>>   add z18.s, p0/m, z18.s, z17.s
>> 
>> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed):
>> 
>> NEON:
>> Benchmark                Gain
>> Byte128Vector.NEG        1.029
>> Byte128Vector.NEGMasked  1.757
>> Short128Vector.NEG       1.041
>> Short128Vector.NEGMasked 1.659
>> Int128Vector.NEG         1.005
>> Int128Vector.NEGMasked   1.513
>> Long128Vector.NEG        1.003
>> Long128Vector.NEGMasked  1.878
>> 
>> SVE with 512-bits:
>> Benchmark                Gain
>> ByteMaxVector.NEG        1.10
>> ByteMaxVector.NEGMasked  1.165
>> ShortMaxVector.NEG       1.056
>> ShortMaxVector.NEGMasked 1.195
>> IntMaxVector.NEG         1.002
>> IntMaxVector.NEGMasked   1.239
>> LongMaxVector.NEG        1.031
>> LongMaxVector.NEGMasked  1.191
>> 
>> X86 (non AVX-512):
>> Benchmark                Gain
>> ByteMaxVector.NEGMasked  1.254
>> ShortMaxVector.NEGMasked 1.359
>> IntMaxVector.NEGMasked   1.431
>> LongMaxVector.NEGMasked  1.989
>> 
>> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a superclass for vector negation

src/hotspot/share/opto/vectornode.cpp line 1592:

> 1590: 
> 1591: // Generate other vector nodes to implement the masked/non-masked vector negation.
> 1592: Node* VectorNode::degenerate_vector_integral_negate(Node* n, int vlen, BasicType bt, PhaseGVN* phase, bool is_predicated) {

Shall we move this declaration in `class  NegVNode` since it is only used by  NegVNode::Ideal ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From xgong at openjdk.java.net  Mon Mar 28 07:49:50 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 28 Mar 2022 07:49:50 GMT
Subject: RFR: 8282162: [vector] Optimize vector negation API [v2]
In-Reply-To: <l-osKuZN6L16ZR0CL5KbSlyhjBvIpnbJjxTvO9ccpVw=.7864ef37-50b7-4551-92ce-accbb7a0e407@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
 <QnpIqj1hBZz6GNQxOr72g8PEMH4uKtAzNyR-9tCX1b4=.797224d5-c5a6-4732-9323-3b64aa4fa12f@github.com>
 <l-osKuZN6L16ZR0CL5KbSlyhjBvIpnbJjxTvO9ccpVw=.7864ef37-50b7-4551-92ce-accbb7a0e407@github.com>
Message-ID: <TC_1FfVkbvPAA8p_NPyxRY7dbz7_6v5OrJsluBqiZ5I=.1821b725-48e6-44ac-94d3-351be3d816e4@github.com>

On Mon, 28 Mar 2022 07:43:29 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a superclass for vector negation
>
> src/hotspot/share/opto/vectornode.cpp line 1592:
> 
>> 1590: 
>> 1591: // Generate other vector nodes to implement the masked/non-masked vector negation.
>> 1592: Node* VectorNode::degenerate_vector_integral_negate(Node* n, int vlen, BasicType bt, PhaseGVN* phase, bool is_predicated) {
> 
> Shall we move this declaration in `class  NegVNode` since it is only used by  NegVNode::Ideal ?

I think it can be. Thanks for pointing out this. I will change this later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From jiefu at openjdk.java.net  Mon Mar 28 08:03:50 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 28 Mar 2022 08:03:50 GMT
Subject: RFR: 8282162: [vector] Optimize vector negation API
In-Reply-To: <UIbbi5W7BMv_b9IuzYdCQOCzSNfJuHEvOOuqqRyhHUE=.cc631985-5ef3-4d93-a6d6-c73db7903412@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
 <-E5E_NBci6gsGyOV5nWuTUNKLVnjiw2IiWjjgv2vFz0=.ebe7c447-ede9-4437-815c-a2004f9d6ce1@github.com>
 <UIbbi5W7BMv_b9IuzYdCQOCzSNfJuHEvOOuqqRyhHUE=.cc631985-5ef3-4d93-a6d6-c73db7903412@github.com>
Message-ID: <4Ecgum5Cb8oDUN02LIkOsU_3tYOLXASEq1znc3JhT28=.d69bc461-d84c-405a-9aad-945b04ca1a1e@github.com>

On Tue, 15 Mar 2022 02:47:20 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> > Note that in terms of Java semantics, negation of floating point values needs to be implemented as subtraction from negative zero rather than positive zero:
> > double negate(double arg) {return -0.0 - arg; }
> > This is to handle signed zeros correctly.
> 
> Hi @jddarcy ,thanks for looking at this PR and thanks for the notes on the floating point negation! Yeah, this really makes sense to me. Kindly note that this patch didn't touch the negation of the floating point values. For Vector API, the vector floating point negation has been intrinsified to `NegVF/D` node by compiler that we directly generate the negation instructions for them. Thanks!

I would suggest changing the JBS title like `[vector] Optimize non-floating vector negation API` .

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From rcastanedalo at openjdk.java.net  Mon Mar 28 09:28:44 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 28 Mar 2022 09:28:44 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v3]
In-Reply-To: <ryLuyZpNXUfQG5NjLlN6i8_xYmxGtbVOjWVqObNPGY8=.206bc9b8-43c5-4b51-a11f-54fc1a516d08@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <NQtRiYFx2_FiLpAUDa8qx96T27jFZt1yM0nk56rluno=.d9bc7262-4c90-4664-ba6b-88d5a1427f06@github.com>
 <ryLuyZpNXUfQG5NjLlN6i8_xYmxGtbVOjWVqObNPGY8=.206bc9b8-43c5-4b51-a11f-54fc1a516d08@github.com>
Message-ID: <U7W0gQXIZdlkS23ZZZ2fZFUkLM_It4eXkjdNexZwxIQ=.3b460398-f4bd-408a-a95a-51e14c38ad3a@github.com>

On Mon, 28 Mar 2022 03:36:16 GMT, Xin Liu <xliu at openjdk.org> wrote:

> This looks good to me. I am not a reviewer. I even don't think I understand IGV completely. I just read the patch and also try it out. I think this compact view of sea-of-node is really useful.

Thanks for having a look at the changes and trying out the new view, Xin, happy that you found it useful!

> src/utils/IdealGraphVisualizer/ServerCompiler/src/main/java/com/sun/hotspot/igv/servercompiler/ServerCompilerScheduler.java line 61:
> 
>> 59:             inputNode = n;
>> 60:             String p = n.getProperties().get("is_block_proj");
>> 61:             isBlockProjection = (p != null && p.equals("true"));
> 
> is it easy to flip equals here? 
> "true".equals(p) can avoid nullcheck.

Thanks for the tip! String comparisons are not a performance bottleneck in graph scheduling, and I find the current code more readable. But I will re-evaluate this suggestion after the main performance bottleneck in scheduling is removed in [JDK-8282043](https://bugs.openjdk.java.net/browse/JDK-8282043).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7817

From xgong at openjdk.java.net  Mon Mar 28 09:56:22 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Mon, 28 Mar 2022 09:56:22 GMT
Subject: RFR: 8282162: [vector] Optimize integral vector negation API [v3]
In-Reply-To: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
Message-ID: <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com>

> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE.
> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern.
> 
> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture:
>   - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation.
>   - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`.
> 
> So with this patch, the following transformations are applied:
> 
> For non-masked negation with NEON:
> 
>   movi    v16.4s, #0x0
>   sub v17.4s, v16.4s, v17.4s       ==> neg v17.4s, v17.4s
> 
> and with SVE:
> 
>   mov z16.s, #0
>   sub z18.s, z16.s, z17.s          ==> neg z16.s, p7/m, z16.s
> 
> For masked negation with NEON:
> 
>   movi    v17.4s, #0x1
>   mvn v19.16b, v18.16b
>   mov v20.16b, v16.16b             ==>  neg v18.4s, v17.4s
>   bsl v20.16b, v19.16b, v18.16b         bsl v19.16b, v18.16b, v17.16b
>   add v19.4s, v20.4s, v17.4s
>   mov v18.16b, v16.16b
>   bsl v18.16b, v19.16b, v20.16b
> 
> and with SVE:
> 
>   mov z16.s, #-1
>   mov z17.s, #1                    ==> neg z16.s, p0/m, z16.s
>   eor z18.s, p0/m, z18.s, z16.s
>   add z18.s, p0/m, z18.s, z17.s
> 
> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed):
> 
> NEON:
> Benchmark                Gain
> Byte128Vector.NEG        1.029
> Byte128Vector.NEGMasked  1.757
> Short128Vector.NEG       1.041
> Short128Vector.NEGMasked 1.659
> Int128Vector.NEG         1.005
> Int128Vector.NEGMasked   1.513
> Long128Vector.NEG        1.003
> Long128Vector.NEGMasked  1.878
> 
> SVE with 512-bits:
> Benchmark                Gain
> ByteMaxVector.NEG        1.10
> ByteMaxVector.NEGMasked  1.165
> ShortMaxVector.NEG       1.056
> ShortMaxVector.NEGMasked 1.195
> IntMaxVector.NEG         1.002
> IntMaxVector.NEGMasked   1.239
> LongMaxVector.NEG        1.031
> LongMaxVector.NEGMasked  1.191
> 
> X86 (non AVX-512):
> Benchmark                Gain
> ByteMaxVector.NEGMasked  1.254
> ShortMaxVector.NEGMasked 1.359
> IntMaxVector.NEGMasked   1.431
> LongMaxVector.NEGMasked  1.989
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896

Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:

  Make "degenerate_vector_integral_negate" to be "NegVI" private

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7782/files
  - new: https://git.openjdk.java.net/jdk/pull/7782/files/97c8119a..48f4d6be

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7782&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7782&range=01-02

  Stats: 15 lines in 2 files changed: 6 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7782.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7782/head:pull/7782

PR: https://git.openjdk.java.net/jdk/pull/7782

From rcastanedalo at openjdk.java.net  Mon Mar 28 10:40:05 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 28 Mar 2022 10:40:05 GMT
Subject: RFR: 8270090: C2: LCM may prioritize CheckCastPP nodes over
 projections
Message-ID: <eowMiJv7rO6UwLniuzQKJ12X5dbs3HjkD3mffNi8hro=.4193ef6e-30b7-4c03-ae48-928f88cca12b@github.com>

This change breaks the tie between top-priority nodes (CreateEx, projections, constants, and CheckCastPP) in LCM, when the node to be scheduled next is selected. The change assigns the highest priority to CreateEx (which must be scheduled at the beginning of its block, right after Phi and Parm nodes), followed by projections (which must be scheduled right after their parents), followed by constant and CheckCastPP nodes (which are given equal priority to preserve the current behavior), followed by the remaining lower-priority nodes.

The proposed prioritization prevents CheckCastPP from being incorrectly scheduled between a node and its projection. See the [bug description](https://bugs.openjdk.java.net/browse/JDK-8270090) for more details.

As a side-benefit, the proposed change removes the need of manipulating the ready list order for scheduling of CreateEx nodes correctly.

#### Testing

##### Functionality

- Original failure on linux-arm (see results [here](https://pici.beachhub.io/#/JDK-8270090/20220325-103958) and [here](https://pici.beachhub.io/#/JDK-8270090-jacoco/20220325-131740), thanks to Marc Hoffmann for setting up a test environment).
- hs-tier1-5 (windows-x64, linux-x64, linux-aarch64, and macosx-x64; release and debug mode).
- hs-tier1-3 (windows-x64, linux-x64, linux-aarch64, and macosx-x64; debug mode) with `-XX:+StressLCM` and `-XX:+StressGCM` (5 different seeds).

Note that the change does not include a regression test, since the failure only seems to be reproducible in ARM32 and I do not have access to this platform. If anyone wants to extract an ARM32 regression test out of the original failure, please let me know and I would be happy to add it to the change.

##### Performance

Tested performance on a set of standard benchmark suites (DaCapo, SPECjbb2015, SPECjvm2008, ...) and on windows-x64, linux-x64, linux-aarch64, and macosx-x64. No significant regression was observed.

-------------

Commit messages:
 - Remove temporary tracing code
 - Keep tie between constants and CheckCastPP nodes; document code
 - Break top-priority ties in local scheduling, add some temporary tracing code
 - Skip other checks when a block starter is found
 - Use priorities for block starter nodes
 - Ensure that projections are really selected first in local scheduling

Changes: https://git.openjdk.java.net/jdk/pull/7988/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7988&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8270090
  Stats: 37 lines in 1 file changed: 22 ins; 8 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7988.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7988/head:pull/7988

PR: https://git.openjdk.java.net/jdk/pull/7988

From duke at openjdk.java.net  Mon Mar 28 12:33:06 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Mon, 28 Mar 2022 12:33:06 GMT
Subject: RFR: 8283626: AArch64: Set relocInfo::offset_unit to 4
Message-ID: <7FGsw_mQVQ-BLGxv7WSSOh1OvyyL5X36X3lbLm_pMYM=.f9897ba8-0bf5-48fa-8d0a-bfb5030f4056@github.com>

AArch64 instructions size is 4 bytes. Two lowest bits of `relocInfo` offsets can be discarded.
Tested with release and fastdebug builds:
- `gtest`: Passed.
- `tier1`...`tier4`: Passed

-------------

Commit messages:
 - 8283626: AArch64: Set relocInfo::offset_unit to 4

Changes: https://git.openjdk.java.net/jdk/pull/7991/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7991&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283626
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7991.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7991/head:pull/7991

PR: https://git.openjdk.java.net/jdk/pull/7991

From shade at openjdk.java.net  Mon Mar 28 12:52:08 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 28 Mar 2022 12:52:08 GMT
Subject: RFR: 8283787: C1: Remove unused ArrayStoreExceptionStub::_info
Message-ID: <n8TuFg0xCQ7ODclXppRkIiUz7Rw3DUmOdDX4IEMAA5w=.0b3c7edf-9553-4d7a-a0a6-75d2b39338f1@github.com>

SonarCloud complains `ArrayStoreExceptionStub::_info` field is not initialized. It is not actually used, and the incoming `CodeEmitInfo*` gets passed to superclass instead.

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/7992/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7992&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283787
  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7992.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7992/head:pull/7992

PR: https://git.openjdk.java.net/jdk/pull/7992

From shade at openjdk.java.net  Mon Mar 28 13:09:04 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 28 Mar 2022 13:09:04 GMT
Subject: RFR: 8283789: CompilerPhaseTypeHelper::to_bitmask should operate on
 uint64_t
Message-ID: <Wg8QF4tB5ZV_zOg5nOG1NcPm05ME6DBZGXT-mWzFMgk=.89d42e05-22da-42a0-94d4-95d1f5b972d6@github.com>

[JDK-8281505](https://bugs.openjdk.java.net/browse/JDK-8281505) added this helper method that operates on `uint64_t` masks, but it operates on `int`s. So it is subtly broken on 32-bit platforms, for example. SonarCloud complains about it: "The result of the left shift is undefined due to shifting by '32', which is greater or equal to the width of type 'int'"

Additional testing:
 - [x] Linux x86_64 fastdebug, `compiler/oracle` passes
 - [x] Linux x86_32 fastdebug, `compiler/oracle` passes

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/7994/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7994&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283789
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7994.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7994/head:pull/7994

PR: https://git.openjdk.java.net/jdk/pull/7994

From aph at openjdk.java.net  Mon Mar 28 13:19:47 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 28 Mar 2022 13:19:47 GMT
Subject: RFR: 8283626: AArch64: Set relocInfo::offset_unit to 4
In-Reply-To: <7FGsw_mQVQ-BLGxv7WSSOh1OvyyL5X36X3lbLm_pMYM=.f9897ba8-0bf5-48fa-8d0a-bfb5030f4056@github.com>
References: <7FGsw_mQVQ-BLGxv7WSSOh1OvyyL5X36X3lbLm_pMYM=.f9897ba8-0bf5-48fa-8d0a-bfb5030f4056@github.com>
Message-ID: <8jkmu-GOW9c-fqQt7MqeYD6ls61dWf-Q4Mh9FG55ygA=.d28f18f9-5821-468a-8d41-8bfbc37ede69@github.com>

On Mon, 28 Mar 2022 12:26:17 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

> AArch64 instructions size is 4 bytes. Two lowest bits of `relocInfo` offsets can be discarded.
> Tested with release and fastdebug builds:
> - `gtest`: Passed.
> - `tier1`...`tier4`: Passed

Looks good. I remember this being suggested a long time ago, but we were close to release and I was worried something might break unexpectedly.

src/hotspot/cpu/aarch64/relocInfo_aarch64.hpp line 33:

> 31:   enum {
> 32:     // AArch64 instructions size is 4 bytes.
> 33:     // Two lowest offset bits can always be discarded.

Suggestion:

    // AArch64 instructions are always 4 bytes long and 4-aligned, so the
    // two lowest offset bits can always be discarded.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7991

From chagedorn at openjdk.java.net  Mon Mar 28 13:31:43 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 28 Mar 2022 13:31:43 GMT
Subject: RFR: 8283789: CompilerPhaseTypeHelper::to_bitmask should operate
 on uint64_t
In-Reply-To: <Wg8QF4tB5ZV_zOg5nOG1NcPm05ME6DBZGXT-mWzFMgk=.89d42e05-22da-42a0-94d4-95d1f5b972d6@github.com>
References: <Wg8QF4tB5ZV_zOg5nOG1NcPm05ME6DBZGXT-mWzFMgk=.89d42e05-22da-42a0-94d4-95d1f5b972d6@github.com>
Message-ID: <5TmV0MOxof1VGvPMMV-6QwxxRBJ3prywKtRo6VX_FIE=.ff50817f-3291-4c18-931c-bcf97a3237a2@github.com>

On Mon, 28 Mar 2022 13:02:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8281505](https://bugs.openjdk.java.net/browse/JDK-8281505) added this helper method that operates on `uint64_t` masks, but it operates on `int`s. So it is subtly broken on 32-bit platforms, for example. SonarCloud complains about it: "The result of the left shift is undefined due to shifting by '32', which is greater or equal to the width of type 'int'"
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `compiler/oracle` passes
>  - [x] Linux x86_32 fastdebug, `compiler/oracle` passes

Looks good and trivial.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7994

From chagedorn at openjdk.java.net  Mon Mar 28 13:34:40 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 28 Mar 2022 13:34:40 GMT
Subject: RFR: 8283692: Add PrintIdealPhase that includes block scheduling
In-Reply-To: <PshDgWdf8qtkdZQdJCMJK3Mo-5zxN5sbW59nEtcoEz4=.c1ffc2db-a1aa-4ae5-bcb3-d445d6a58e08@github.com>
References: <PshDgWdf8qtkdZQdJCMJK3Mo-5zxN5sbW59nEtcoEz4=.c1ffc2db-a1aa-4ae5-bcb3-d445d6a58e08@github.com>
Message-ID: <YQNJPtD-piSD3ueKi63iqkQCr3edRxS4FCYyIQcgor8=.19aba3b4-602f-491e-a158-d75328bb3d6b@github.com>

On Fri, 25 Mar 2022 14:47:44 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Hi,
> 
> This patch adds:
> 1) A new method Output::print_scheduling() that encapsulates the ir node printing on blocks
> 2) Modifying print_ideal_ir to use the print_scheduling() when there is a scheduling available
> 3) A new compiler phase MACH_ANALYSIS after the mach dependent optimizations.
> 
> Motivation:
> This is used by the IR-test framework when testing optimizations on mach-nodes, and is a requirement to be able to test peephole-optimizations (because peephole-removed nodes are only removed from the scheduling, not from the graph.)
> 
> Having a method for print_scheduling() is also very useful when debugging.
> 
> Please review,
> Nils Eliasson

Otherwise, looks good!

src/hotspot/share/opto/output.cpp line 328:

> 326:   pd_perform_mach_node_analysis();
> 327: 
> 328:   C->print_method(CompilerPhaseType::PHASE_MACHANALYSIS, 4);

I suggest to go with an underscore as mentioned in the PR description:
`PHASE_MACH_ANALYSIS`.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7960

From duke at openjdk.java.net  Mon Mar 28 13:44:15 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Mon, 28 Mar 2022 13:44:15 GMT
Subject: RFR: 8283626: AArch64: Set relocInfo::offset_unit to 4 [v2]
In-Reply-To: <7FGsw_mQVQ-BLGxv7WSSOh1OvyyL5X36X3lbLm_pMYM=.f9897ba8-0bf5-48fa-8d0a-bfb5030f4056@github.com>
References: <7FGsw_mQVQ-BLGxv7WSSOh1OvyyL5X36X3lbLm_pMYM=.f9897ba8-0bf5-48fa-8d0a-bfb5030f4056@github.com>
Message-ID: <iomVChGnqcWrY8BUNVCPouMTXfXaxiW8FfwvlXIKXig=.a7a193a8-81c6-4a20-aa6c-e4d1256e5298@github.com>

> AArch64 instructions size is 4 bytes. Two lowest bits of `relocInfo` offsets can be discarded.
> Tested with release and fastdebug builds:
> - `gtest`: Passed.
> - `tier1`...`tier4`: Passed

Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:

  Updated code comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7991/files
  - new: https://git.openjdk.java.net/jdk/pull/7991/files/1104f4e4..9b040c31

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7991&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7991&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7991.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7991/head:pull/7991

PR: https://git.openjdk.java.net/jdk/pull/7991

From simonis at openjdk.java.net  Mon Mar 28 13:44:16 2022
From: simonis at openjdk.java.net (Volker Simonis)
Date: Mon, 28 Mar 2022 13:44:16 GMT
Subject: RFR: 8283626: AArch64: Set relocInfo::offset_unit to 4 [v2]
In-Reply-To: <iomVChGnqcWrY8BUNVCPouMTXfXaxiW8FfwvlXIKXig=.a7a193a8-81c6-4a20-aa6c-e4d1256e5298@github.com>
References: <7FGsw_mQVQ-BLGxv7WSSOh1OvyyL5X36X3lbLm_pMYM=.f9897ba8-0bf5-48fa-8d0a-bfb5030f4056@github.com>
 <iomVChGnqcWrY8BUNVCPouMTXfXaxiW8FfwvlXIKXig=.a7a193a8-81c6-4a20-aa6c-e4d1256e5298@github.com>
Message-ID: <SScQow4ordDGwgW_AtBkjQf8Y8XbfJKl1rXwqlR9_Nc=.9d41a5fb-9807-4e9d-8ad2-3aaa9d26a1e0@github.com>

On Mon, 28 Mar 2022 13:40:14 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

>> AArch64 instructions size is 4 bytes. Two lowest bits of `relocInfo` offsets can be discarded.
>> Tested with release and fastdebug builds:
>> - `gtest`: Passed.
>> - `tier1`...`tier4`: Passed
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated code comments

Looks good to me.

This also fixes the issue that currently `OptoLoopAlignment` can be set to `1` although it should be a *multiple of NOP size* according to `OptoLoopAlignmentConstraintFunc()`.

-------------

Marked as reviewed by simonis (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7991

From duke at openjdk.java.net  Mon Mar 28 13:44:18 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Mon, 28 Mar 2022 13:44:18 GMT
Subject: RFR: 8283626: AArch64: Set relocInfo::offset_unit to 4 [v2]
In-Reply-To: <8jkmu-GOW9c-fqQt7MqeYD6ls61dWf-Q4Mh9FG55ygA=.d28f18f9-5821-468a-8d41-8bfbc37ede69@github.com>
References: <7FGsw_mQVQ-BLGxv7WSSOh1OvyyL5X36X3lbLm_pMYM=.f9897ba8-0bf5-48fa-8d0a-bfb5030f4056@github.com>
 <8jkmu-GOW9c-fqQt7MqeYD6ls61dWf-Q4Mh9FG55ygA=.d28f18f9-5821-468a-8d41-8bfbc37ede69@github.com>
Message-ID: <4yMOTuBpAwVjxJdd6I_kT__pR8mGQ5UFtEVbW-ZdWOE=.2ac91b29-fe3b-4bbb-b8be-e843ff8926b5@github.com>

On Mon, 28 Mar 2022 13:16:34 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated code comments
>
> src/hotspot/cpu/aarch64/relocInfo_aarch64.hpp line 33:
> 
>> 31:   enum {
>> 32:     // AArch64 instructions size is 4 bytes.
>> 33:     // Two lowest offset bits can always be discarded.
> 
> Suggestion:
> 
>     // AArch64 instructions are always 4 bytes long and 4-aligned, so the
>     // two lowest offset bits can always be discarded.

@theRealAph Thank you for reviewing and comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7991

From shade at openjdk.java.net  Mon Mar 28 14:05:42 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 28 Mar 2022 14:05:42 GMT
Subject: RFR: 8280003: C1: Reconsider uses of logical_and immediates in
 LIRGenerator::do_getObjectSize [v6]
In-Reply-To: <4wfmxqeneC0qL6x2cFaMVp-AWoQVbognQdKjV_nx4_U=.40d443e8-d900-472c-857d-841efabebc3d@github.com>
References: <4wfmxqeneC0qL6x2cFaMVp-AWoQVbognQdKjV_nx4_U=.40d443e8-d900-472c-857d-841efabebc3d@github.com>
Message-ID: <YAHxhH0E1Me0_EFSpoe-D0tjYaczsNDSCCTAOy-YvVE=.69f49357-e49d-47c0-b0ae-c32a36d608d6@github.com>

> See the discussion in the bug.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug `java/lang/instrument`
>  - [x] Linux x86_32 fastdebug `java/lang/instrument`
>  - [x] Linux AArch64 fastdebug `java/lang/instrument`
>  - [x] Linux ARM32 fastdebug `java/lang/instrument`
>  - [x] Linux PPC64 fastdebug `java/lang/instrument`
>  - [x] Linux x86_64 fastdebug `tier1`
>  - [x] Linux x86_32 fastdebug `tier1`
>  - [x] Linux AArch64 fastdebug `tier1`
>  - [x] Linux PPC64 fastdebug `tier1`

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:

 - Merge branch 'master' into JDK-8280003-c1-logical-and
 - Revert ARM32 checks
 - Merge branch 'master' into JDK-8280003-c1-logical-and
 - Fixing failures in ARM32
 - Merge branch 'master' into JDK-8280003-c1-logical-and
 - Checking ARM32 code
 - Use checked_cast<jint>
 - Merge branch 'master' into JDK-8280003-c1-logical-and
 - Fix

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7080/files
  - new: https://git.openjdk.java.net/jdk/pull/7080/files/784cff46..efc32767

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7080&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7080&range=04-05

  Stats: 210360 lines in 3058 files changed: 147466 ins; 50236 del; 12658 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7080.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7080/head:pull/7080

PR: https://git.openjdk.java.net/jdk/pull/7080

From thartmann at openjdk.java.net  Mon Mar 28 14:52:45 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 28 Mar 2022 14:52:45 GMT
Subject: RFR: 8283789: CompilerPhaseTypeHelper::to_bitmask should operate
 on uint64_t
In-Reply-To: <Wg8QF4tB5ZV_zOg5nOG1NcPm05ME6DBZGXT-mWzFMgk=.89d42e05-22da-42a0-94d4-95d1f5b972d6@github.com>
References: <Wg8QF4tB5ZV_zOg5nOG1NcPm05ME6DBZGXT-mWzFMgk=.89d42e05-22da-42a0-94d4-95d1f5b972d6@github.com>
Message-ID: <9V002PuSIwZVv3AUDtokLvbL3M0jrP6ux3ERBlaY1do=.fb0a2f82-d936-4ad8-a8fc-2447d3cc8e51@github.com>

On Mon, 28 Mar 2022 13:02:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8281505](https://bugs.openjdk.java.net/browse/JDK-8281505) added this helper method that operates on `uint64_t` masks, but it operates on `int`s. So it is subtly broken on 32-bit platforms, for example. SonarCloud complains about it: "The result of the left shift is undefined due to shifting by '32', which is greater or equal to the width of type 'int'"
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `compiler/oracle` passes
>  - [x] Linux x86_32 fastdebug, `compiler/oracle` passes

Marked as reviewed by thartmann (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7994

From thartmann at openjdk.java.net  Mon Mar 28 14:53:46 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Mon, 28 Mar 2022 14:53:46 GMT
Subject: RFR: 8283787: C1: Remove unused ArrayStoreExceptionStub::_info
In-Reply-To: <n8TuFg0xCQ7ODclXppRkIiUz7Rw3DUmOdDX4IEMAA5w=.0b3c7edf-9553-4d7a-a0a6-75d2b39338f1@github.com>
References: <n8TuFg0xCQ7ODclXppRkIiUz7Rw3DUmOdDX4IEMAA5w=.0b3c7edf-9553-4d7a-a0a6-75d2b39338f1@github.com>
Message-ID: <fHg6AHGx9V_jfzxMX8chhigkBDz15rtRh7nPZyq6Tfc=.a6d61479-b181-48f4-a983-05dc2d41e749@github.com>

On Mon, 28 Mar 2022 12:45:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains `ArrayStoreExceptionStub::_info` field is not initialized. It is not actually used, and the incoming `CodeEmitInfo*` gets passed to superclass instead.

Looks good and trivial.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7992

From chagedorn at openjdk.java.net  Mon Mar 28 15:10:47 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Mon, 28 Mar 2022 15:10:47 GMT
Subject: RFR: 8283787: C1: Remove unused ArrayStoreExceptionStub::_info
In-Reply-To: <n8TuFg0xCQ7ODclXppRkIiUz7Rw3DUmOdDX4IEMAA5w=.0b3c7edf-9553-4d7a-a0a6-75d2b39338f1@github.com>
References: <n8TuFg0xCQ7ODclXppRkIiUz7Rw3DUmOdDX4IEMAA5w=.0b3c7edf-9553-4d7a-a0a6-75d2b39338f1@github.com>
Message-ID: <Fo_CVmyApUBtbYqp5c3TG_E4wLG0ODUCy8uvRSj4u2Q=.9ce3e6c7-f3be-455b-b0c4-f0ff79c4f3d7@github.com>

On Mon, 28 Mar 2022 12:45:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains `ArrayStoreExceptionStub::_info` field is not initialized. It is not actually used, and the incoming `CodeEmitInfo*` gets passed to superclass instead.

Looks good.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7992

From eliu at openjdk.java.net  Mon Mar 28 16:47:08 2022
From: eliu at openjdk.java.net (Eric Liu)
Date: Mon, 28 Mar 2022 16:47:08 GMT
Subject: RFR: 8282875: AArch64: [vectorapi] Optimize Vector.reduceLane for SVE
 64/128 vector size
Message-ID: <6KkmSzP3na8JUnMFh3Yfzm6yuzk1EWr1LORhDLDPxRM=.c4bf6878-3964-4b9e-9225-f0fe3da1fc16@github.com>

This patch speeds up add/mul/min/max reductions for SVE for 64/128
vector size.

According to Neoverse N2/V1 software optimization guide[1][2], for
128-bit vector size reduction operations, we prefer using NEON
instructions instead of SVE instructions. This patch adds some rules to
distinguish 64/128 bits vector size with others, so that for these two
special cases, they can generate code the same as NEON. E.g., For
ByteVector.SPECIES_128, "ByteVector.reduceLanes(VectorOperators.ADD)"
generates code as below:


        Before:
        uaddv   d17, p0, z16.b
        smov    x15, v17.b[0]
        add     w15, w14, w15, sxtb

        After:
        addv    b17, v16.16b
        smov    x12, v17.b[0]
        add     w12, w12, w16, sxtb

No multiply reduction instruction in SVE, this patch generates code for
MulReductionVL by using scalar insnstructions for 128-bit vector size.

With this patch, all of them have performance gain for specific vector
micro benchmarks in my SVE testing system.

[1] https://developer.arm.com/documentation/pjdoc466751330-9685/latest/
[2] https://developer.arm.com/documentation/PJDOC-466751330-18256/0001

Change-Id: I4bef0b3eb6ad1bac582e4236aef19787ccbd9b1c

-------------

Commit messages:
 - 8282875: AArch64: [vectorapi] Optimize Vector.reduceLane for SVE 64/128 vector size

Changes: https://git.openjdk.java.net/jdk/pull/7999/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7999&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282875
  Stats: 1740 lines in 6 files changed: 770 ins; 671 del; 299 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7999.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7999/head:pull/7999

PR: https://git.openjdk.java.net/jdk/pull/7999

From aph at openjdk.java.net  Mon Mar 28 17:35:44 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 28 Mar 2022 17:35:44 GMT
Subject: RFR: 8283626: AArch64: Set relocInfo::offset_unit to 4 [v2]
In-Reply-To: <iomVChGnqcWrY8BUNVCPouMTXfXaxiW8FfwvlXIKXig=.a7a193a8-81c6-4a20-aa6c-e4d1256e5298@github.com>
References: <7FGsw_mQVQ-BLGxv7WSSOh1OvyyL5X36X3lbLm_pMYM=.f9897ba8-0bf5-48fa-8d0a-bfb5030f4056@github.com>
 <iomVChGnqcWrY8BUNVCPouMTXfXaxiW8FfwvlXIKXig=.a7a193a8-81c6-4a20-aa6c-e4d1256e5298@github.com>
Message-ID: <iiX43y9Wg_YXZzsLckl5DQ7AnO1CJ5VjeeaitzwauG0=.7fb716dd-4559-42fc-ba17-849a3170fddb@github.com>

On Mon, 28 Mar 2022 13:44:15 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

>> AArch64 instructions size is 4 bytes. Two lowest bits of `relocInfo` offsets can be discarded.
>> Tested with release and fastdebug builds:
>> - `gtest`: Passed.
>> - `tier1`...`tier4`: Passed
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated code comments

Marked as reviewed by aph (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7991

From aph at openjdk.java.net  Mon Mar 28 17:39:41 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 28 Mar 2022 17:39:41 GMT
Subject: RFR: 8282875: AArch64: [vectorapi] Optimize Vector.reduceLane for
 SVE 64/128 vector size
In-Reply-To: <6KkmSzP3na8JUnMFh3Yfzm6yuzk1EWr1LORhDLDPxRM=.c4bf6878-3964-4b9e-9225-f0fe3da1fc16@github.com>
References: <6KkmSzP3na8JUnMFh3Yfzm6yuzk1EWr1LORhDLDPxRM=.c4bf6878-3964-4b9e-9225-f0fe3da1fc16@github.com>
Message-ID: <HEIAfnyvOiwL-9LFv90k77iWT2q9HqNre5fYzWDBtUQ=.a816ab22-6937-4dbc-9756-fbb128a9ef75@github.com>

On Mon, 28 Mar 2022 16:39:08 GMT, Eric Liu <eliu at openjdk.org> wrote:

> This patch speeds up add/mul/min/max reductions for SVE for 64/128
> vector size.
> 
> According to Neoverse N2/V1 software optimization guide[1][2], for
> 128-bit vector size reduction operations, we prefer using NEON
> instructions instead of SVE instructions. This patch adds some rules to
> distinguish 64/128 bits vector size with others, so that for these two
> special cases, they can generate code the same as NEON. E.g., For
> ByteVector.SPECIES_128, "ByteVector.reduceLanes(VectorOperators.ADD)"
> generates code as below:
> 
> 
>         Before:
>         uaddv   d17, p0, z16.b
>         smov    x15, v17.b[0]
>         add     w15, w14, w15, sxtb
> 
>         After:
>         addv    b17, v16.16b
>         smov    x12, v17.b[0]
>         add     w12, w12, w16, sxtb
> 
> No multiply reduction instruction in SVE, this patch generates code for
> MulReductionVL by using scalar insnstructions for 128-bit vector size.
> 
> With this patch, all of them have performance gain for specific vector
> micro benchmarks in my SVE testing system.
> 
> [1] https://developer.arm.com/documentation/pjdoc466751330-9685/latest/
> [2] https://developer.arm.com/documentation/PJDOC-466751330-18256/0001
> 
> Change-Id: I4bef0b3eb6ad1bac582e4236aef19787ccbd9b1c

Out of curiosity, how do we propose to distinguish when we should use SVE? I guess as long as we only have Neoverse V1/N2 for SVE it makes sense to concentrate on that, but I guess we'll want a better optimization model sooner or later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7999

From vladimir.kozlov at oracle.com  Mon Mar 28 17:48:45 2022
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 28 Mar 2022 10:48:45 -0700
Subject: [External] : Re: RFC : Approach to handle Allocation Merges in C2
 Scalar Replacement
In-Reply-To: <BY5PR21MB1473482D25CF302438F83A289A129@BY5PR21MB1473.namprd21.prod.outlook.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
 <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
 <806f2baa-9b48-e57a-d153-0a19fc3e709d@oracle.com>
 <BY5PR21MB14735BCBF26C72B09051613E9A379@BY5PR21MB1473.namprd21.prod.outlook.com>
 <3cd5e4b1-5a0e-28ef-2445-1bf65fca4422@oracle.com>
 <BY5PR21MB147353D5267885877DFB47D79A3B9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <BY5PR21MB1473482D25CF302438F83A289A129@BY5PR21MB1473.namprd21.prod.outlook.com>
Message-ID: <cbe335c5-7fb5-ce01-d113-c098f9b6a6b6@oracle.com>

Hi Cesar

On 3/17/22 12:15 PM, Cesar Soares Lucas wrote:
> Hi all,
> 
> I?ve been experimenting with the idea explained by Vladimir Ivanov and I was able to implement it and have a few 
> non-trivial merges untangled and scalar replaced. However, I found an obstacle on the road. I was able to overcome it, 
> but I?d very much appreciate your opinion about the matter. Assume we start off with the piece of code below.
> 
> if (?) ????p0 = ?
> 
> else ??????p1 = ?
> 
> p = phi(p0, p1)
> 
> return p.x
> 
> The idea proposed suggests, AFAIU, that we change the code to be something like the below **where we use the bases 
> directly**.
> 
> if (?)?? p0 = ?
> 
> else ????p1 = ?
> 
> s = # selector phi #
> 
> if (s == id_base0)??? ???????x0 = p0.x
> 
> elseif (s == id_base1) ???x1 = p1.x
> 
> else ?????????????????????????????????halt()
> 
> x = phi(x0, x1)
> 
> return x
> 
> The problem here is that the definition of ?p0? and/or ?p1? doesn?t dominate their use in the loads ?x0 = p0.x? / ?x1 = 
> p1.x?, therefore certain IR verification steps in C2 fail. I was able to work around the issue by adding Phi nodes where 
> all inputs are the same (excluding the ctrl), thus creating a ?fake? definition for the value. Please see code below.

You have original `p = phi(p0, p1)` which is attached to Region node which merges paths with p0 and p1. `Selector ID 
Phi(id_p0, id_p1)` should be attached to the same Region and guarantee that p0 and p1 are defined at that point. The 
only issue could be is that load nodes don't have control edges and depend on memory edges to schedule. So they could 
float up. I think they should be attached (control edge) to id checks (s == id_base*) to prevent them move up as new 
special case [1]. At least as first approach for experiment.

Thanks,
Vladimir K

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/memnode.cpp#L1737

> 
> if (?)?? p0 = ?
> 
> else ????p1 = ?
> 
> phi0 = phi(p0, p0)
> 
> phi1 = Phi(p1, p1)
> 
> s = # selector phi #
> 
> if (s == id_base0)??? ???????x0 = phi0.x
> 
> elseif (s == id_base1) ???x1 = phi1.x
> 
> else ?????????????????????????????????halt()
> 
> x = phi(x0, x1)
> 
> return x
> 
> Transforming the code to look like the above silenced the verifications ( :-] ) and at the end EA+SR was able to remove 
> the allocations **and get rid of all the Phi?s**.
> 
> So, my question is: is this workaround acceptable? Do you have a suggestion of a better solution?
> 
> TIA, Cesar
> 
> *From: *hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.java.net> on behalf of Cesar Soares Lucas 
> <Divino.Cesar at microsoft.com>
> *Date: *Tuesday, February 22, 2022 at 10:01 AM
> *To: *Vladimir Ivanov <vladimir.x.ivanov at oracle.com>, Vladimir Kozlov <vladimir.kozlov at oracle.com>, hotspot compiler 
> <hotspot-compiler-dev at openjdk.java.net>
> *Cc: *Brian Stafford <Brian.Stafford at microsoft.com>, Martijn Verburg <Martijn.Verburg at microsoft.com>
> *Subject: *Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
> 
> Hi Vladimir,
> 
> I think I've enough feedback to start working on a prototype and see how things play out. Thank you for sharing your 
> ideas/expertise!
> 
> 
> Cheers,
> Cesar
> 
> ________________________________________
> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> Sent: February 21, 2022 10:26 AM
> To: Cesar Soares Lucas; Vladimir Kozlov; hotspot compiler
> Cc: Brian Stafford; Martijn Verburg
> Subject: Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
> 
> Hi Cesar,
> 
>> I with the selector-based base splitting idea using some examples and I think I understand the mechanics well. It's conceptually simple and quite effective, I like it! I've another question, though. From your previous message I had understood that we needed  the clustering because split_unique_types can't handle multiple bases at once, which makes sense to me. _This time I 
> don't understand why we need to do the clustering before doing the selector-based transformation_. AFAIU this 
> transformation won't be creating any memory slices but rather just assigning IDs to different bases and then creating 
> specialized memory operations conditionally using the different bases.
> 
> Yes, that's a valid simplification. It does sound like introducing
> selector ID doesn't require a separate memory graph (and can be
> performed before split_unique_types()), but I don't have a good
> understanding how complicated simplifying selector-based IR shapes would
> be compared to original (memory op-based) ones. It's definitely worth
> experimenting with.
> 
> Best regards,
> Vladimir Ivanov
> 
>> ________________________________________
>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>> Sent: February 17, 2022 7:37 AM
>> To: Vladimir Kozlov; Cesar Soares Lucas; hotspot compiler
>> Cc: Brian Stafford; Martijn Verburg
>> Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>
>>
>>> But depending on the actual shape of the base pointer (here it's
>>> Phi(obj1,obj2)), it may become infeasible (from performance perspective)
>>> or even impossible (e.g., for complex loop variant conditions) to
>>> separate instance slices.
>>
>> I'd like to correct myself. After thinking more about the problem, I see
>> a universal way to scalarize clusters of interfering non-escaping
>> allocations even in presence of accesses with indeterminate base.
>>
>> The crucial property for such cluster of interacting non-escaping
>> allocations is for any memory access its base is either part of the
>> cluster or not (it's a static property for every access). Then, when it
>> is part of the cluster, then the number of possible base values at
>> runtime is finite and is a subset of the cluster.
>>
>> So, memory graph for the cluster can be scalarized as follows:
>>
>>???? (1) separate memory graph for the cluster
>>
>>???? (2) on the newly constructed graph:
>>
>>??????? (a) replace every base pointer with an ID ("selector id") and
>> recreate data graph for selector IDs from base pointers graph;
>>
>>??????? (b) for accesses with indeterminate base pointer, replace them
>> with a merge of states from relevant allocations selected by "selector id"
>>
>>??????? (c) after 2b, all memory accesses from the cluster memory graph
>> should have fixed base pointing at a particular allocation
>>
>>???? (3) scalarize individual allocations from the cluster one by one
>> (since they are independent now)
>>
>>??????? - additional transformation (like, split-through-phi) should
>> simplify the graph by reducing the number of cases at merge points to
>> care about (ideally, leaving only a single one);
>>
>>
>>
>> As an illustration:
>>
>>???? val = Load (AddP (Phi R base1 base2) offset) mem # load A.i
>>
>> ==(pseudo-code)==>
>>
>>???? selector = (Phi R #base1 #base2)
>>
>>???? if (selector == #base1) {
>>?????? val1 = Load (base1 + offset) mem
>>???? } else if (selector == #base2) {
>>?????? val2 = Load (base2 + offset) mem
>>???? } else {
>>?????? halt(); // impossible
>>???? }
>>
>>???? val = Phi(R1, val1, val2)
>>
>> ======
>>
>>???? Store (AddP (Phi R base1 base2) offset) mem v # store A.i v
>>
>> ==(pseudo-code)==>
>>
>>???? selector = (Phi R #base1 #base2)
>>
>>???? if (selector == #base1) {
>>?????? Store base1 mem v ==> mem1
>>???? } else if (selector == #base2) {
>>?????? Store base2 mem v ==> mem2
>>???? } else {
>>?????? halt(); // impossible
>>???? }
>>
>>???? mem = Phi(R1, mem1, mem2);
>>
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>>
>>> So, gradual approach seems the way to go:
>>>???? (1) split memory graph for clusters of interacting non-escaping
>>> allocations;
>>>
>>>???? (2) perform adhoc transformation targeted at untangling aliasing
>>> accesses (e.g, split-through-phi);
>>>
>>>???? (3) extract unique instance types where possible, thus making the
>>> corresponding allocation scalar replaceable
>>>
>>> =====================================================================
>>>
>>> Also, one observation: interacting allocations don't have to be of the
>>> same class.
>>>
>>>?????? static int testPolluted(int r, boolean b) {
>>>?????????? A obj1 = new B1(r);
>>>?????????? A obj2 = new B2(r);
>>>
>>>?????????? A obj = (b ? obj1 : obj2);
>>>?????????? for (int i = 1; i < r; i++) {
>>>?????????????? obj.i++;
>>>?????????? }
>>>
>>>?????????? return obj1.i + obj2.i;
>>>?????? }
>>>
>>> Requiring unique instance types to perform SR (and not enhancing SR to
>>> handle aliasing allocations case) helps avoid some challenges in
>>> instance rematerialization logic at safepoints, because actual shape of
>>> the scalarized object (its class and exact set of fields) becomes a
>>> runtime property.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>>>>
>>>>>> Otherwise, I believe wide memory states/merges would pose serious
>>>>>> problems. E.g., when a load is split through a phi, you need to pick
>>>>>> correct memory states for the new loads above the phi which quickly
>>>>>> becomes quite a challenging task.
>>>>>
>>>>> Especially in loops. Actually I did tried such approach before and I
>>>>> agree that it is hard.
>>>>>
>>>>> Thanks,
>>>>> Vladimir K
>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Vladimir Ivanov
>>>>>>
>>>>>>>
>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>?????? p0 = Allocate(...);
>>>>>>>?????? ...
>>>>>>>?????? p0.x = first;
>>>>>>>?????? p0.y = second;
>>>>>>>
>>>>>>>?????? if (cond) {
>>>>>>>?????????? p1 = Allocate(...);
>>>>>>>?????????? ...
>>>>>>>?????????? p1.x = second;
>>>>>>>?????????? p1.y = first;
>>>>>>>?????? }
>>>>>>>
>>>>>>>?????? p = phi(p0, p1) // unused and will be removed
>>>>>>>
>>>>>>>
>>>>>>>?????? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>>>>> }
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir K
>>>>>>>
>>>>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>>>>> (BCCing hotspot-dev and moving the discussion to
>>>>>>>> hotspot-compiler-dev.)
>>>>>>>>
>>>>>>>> Hi Cesar,
>>>>>>>>
>>>>>>>> Thanks for looking into enhancing EA.
>>>>>>>>
>>>>>>>> Overall, the proposal looks reasonable.
>>>>>>>>
>>>>>>>> I suggest to look more closely at split_unique_types().
>>>>>>>> It introduces a dedicated class of alias categories for fields of
>>>>>>>> the allocation being eliminated and clones memory graph. I don't
>>>>>>>> see why it shouldn't work for multiple allocations.
>>>>>>>>
>>>>>>>> Moreover, split_unique_types() will break if you start optimizing
>>>>>>>> multiple allocations at once. The notion of unique alias should be
>>>>>>>> adjusted and cover the union of unique aliases for all interacting
>>>>>>>> allocations.
>>>>>>>>
>>>>>>>> Seems like you need to enhance SR to work on non-intersecting
>>>>>>>> clusters of allocations.
>>>>>>>>
>>>>>>>> One thing to take care of: scalar replacement relies on
>>>>>>>> TypeOopPtr::instance_id().
>>>>>>>>
>>>>>>>>???? // If not InstanceTop or InstanceBot, indicates that this is
>>>>>>>>???? // a particular instance of this type which is distinct.
>>>>>>>>???? // This is the node index of the allocation node creating this
>>>>>>>> instance.
>>>>>>>>???? int?????????? _instance_id;
>>>>>>>>
>>>>>>>> It'll break when multiple allocations are in play.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Vladimir Ivanov
>>>>>>>>
>>>>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>>>>> Hi there again!
>>>>>>>>>
>>>>>>>>> Can you please give me feedback on the following approach to at
>>>>>>>>> least partially
>>>>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>>>>
>>>>>>>>> The problem that I am trying to solve arises when allocations are
>>>>>>>>> merged after a
>>>>>>>>> control flow split. The code below shows _one example_ of such a
>>>>>>>>> situation.
>>>>>>>>>
>>>>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>>>>>?????? Point p = new Point(x, y);
>>>>>>>>>?????? if (cond)
>>>>>>>>>?????????? p = new Point(y, x);
>>>>>>>>>?????? // Allocations for p are merged here.
>>>>>>>>>?????? return p.calc();
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Assuming the method calls on "p" are inlined then the allocations
>>>>>>>>> will not
>>>>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>>>>
>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>?????? p0 = Allocate(...);
>>>>>>>>>?????? ...
>>>>>>>>>?????? p0.x = first;
>>>>>>>>>?????? p0.y = second;
>>>>>>>>>
>>>>>>>>>?????? if (cond) {
>>>>>>>>>?????????? p1 = Allocate(...);
>>>>>>>>>?????????? ...
>>>>>>>>>?????????? p1.x = second;
>>>>>>>>>?????????? p1.y = first;
>>>>>>>>>?????? }
>>>>>>>>>
>>>>>>>>>?????? p = phi(p0, p1)
>>>>>>>>>
>>>>>>>>>?????? return p.x - p.y;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> However, one of the constraints implemented here [2],
>>>>>>>>> specifically the third
>>>>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>>>>
>>>>>>>>> The approach that I'm considering for solving the problem is to
>>>>>>>>> replace the Phi
>>>>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields
>>>>>>>>> of the objects
>>>>>>>>> in the original Phi. The IR for `ex1` would look something like
>>>>>>>>> this after the
>>>>>>>>> transformation:
>>>>>>>>>
>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>?????? p0 = Allocate(...);
>>>>>>>>>?????? ...
>>>>>>>>>?????? p0.x = first;
>>>>>>>>>?????? p0.y = second;
>>>>>>>>>
>>>>>>>>>?????? if (cond) {
>>>>>>>>>?????????? p1 = Allocate(...);
>>>>>>>>>?????????? ...
>>>>>>>>>?????????? p1.x = second;
>>>>>>>>>?????????? p1.y = first;
>>>>>>>>>?????? }
>>>>>>>>>
>>>>>>>>>?????? pX = phi(first, second)
>>>>>>>>>?????? pY = phi(second, first)
>>>>>>>>>
>>>>>>>>>?????? return pX - pY;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> I understand that this transformation might not be applicable for
>>>>>>>>> all cases and
>>>>>>>>> that it's not as simple as illustrated above. Also, it seems to
>>>>>>>>> me that much of
>>>>>>>>> what I'd have to implement is already implemented in other steps
>>>>>>>>> of the Scalar
>>>>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>>>>> implementation details I plan to use as much of the existing code
>>>>>>>>> as possible.
>>>>>>>>> The algorithm for the transformation would be like this:
>>>>>>>>>
>>>>>>>>> split_phis(phi)
>>>>>>>>>?????? # If output of phi escapes, or something uses its identity, etc
>>>>>>>>>?????? # then we can't remove it. The conditions here might
>>>>>>>>> possible be the
>>>>>>>>>?????? # same as the ones implemented in
>>>>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>>>>>?????? if cant_remove_phi_output(phi)
>>>>>>>>>?????????? return ;
>>>>>>>>>
>>>>>>>>>?????? # Collect a set of tuples(F,U) containing nodes U that uses
>>>>>>>>> field F
>>>>>>>>>?????? # member of the object resulting from `phi`.
>>>>>>>>>?????? fields_used = collect_fields_used_after_phi(phi)
>>>>>>>>>
>>>>>>>>>?????? foreach field in fields_used
>>>>>>>>>?????????? producers = {}
>>>>>>>>>
>>>>>>>>>?????????? # Create a list with the last Store for each field
>>>>>>>>> "field" on the
>>>>>>>>>?????????? # scope of each of the Phi input objects.
>>>>>>>>>?????????? foreach o in phi.inputs
>>>>>>>>>?????????????? # The function called below might re-use a lot of
>>>>>>>>> the code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>>>>>?????????????? producers += last_store_to_o_field(0, field)
>>>>>>>>>?????????? # Create a new phi node whose inputs are the Store's to
>>>>>>>>> 'field'
>>>>>>>>>?????????? field_phi = create_new_phi(producers)
>>>>>>>>>
>>>>>>>>>?????????? update_consumers(field, field_phi)
>>>>>>>>>
>>>>>>>>> The implementation that I envisioned would be as a "pre-process"
>>>>>>>>> [3] step just
>>>>>>>>> after EA but before the constraint checks in
>>>>>>>>> `adjust_scalar_replaceable_state`
>>>>>>>>> [2]. If we agree that the overall Scalar Replacement
>>>>>>>>> implementation goes through
>>>>>>>>> the following major phases:
>>>>>>>>>
>>>>>>>>>?????? 1. Identify the Escape Status of objects.
>>>>>>>>>?????? 2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>>> based on a set of constraints.
>>>>>>>>>?????? 3. Make call to Split_unique_types [4].
>>>>>>>>>?????? 4 Iterate over object and array allocations.
>>>>>>>>>?????????? 4.1 Check if allocation can be eliminated.
>>>>>>>>>?????????? 4.2 Perform scalar replacement. Replace uses of object
>>>>>>>>> in Safepoints.
>>>>>>>>>?????????? 4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>>
>>>>>>>>> The transformation that I am proposing would change the overall
>>>>>>>>> flow to look
>>>>>>>>> like this:
>>>>>>>>>
>>>>>>>>>?????? 1. Identify the Escape Status of objects.
>>>>>>>>>?????? 2. ----> New: "Split phi functions" <----
>>>>>>>>>?????? 2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>>> based on a set of constraints.
>>>>>>>>>?????? 3. Make call to Split_unique_types [14].
>>>>>>>>>?????? 4 Iterate over object and array allocations.
>>>>>>>>>?????????? 4.1 ----> Moved to split_phi: "Check if allocation can
>>>>>>>>> be eliminated" <----
>>>>>>>>>?????????? 4.2 Perform scalar replacement. Replace uses of object
>>>>>>>>> in Safepoints.
>>>>>>>>>?????????? 4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>>
>>>>>>>>> Please let me know what you think and thank you for taking the
>>>>>>>>> time to review
>>>>>>>>> this!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Cesar
>>>>>>>>>
>>>>>>>>> Notes:
>>>>>>>>>
>>>>>>>>>?????? [1] I am not sure yet how this approach will play with the
>>>>>>>>> case of a merge
>>>>>>>>>?????????? with NULL.
>>>>>>>>>?????? [2]
>>>>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809%26amp%3Bdata%3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc%24&amp;data=04%7C01%7Cdivino.cesar%40microsoft.com%7C8c1737b992e847651e8d08d9f62d649b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637811497098895122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=8hLm9BcYVRF810gFqf2%2B%2Fd28jzqU2k7htD%2FDLqR9vAM%3D&amp;reserved=0 
> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24&amp;data=04*7C01*7Cdivino.cesar*40microsoft.com*7C8c1737b992e847651e8d08d9f62d649b*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637811497098895122*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=8hLm9BcYVRF810gFqf2*2B*2Fd28jzqU2k7htD*2FDLqR9vAM*3D&amp;reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!c3mFGaPH2PWpbeiHR44WrjfJKF0Ymg6aPQ8EOEMK0t5iYjdL4XwgsEvifrlDVrer2pCrdQ$>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>?????? [3] Another option would be to "patch" the current
>>>>>>>>> implementation to be able
>>>>>>>>>?????????? to handle the merges. I am not certain that the "patch"
>>>>>>>>> approach would be
>>>>>>>>>?????????? better, however, the "pre-process" approach is certainly
>>>>>>>>> much easier to test
>>>>>>>>>?????????? and more readable.
>>>>>>>>>
>>>>>>>>>?????? [4] I cannot say I understand 100% the effects of executing
>>>>>>>>>?????????? split_unique_types(). Would the transformation that I am
>>>>>>>>> proposing need to
>>>>>>>>>?????????? be after the call to split_unique_types?
> 

From vladimir.kozlov at oracle.com  Mon Mar 28 18:08:33 2022
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 28 Mar 2022 11:08:33 -0700
Subject: [External] : Re: RFC : Approach to handle Allocation Merges in C2
 Scalar Replacement
In-Reply-To: <cbe335c5-7fb5-ce01-d113-c098f9b6a6b6@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
 <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
 <806f2baa-9b48-e57a-d153-0a19fc3e709d@oracle.com>
 <BY5PR21MB14735BCBF26C72B09051613E9A379@BY5PR21MB1473.namprd21.prod.outlook.com>
 <3cd5e4b1-5a0e-28ef-2445-1bf65fca4422@oracle.com>
 <BY5PR21MB147353D5267885877DFB47D79A3B9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <BY5PR21MB1473482D25CF302438F83A289A129@BY5PR21MB1473.namprd21.prod.outlook.com>
 <cbe335c5-7fb5-ce01-d113-c098f9b6a6b6@oracle.com>
Message-ID: <c0906d57-5bce-2ee5-c6bd-4b93a677edad@oracle.com>

On 3/28/22 10:48 AM, Vladimir Kozlov wrote:
> Hi Cesar
> 
> On 3/17/22 12:15 PM, Cesar Soares Lucas wrote:
>> Hi all,
>>
>> I?ve been experimenting with the idea explained by Vladimir Ivanov and I was able to implement it and have a few 
>> non-trivial merges untangled and scalar replaced. However, I found an obstacle on the road. I was able to overcome it, 
>> but I?d very much appreciate your opinion about the matter. Assume we start off with the piece of code below.
>>
>> if (?) ????p0 = ?
>>
>> else ??????p1 = ?
>>
>> p = phi(p0, p1)
>>
>> return p.x
>>
>> The idea proposed suggests, AFAIU, that we change the code to be something like the below **where we use the bases 
>> directly**.
>>
>> if (?)?? p0 = ?
>>
>> else ????p1 = ?
>>
>> s = # selector phi #
>>
>> if (s == id_base0)??? ???????x0 = p0.x
>>
>> elseif (s == id_base1) ???x1 = p1.x
>>
>> else ?????????????????????????????????halt()
>>
>> x = phi(x0, x1)
>>
>> return x
>>
>> The problem here is that the definition of ?p0? and/or ?p1? doesn?t dominate their use in the loads ?x0 = p0.x? / ?x1 
>> = p1.x?, therefore certain IR verification steps in C2 fail. I was able to work around the issue by adding Phi nodes 
>> where all inputs are the same (excluding the ctrl), thus creating a ?fake? definition for the value. Please see code 
>> below.
> 
> You have original `p = phi(p0, p1)` which is attached to Region node which merges paths with p0 and p1. `Selector ID 
> Phi(id_p0, id_p1)` should be attached to the same Region and guarantee that p0 and p1 are defined at that point. The 
> only issue could be is that load nodes don't have control edges and depend on memory edges to schedule. So they could 
> float up. I think they should be attached (control edge) to id checks (s == id_base*) to prevent them move up as new 
> special case [1]. At least as first approach for experiment.

On other hand there should be a `mem` edge which original `p.x` load node has. May be use it for new load nodes which 
replace it. Then you don't need to set control.

Vladimir K

> 
> Thanks,
> Vladimir K
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/memnode.cpp#L1737
> 
>>
>> if (?)?? p0 = ?
>>
>> else ????p1 = ?
>>
>> phi0 = phi(p0, p0)
>>
>> phi1 = Phi(p1, p1)
>>
>> s = # selector phi #
>>
>> if (s == id_base0)??? ???????x0 = phi0.x
>>
>> elseif (s == id_base1) ???x1 = phi1.x
>>
>> else ?????????????????????????????????halt()
>>
>> x = phi(x0, x1)
>>
>> return x
>>
>> Transforming the code to look like the above silenced the verifications ( :-] ) and at the end EA+SR was able to 
>> remove the allocations **and get rid of all the Phi?s**.
>>
>> So, my question is: is this workaround acceptable? Do you have a suggestion of a better solution?
>>
>> TIA, Cesar
>>
>> *From: *hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.java.net> on behalf of Cesar Soares Lucas 
>> <Divino.Cesar at microsoft.com>
>> *Date: *Tuesday, February 22, 2022 at 10:01 AM
>> *To: *Vladimir Ivanov <vladimir.x.ivanov at oracle.com>, Vladimir Kozlov <vladimir.kozlov at oracle.com>, hotspot compiler 
>> <hotspot-compiler-dev at openjdk.java.net>
>> *Cc: *Brian Stafford <Brian.Stafford at microsoft.com>, Martijn Verburg <Martijn.Verburg at microsoft.com>
>> *Subject: *Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>
>> Hi Vladimir,
>>
>> I think I've enough feedback to start working on a prototype and see how things play out. Thank you for sharing your 
>> ideas/expertise!
>>
>>
>> Cheers,
>> Cesar
>>
>> ________________________________________
>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>> Sent: February 21, 2022 10:26 AM
>> To: Cesar Soares Lucas; Vladimir Kozlov; hotspot compiler
>> Cc: Brian Stafford; Martijn Verburg
>> Subject: Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>
>> Hi Cesar,
>>
>>> I with the selector-based base splitting idea using some examples and I think I understand the mechanics well. It's 
>>> conceptually simple and quite effective, I like it! I've another question, though. From your previous message I had 
>>> understood that we needed? the clustering because split_unique_types can't handle multiple bases at once, which makes 
>>> sense to me. _This time I 
>> don't understand why we need to do the clustering before doing the selector-based transformation_. AFAIU this 
>> transformation won't be creating any memory slices but rather just assigning IDs to different bases and then creating 
>> specialized memory operations conditionally using the different bases.
>>
>> Yes, that's a valid simplification. It does sound like introducing
>> selector ID doesn't require a separate memory graph (and can be
>> performed before split_unique_types()), but I don't have a good
>> understanding how complicated simplifying selector-based IR shapes would
>> be compared to original (memory op-based) ones. It's definitely worth
>> experimenting with.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>> ________________________________________
>>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>>> Sent: February 17, 2022 7:37 AM
>>> To: Vladimir Kozlov; Cesar Soares Lucas; hotspot compiler
>>> Cc: Brian Stafford; Martijn Verburg
>>> Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>
>>>
>>>> But depending on the actual shape of the base pointer (here it's
>>>> Phi(obj1,obj2)), it may become infeasible (from performance perspective)
>>>> or even impossible (e.g., for complex loop variant conditions) to
>>>> separate instance slices.
>>>
>>> I'd like to correct myself. After thinking more about the problem, I see
>>> a universal way to scalarize clusters of interfering non-escaping
>>> allocations even in presence of accesses with indeterminate base.
>>>
>>> The crucial property for such cluster of interacting non-escaping
>>> allocations is for any memory access its base is either part of the
>>> cluster or not (it's a static property for every access). Then, when it
>>> is part of the cluster, then the number of possible base values at
>>> runtime is finite and is a subset of the cluster.
>>>
>>> So, memory graph for the cluster can be scalarized as follows:
>>>
>>> ???? (1) separate memory graph for the cluster
>>>
>>> ???? (2) on the newly constructed graph:
>>>
>>> ??????? (a) replace every base pointer with an ID ("selector id") and
>>> recreate data graph for selector IDs from base pointers graph;
>>>
>>> ??????? (b) for accesses with indeterminate base pointer, replace them
>>> with a merge of states from relevant allocations selected by "selector id"
>>>
>>> ??????? (c) after 2b, all memory accesses from the cluster memory graph
>>> should have fixed base pointing at a particular allocation
>>>
>>> ???? (3) scalarize individual allocations from the cluster one by one
>>> (since they are independent now)
>>>
>>> ??????? - additional transformation (like, split-through-phi) should
>>> simplify the graph by reducing the number of cases at merge points to
>>> care about (ideally, leaving only a single one);
>>>
>>>
>>>
>>> As an illustration:
>>>
>>> ???? val = Load (AddP (Phi R base1 base2) offset) mem # load A.i
>>>
>>> ==(pseudo-code)==>
>>>
>>> ???? selector = (Phi R #base1 #base2)
>>>
>>> ???? if (selector == #base1) {
>>> ?????? val1 = Load (base1 + offset) mem
>>> ???? } else if (selector == #base2) {
>>> ?????? val2 = Load (base2 + offset) mem
>>> ???? } else {
>>> ?????? halt(); // impossible
>>> ???? }
>>>
>>> ???? val = Phi(R1, val1, val2)
>>>
>>> ======
>>>
>>> ???? Store (AddP (Phi R base1 base2) offset) mem v # store A.i v
>>>
>>> ==(pseudo-code)==>
>>>
>>> ???? selector = (Phi R #base1 #base2)
>>>
>>> ???? if (selector == #base1) {
>>> ?????? Store base1 mem v ==> mem1
>>> ???? } else if (selector == #base2) {
>>> ?????? Store base2 mem v ==> mem2
>>> ???? } else {
>>> ?????? halt(); // impossible
>>> ???? }
>>>
>>> ???? mem = Phi(R1, mem1, mem2);
>>>
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>>
>>>> So, gradual approach seems the way to go:
>>>> ???? (1) split memory graph for clusters of interacting non-escaping
>>>> allocations;
>>>>
>>>> ???? (2) perform adhoc transformation targeted at untangling aliasing
>>>> accesses (e.g, split-through-phi);
>>>>
>>>> ???? (3) extract unique instance types where possible, thus making the
>>>> corresponding allocation scalar replaceable
>>>>
>>>> =====================================================================
>>>>
>>>> Also, one observation: interacting allocations don't have to be of the
>>>> same class.
>>>>
>>>> ?????? static int testPolluted(int r, boolean b) {
>>>> ?????????? A obj1 = new B1(r);
>>>> ?????????? A obj2 = new B2(r);
>>>>
>>>> ?????????? A obj = (b ? obj1 : obj2);
>>>> ?????????? for (int i = 1; i < r; i++) {
>>>> ?????????????? obj.i++;
>>>> ?????????? }
>>>>
>>>> ?????????? return obj1.i + obj2.i;
>>>> ?????? }
>>>>
>>>> Requiring unique instance types to perform SR (and not enhancing SR to
>>>> handle aliasing allocations case) helps avoid some challenges in
>>>> instance rematerialization logic at safepoints, because actual shape of
>>>> the scalarized object (its class and exact set of fields) becomes a
>>>> runtime property.
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>>>>>
>>>>>>> Otherwise, I believe wide memory states/merges would pose serious
>>>>>>> problems. E.g., when a load is split through a phi, you need to pick
>>>>>>> correct memory states for the new loads above the phi which quickly
>>>>>>> becomes quite a challenging task.
>>>>>>
>>>>>> Especially in loops. Actually I did tried such approach before and I
>>>>>> agree that it is hard.
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir K
>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Vladimir Ivanov
>>>>>>>
>>>>>>>>
>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>> ?????? p0 = Allocate(...);
>>>>>>>> ?????? ...
>>>>>>>> ?????? p0.x = first;
>>>>>>>> ?????? p0.y = second;
>>>>>>>>
>>>>>>>> ?????? if (cond) {
>>>>>>>> ?????????? p1 = Allocate(...);
>>>>>>>> ?????????? ...
>>>>>>>> ?????????? p1.x = second;
>>>>>>>> ?????????? p1.y = first;
>>>>>>>> ?????? }
>>>>>>>>
>>>>>>>> ?????? p = phi(p0, p1) // unused and will be removed
>>>>>>>>
>>>>>>>>
>>>>>>>> ?????? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>>>>>> }
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Vladimir K
>>>>>>>>
>>>>>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>>>>>> (BCCing hotspot-dev and moving the discussion to
>>>>>>>>> hotspot-compiler-dev.)
>>>>>>>>>
>>>>>>>>> Hi Cesar,
>>>>>>>>>
>>>>>>>>> Thanks for looking into enhancing EA.
>>>>>>>>>
>>>>>>>>> Overall, the proposal looks reasonable.
>>>>>>>>>
>>>>>>>>> I suggest to look more closely at split_unique_types().
>>>>>>>>> It introduces a dedicated class of alias categories for fields of
>>>>>>>>> the allocation being eliminated and clones memory graph. I don't
>>>>>>>>> see why it shouldn't work for multiple allocations.
>>>>>>>>>
>>>>>>>>> Moreover, split_unique_types() will break if you start optimizing
>>>>>>>>> multiple allocations at once. The notion of unique alias should be
>>>>>>>>> adjusted and cover the union of unique aliases for all interacting
>>>>>>>>> allocations.
>>>>>>>>>
>>>>>>>>> Seems like you need to enhance SR to work on non-intersecting
>>>>>>>>> clusters of allocations.
>>>>>>>>>
>>>>>>>>> One thing to take care of: scalar replacement relies on
>>>>>>>>> TypeOopPtr::instance_id().
>>>>>>>>>
>>>>>>>>> ???? // If not InstanceTop or InstanceBot, indicates that this is
>>>>>>>>> ???? // a particular instance of this type which is distinct.
>>>>>>>>> ???? // This is the node index of the allocation node creating this
>>>>>>>>> instance.
>>>>>>>>> ???? int?????????? _instance_id;
>>>>>>>>>
>>>>>>>>> It'll break when multiple allocations are in play.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Vladimir Ivanov
>>>>>>>>>
>>>>>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>>>>>> Hi there again!
>>>>>>>>>>
>>>>>>>>>> Can you please give me feedback on the following approach to at
>>>>>>>>>> least partially
>>>>>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>>>>>
>>>>>>>>>> The problem that I am trying to solve arises when allocations are
>>>>>>>>>> merged after a
>>>>>>>>>> control flow split. The code below shows _one example_ of such a
>>>>>>>>>> situation.
>>>>>>>>>>
>>>>>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>>>>>> ?????? Point p = new Point(x, y);
>>>>>>>>>> ?????? if (cond)
>>>>>>>>>> ?????????? p = new Point(y, x);
>>>>>>>>>> ?????? // Allocations for p are merged here.
>>>>>>>>>> ?????? return p.calc();
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Assuming the method calls on "p" are inlined then the allocations
>>>>>>>>>> will not
>>>>>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>>>>>
>>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>> ?????? p0 = Allocate(...);
>>>>>>>>>> ?????? ...
>>>>>>>>>> ?????? p0.x = first;
>>>>>>>>>> ?????? p0.y = second;
>>>>>>>>>>
>>>>>>>>>> ?????? if (cond) {
>>>>>>>>>> ?????????? p1 = Allocate(...);
>>>>>>>>>> ?????????? ...
>>>>>>>>>> ?????????? p1.x = second;
>>>>>>>>>> ?????????? p1.y = first;
>>>>>>>>>> ?????? }
>>>>>>>>>>
>>>>>>>>>> ?????? p = phi(p0, p1)
>>>>>>>>>>
>>>>>>>>>> ?????? return p.x - p.y;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> However, one of the constraints implemented here [2],
>>>>>>>>>> specifically the third
>>>>>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>>>>>
>>>>>>>>>> The approach that I'm considering for solving the problem is to
>>>>>>>>>> replace the Phi
>>>>>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields
>>>>>>>>>> of the objects
>>>>>>>>>> in the original Phi. The IR for `ex1` would look something like
>>>>>>>>>> this after the
>>>>>>>>>> transformation:
>>>>>>>>>>
>>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>> ?????? p0 = Allocate(...);
>>>>>>>>>> ?????? ...
>>>>>>>>>> ?????? p0.x = first;
>>>>>>>>>> ?????? p0.y = second;
>>>>>>>>>>
>>>>>>>>>> ?????? if (cond) {
>>>>>>>>>> ?????????? p1 = Allocate(...);
>>>>>>>>>> ?????????? ...
>>>>>>>>>> ?????????? p1.x = second;
>>>>>>>>>> ?????????? p1.y = first;
>>>>>>>>>> ?????? }
>>>>>>>>>>
>>>>>>>>>> ?????? pX = phi(first, second)
>>>>>>>>>> ?????? pY = phi(second, first)
>>>>>>>>>>
>>>>>>>>>> ?????? return pX - pY;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> I understand that this transformation might not be applicable for
>>>>>>>>>> all cases and
>>>>>>>>>> that it's not as simple as illustrated above. Also, it seems to
>>>>>>>>>> me that much of
>>>>>>>>>> what I'd have to implement is already implemented in other steps
>>>>>>>>>> of the Scalar
>>>>>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>>>>>> implementation details I plan to use as much of the existing code
>>>>>>>>>> as possible.
>>>>>>>>>> The algorithm for the transformation would be like this:
>>>>>>>>>>
>>>>>>>>>> split_phis(phi)
>>>>>>>>>> ?????? # If output of phi escapes, or something uses its identity, etc
>>>>>>>>>> ?????? # then we can't remove it. The conditions here might
>>>>>>>>>> possible be the
>>>>>>>>>> ?????? # same as the ones implemented in
>>>>>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>>>>>> ?????? if cant_remove_phi_output(phi)
>>>>>>>>>> ?????????? return ;
>>>>>>>>>>
>>>>>>>>>> ?????? # Collect a set of tuples(F,U) containing nodes U that uses
>>>>>>>>>> field F
>>>>>>>>>> ?????? # member of the object resulting from `phi`.
>>>>>>>>>> ?????? fields_used = collect_fields_used_after_phi(phi)
>>>>>>>>>>
>>>>>>>>>> ?????? foreach field in fields_used
>>>>>>>>>> ?????????? producers = {}
>>>>>>>>>>
>>>>>>>>>> ?????????? # Create a list with the last Store for each field
>>>>>>>>>> "field" on the
>>>>>>>>>> ?????????? # scope of each of the Phi input objects.
>>>>>>>>>> ?????????? foreach o in phi.inputs
>>>>>>>>>> ?????????????? # The function called below might re-use a lot of
>>>>>>>>>> the code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>>>>>> ?????????????? producers += last_store_to_o_field(0, field)
>>>>>>>>>> ?????????? # Create a new phi node whose inputs are the Store's to
>>>>>>>>>> 'field'
>>>>>>>>>> ?????????? field_phi = create_new_phi(producers)
>>>>>>>>>>
>>>>>>>>>> ?????????? update_consumers(field, field_phi)
>>>>>>>>>>
>>>>>>>>>> The implementation that I envisioned would be as a "pre-process"
>>>>>>>>>> [3] step just
>>>>>>>>>> after EA but before the constraint checks in
>>>>>>>>>> `adjust_scalar_replaceable_state`
>>>>>>>>>> [2]. If we agree that the overall Scalar Replacement
>>>>>>>>>> implementation goes through
>>>>>>>>>> the following major phases:
>>>>>>>>>>
>>>>>>>>>> ?????? 1. Identify the Escape Status of objects.
>>>>>>>>>> ?????? 2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>>>> based on a set of constraints.
>>>>>>>>>> ?????? 3. Make call to Split_unique_types [4].
>>>>>>>>>> ?????? 4 Iterate over object and array allocations.
>>>>>>>>>> ?????????? 4.1 Check if allocation can be eliminated.
>>>>>>>>>> ?????????? 4.2 Perform scalar replacement. Replace uses of object
>>>>>>>>>> in Safepoints.
>>>>>>>>>> ?????????? 4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>>>
>>>>>>>>>> The transformation that I am proposing would change the overall
>>>>>>>>>> flow to look
>>>>>>>>>> like this:
>>>>>>>>>>
>>>>>>>>>> ?????? 1. Identify the Escape Status of objects.
>>>>>>>>>> ?????? 2. ----> New: "Split phi functions" <----
>>>>>>>>>> ?????? 2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>>>> based on a set of constraints.
>>>>>>>>>> ?????? 3. Make call to Split_unique_types [14].
>>>>>>>>>> ?????? 4 Iterate over object and array allocations.
>>>>>>>>>> ?????????? 4.1 ----> Moved to split_phi: "Check if allocation can
>>>>>>>>>> be eliminated" <----
>>>>>>>>>> ?????????? 4.2 Perform scalar replacement. Replace uses of object
>>>>>>>>>> in Safepoints.
>>>>>>>>>> ?????????? 4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>>>
>>>>>>>>>> Please let me know what you think and thank you for taking the
>>>>>>>>>> time to review
>>>>>>>>>> this!
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Cesar
>>>>>>>>>>
>>>>>>>>>> Notes:
>>>>>>>>>>
>>>>>>>>>> ?????? [1] I am not sure yet how this approach will play with the
>>>>>>>>>> case of a merge
>>>>>>>>>> ?????????? with NULL.
>>>>>>>>>> ?????? [2]
>>>>>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809%26amp%3Bdata%3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc%24&amp;data=04%7C01%7Cdivino.cesar%40microsoft.com%7C8c1737b992e847651e8d08d9f62d649b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637811497098895122%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=8hLm9BcYVRF810gFqf2%2B%2Fd28jzqU2k7htD%2FDLqR9vAM%3D&amp;reserved=0 
>>
>> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24&amp;data=04*7C01*7Cdivino.cesar*40microsoft.com*7C8c1737b992e847651e8d08d9f62d649b*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637811497098895122*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=8hLm9BcYVRF810gFqf2*2B*2Fd28jzqU2k7htD*2FDLqR9vAM*3D&amp;reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!c3mFGaPH2PWpbeiHR44WrjfJKF0Ymg6aPQ8EOEMK0t5iYjdL4XwgsEvifrlDVrer2pCrdQ$> 
>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ?????? [3] Another option would be to "patch" the current
>>>>>>>>>> implementation to be able
>>>>>>>>>> ?????????? to handle the merges. I am not certain that the "patch"
>>>>>>>>>> approach would be
>>>>>>>>>> ?????????? better, however, the "pre-process" approach is certainly
>>>>>>>>>> much easier to test
>>>>>>>>>> ?????????? and more readable.
>>>>>>>>>>
>>>>>>>>>> ?????? [4] I cannot say I understand 100% the effects of executing
>>>>>>>>>> ?????????? split_unique_types(). Would the transformation that I am
>>>>>>>>>> proposing need to
>>>>>>>>>> ?????????? be after the call to split_unique_types?
>>

From psandoz at openjdk.java.net  Mon Mar 28 19:22:48 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 28 Mar 2022 19:22:48 GMT
Subject: RFR: 8282764: AArch64:
 compiler/vectorapi/reshape/TestVectorCastNeon.java failed with incorrect
 result
In-Reply-To: <5s9gVoO8BXDC9k_GYrcMupuP60CgvgvvuTwy6obPZqA=.dbbccd3f-f4f2-404f-a9f5-7b2e110cd84e@github.com>
References: <5s9gVoO8BXDC9k_GYrcMupuP60CgvgvvuTwy6obPZqA=.dbbccd3f-f4f2-404f-a9f5-7b2e110cd84e@github.com>
Message-ID: <jprkEaKlXP1SiUR1Pv1oaUVFchHOn1nA-b1mrtQXr4A=.798f40c0-2ba9-410f-99ea-964a8503bf4b@github.com>

On Thu, 17 Mar 2022 04:33:59 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

> Vector API long to float conversion operation on NEON converts vector of 2 longs to 2 floats. In current implementation, we convert 2 longs to 2 doubles first and then converts 2 doubles to 2 floats. However, this two-steps conversion may have two roundings, while the expected behavior, conversion from long to float directly, has only one rounding. This will result in inconsistent result. E.g. for the failure test case:
> 
> 
> jshell> long l = 0x561a524000000001L;
> l ==> 6204361871487664129
> 
> jshell> float l2f = (float)l;
> l2f ==> 6.2043621E18
> 
> jshell> float l2d2f = (float)((double)l);
> l2d2f ==> 6.2043616E18
> 
> 
> Since we don't have NEON instruction to support vector long to float conversion, we fix the codegen by doing it in scalar operation one element by one element.
> 
> TEST: vector api jtreg tests passed.

Thanks for updating the copyright year. Java changes look good. Just one comment related to an additional value added for testing.

test/hotspot/jtreg/compiler/vectorapi/VectorCastShape128Test.java line 117:

> 115:         Long.MAX_VALUE,
> 116:         Long.MIN_VALUE,
> 117:         0x561a524000000001L,

A comment would be useful as to why this constant is important

-------------

PR: https://git.openjdk.java.net/jdk/pull/7850

From serb at openjdk.java.net  Mon Mar 28 20:30:35 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 28 Mar 2022 20:30:35 GMT
Subject: RFR: 8283422: Create a new test for JDK-8254790 [v2]
In-Reply-To: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
References: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
Message-ID: <9ZQqrMPVWSjmkh3Riwbd7UR1kMD5VzCsNOugmJigMCQ=.d8ae041a-80d6-485c-bc95-ef2a0c1a0605@github.com>

> The [JDK-8254790](https://bugs.openjdk.java.net/browse/JDK-8254790) initially was reported on macOS.
> It was found by the "javax/xml/crypto/dsig/GenerationTests.java" test which for some reason worked fine on Linux/Windows most? of the time.
> 
> I tried to run that test on Linux/Windows many times on a few systems and it always pass. Also, I got the same result for the tier1...tier4 tests.
> 
> I have found that the easiest way to reproduce the crash is to pass the result of the string.indexOf to the str.charAt when the heap is big enough. The test below[1] trigger the crash 1000 time in a row on win/lin on systems I have tested.
> 
> I am not sure what is the best way to contribute to the test, should I create a stand-alone test like[1], or update an existing test as I did for the first version of this PR?
> 
> [1]:
> 
> package compiler.intrinsics.string;
> 
> import static jdk.test.lib.Asserts.assertTrue;
> 
> public final class TestStringIndexOfLargeHeap {
>     static final int[] data = new int[Integer.MAX_VALUE / 2];
>     public static void main(String[] args) throws Exception {
>         test('a');
>         test('\ubeef');
>     }
>     private static void test(char ch) {
>         String str = ("0123456789" + ch).repeat(100);
>         for (int i = 0; i < 1_000_000; ++i) {
>             assertTrue(ch == str.charAt(str.indexOf(ch)));
>         }
>     }
> }

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Request 8G of heap
 - Merge branch 'master' into JDK-8283422
 - Add vm.bits == "64"
 - Initial version

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7883/files
  - new: https://git.openjdk.java.net/jdk/pull/7883/files/78c76a4e..ab2fbc35

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7883&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7883&range=00-01

  Stats: 106494 lines in 1407 files changed: 86986 ins; 16137 del; 3371 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7883.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7883/head:pull/7883

PR: https://git.openjdk.java.net/jdk/pull/7883

From njian at openjdk.java.net  Tue Mar 29 02:27:37 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Tue, 29 Mar 2022 02:27:37 GMT
Subject: RFR: 8282875: AArch64: [vectorapi] Optimize Vector.reduceLane for
 SVE 64/128 vector size
In-Reply-To: <HEIAfnyvOiwL-9LFv90k77iWT2q9HqNre5fYzWDBtUQ=.a816ab22-6937-4dbc-9756-fbb128a9ef75@github.com>
References: <6KkmSzP3na8JUnMFh3Yfzm6yuzk1EWr1LORhDLDPxRM=.c4bf6878-3964-4b9e-9225-f0fe3da1fc16@github.com>
 <HEIAfnyvOiwL-9LFv90k77iWT2q9HqNre5fYzWDBtUQ=.a816ab22-6937-4dbc-9756-fbb128a9ef75@github.com>
Message-ID: <X9XPvzIEH-gehrFld0d3vRvLqJb8MS1attd-yFj3n8w=.b212d1b0-4e2d-40f2-9048-51668e077bfb@github.com>

On Mon, 28 Mar 2022 17:36:48 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Out of curiosity, how do we propose to distinguish when we should use SVE? I guess as long as we only have Neoverse V1/N2 for SVE it makes sense to concentrate on that, but I guess we'll want a better optimization model sooner or later.

Indeed, that's what we need to resolve. Currently, we don't have a good model yet, so we just trying not to use SVE if it doesn't win. We are also trying to merge current neon/sve ad files into single one. Hopefully that will make codegen easier to choose SVE/NEON, e.g. for small vector lengths.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7999

From jiefu at openjdk.java.net  Tue Mar 29 05:08:42 2022
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 29 Mar 2022 05:08:42 GMT
Subject: RFR: 8282162: [vector] Optimize integral vector negation API [v3]
In-Reply-To: <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
 <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com>
Message-ID: <FSU8kfAI527aklR_m1bqxxOYCN4cHdaLwRrin2em4PQ=.5bbe78aa-3cfc-4ab5-a40a-cb27abe6b9c0@github.com>

On Mon, 28 Mar 2022 09:56:22 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE.
>> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern.
>> 
>> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture:
>>   - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation.
>>   - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`.
>> 
>> So with this patch, the following transformations are applied:
>> 
>> For non-masked negation with NEON:
>> 
>>   movi    v16.4s, #0x0
>>   sub v17.4s, v16.4s, v17.4s       ==> neg v17.4s, v17.4s
>> 
>> and with SVE:
>> 
>>   mov z16.s, #0
>>   sub z18.s, z16.s, z17.s          ==> neg z16.s, p7/m, z16.s
>> 
>> For masked negation with NEON:
>> 
>>   movi    v17.4s, #0x1
>>   mvn v19.16b, v18.16b
>>   mov v20.16b, v16.16b             ==>  neg v18.4s, v17.4s
>>   bsl v20.16b, v19.16b, v18.16b         bsl v19.16b, v18.16b, v17.16b
>>   add v19.4s, v20.4s, v17.4s
>>   mov v18.16b, v16.16b
>>   bsl v18.16b, v19.16b, v20.16b
>> 
>> and with SVE:
>> 
>>   mov z16.s, #-1
>>   mov z17.s, #1                    ==> neg z16.s, p0/m, z16.s
>>   eor z18.s, p0/m, z18.s, z16.s
>>   add z18.s, p0/m, z18.s, z17.s
>> 
>> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed):
>> 
>> NEON:
>> Benchmark                Gain
>> Byte128Vector.NEG        1.029
>> Byte128Vector.NEGMasked  1.757
>> Short128Vector.NEG       1.041
>> Short128Vector.NEGMasked 1.659
>> Int128Vector.NEG         1.005
>> Int128Vector.NEGMasked   1.513
>> Long128Vector.NEG        1.003
>> Long128Vector.NEGMasked  1.878
>> 
>> SVE with 512-bits:
>> Benchmark                Gain
>> ByteMaxVector.NEG        1.10
>> ByteMaxVector.NEGMasked  1.165
>> ShortMaxVector.NEG       1.056
>> ShortMaxVector.NEGMasked 1.195
>> IntMaxVector.NEG         1.002
>> IntMaxVector.NEGMasked   1.239
>> LongMaxVector.NEG        1.031
>> LongMaxVector.NEGMasked  1.191
>> 
>> X86 (non AVX-512):
>> Benchmark                Gain
>> ByteMaxVector.NEGMasked  1.254
>> ShortMaxVector.NEGMasked 1.359
>> IntMaxVector.NEGMasked   1.431
>> LongMaxVector.NEGMasked  1.989
>> 
>> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make "degenerate_vector_integral_negate" to be "NegVI" private

Obvious performance improvement had ben observed on x86 for integral vector negation.
So I think it's good to go.

LGTM
Thanks.

Note: I didn't check the aarch64 code change.

-------------

Marked as reviewed by jiefu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7782

From xgong at openjdk.java.net  Tue Mar 29 05:57:40 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 29 Mar 2022 05:57:40 GMT
Subject: RFR: 8282431: AArch64: Add optimized rules for masked vector
 multiply-add/sub for SVE [v2]
In-Reply-To: <SW3zLs9MPHtWkj6c9SdEFOUaCjAIQ6wpAoTF6gaY80I=.89ff44d1-db70-4c82-ad88-02e1e49bff63@github.com>
References: <bRRrWEoEmJk24aLM-eRglGGIttZ2eAIBexmskoh4tdw=.34cca7f0-92b5-4e02-9019-036a29dfc066@github.com>
 <SW3zLs9MPHtWkj6c9SdEFOUaCjAIQ6wpAoTF6gaY80I=.89ff44d1-db70-4c82-ad88-02e1e49bff63@github.com>
Message-ID: <p2WewmpJ1KA8tYySLNpKTXYV-upJ10oValvRcVCTzCk=.05793597-4dd2-4f2d-af69-6a33b096cfb7@github.com>

On Thu, 10 Mar 2022 07:55:15 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> We have the optimized match rules for vector `"fmls,fnmla,fnmls,mla,mls"` for ARM SVE. Similarly we can also add the rules for the relative masked operations to generate the optimized predicated instructions.
>> 
>> With this patch the following masked vector multiply-add for a byte vector:
>> 
>>   mul z18.b, p7/m, z18.b, z17.b
>>   add z17.b, p0/m, z17.b, z18.b
>> 
>> could be optimized to: 
>> 
>>    mla z19.b, p0/m, z18.b, z17.b
>> 
>>  And so does the multiply-sub operations. Also the following masked fused multiply-substract for a float vector:
>> 
>>   fneg    z18.s, p7/m, z18.s
>>   fmad    z17.s, p0/m, z18.s, z16.s
>> 
>> could be optimized to: 
>> 
>>   fmsb z17.s, p0/m, z18.s, z16.s"
>> 
>>  And the same to the relative negated fused operations.
>> 
>> This patch also fixes the potential issues for the usage of `NegVF/D` in match rules. The explicit check of non-predicated vector for `NegVF/D` must be added to the match rule predicate if the `NegVF/D` is assumed to be non-masked. Otherwise, the jvm might crash if a masked` NegVF/D` with two operands is matched into a rule which assumes the `NegVF/D` in subtree has one operand.
>> 
>> Also add the jtreg tests for all the touched vector operations.
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the ir framework for the test

Hi, could anyone please help to take a look at this PR? Thanks so much!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7737

From xgong at openjdk.java.net  Tue Mar 29 06:00:43 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Tue, 29 Mar 2022 06:00:43 GMT
Subject: RFR: 8282162: [vector] Optimize integral vector negation API [v3]
In-Reply-To: <FSU8kfAI527aklR_m1bqxxOYCN4cHdaLwRrin2em4PQ=.5bbe78aa-3cfc-4ab5-a40a-cb27abe6b9c0@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
 <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com>
 <FSU8kfAI527aklR_m1bqxxOYCN4cHdaLwRrin2em4PQ=.5bbe78aa-3cfc-4ab5-a40a-cb27abe6b9c0@github.com>
Message-ID: <3b3zK9Dbs2d-PFUsnmAJJlmp2OddRhHEDYb5ISm8fvs=.728bf5b9-aff5-45bf-a436-f17fa7be50be@github.com>

On Tue, 29 Mar 2022 05:05:43 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make "degenerate_vector_integral_negate" to be "NegVI" private
>
> Note: I didn't check the aarch64 code change.

Thanks for the review @DamonFool !

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From thartmann at openjdk.java.net  Tue Mar 29 07:14:03 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 29 Mar 2022 07:14:03 GMT
Subject: RFR: 8283834: Unmappable character for US-ASCII encoding in
 TestPredicateInputBelowLoopPredicate
In-Reply-To: <Hiu7pc59EO6LTTU0FwDmOdX15Byv2Vlx-_E8vliiqys=.7ef125ae-993f-488a-8442-92b043ef2eb7@github.com>
References: <Hiu7pc59EO6LTTU0FwDmOdX15Byv2Vlx-_E8vliiqys=.7ef125ae-993f-488a-8442-92b043ef2eb7@github.com>
Message-ID: <d-1dUib4ixd-wKEe0wnRcewqxPka5mMpcPhXcj7KJYg=.6cd0585f-9acd-4256-9d62-919a96f48030@github.com>

On Tue, 29 Mar 2022 07:06:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Trivial fix that replaces the non-ascii character `\ufffd\ufffd2` by `C`.
> 
> Thanks,
> Tobias

For the record, one can easily find such non-ascii characters with `grep -P '[^\x00-\x7f]' -r test/hotspot/jtreg/`

-------------

PR: https://git.openjdk.java.net/jdk/pull/8011

From thartmann at openjdk.java.net  Tue Mar 29 07:14:02 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 29 Mar 2022 07:14:02 GMT
Subject: RFR: 8283834: Unmappable character for US-ASCII encoding in
 TestPredicateInputBelowLoopPredicate
Message-ID: <Hiu7pc59EO6LTTU0FwDmOdX15Byv2Vlx-_E8vliiqys=.7ef125ae-993f-488a-8442-92b043ef2eb7@github.com>

Trivial fix that replaces the non-ascii character `\ufffd\ufffd2` by `C`.

Thanks,
Tobias

-------------

Commit messages:
 - 8283834: Unmappable character for US-ASCII encoding in TestPredicateInputBelowLoopPredicate

Changes: https://git.openjdk.java.net/jdk/pull/8011/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8011&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283834
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8011.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8011/head:pull/8011

PR: https://git.openjdk.java.net/jdk/pull/8011

From chagedorn at openjdk.java.net  Tue Mar 29 07:18:42 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 29 Mar 2022 07:18:42 GMT
Subject: RFR: 8283834: Unmappable character for US-ASCII encoding in
 TestPredicateInputBelowLoopPredicate
In-Reply-To: <Hiu7pc59EO6LTTU0FwDmOdX15Byv2Vlx-_E8vliiqys=.7ef125ae-993f-488a-8442-92b043ef2eb7@github.com>
References: <Hiu7pc59EO6LTTU0FwDmOdX15Byv2Vlx-_E8vliiqys=.7ef125ae-993f-488a-8442-92b043ef2eb7@github.com>
Message-ID: <auX7Xq9qAeL6ymLe7hC8djajrg0-LbSSkvBBqt4Ty0E=.f3001ca8-b080-449e-8e3e-ee36d6cf9830@github.com>

On Tue, 29 Mar 2022 07:06:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Trivial fix that replaces the non-ascii character `\ufffd\ufffd2` by `C`.
> 
> Thanks,
> Tobias

That was hard to catch by just looking at it :-) Looks good and trivial.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8011

From thartmann at openjdk.java.net  Tue Mar 29 07:24:45 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 29 Mar 2022 07:24:45 GMT
Subject: RFR: 8283834: Unmappable character for US-ASCII encoding in
 TestPredicateInputBelowLoopPredicate
In-Reply-To: <Hiu7pc59EO6LTTU0FwDmOdX15Byv2Vlx-_E8vliiqys=.7ef125ae-993f-488a-8442-92b043ef2eb7@github.com>
References: <Hiu7pc59EO6LTTU0FwDmOdX15Byv2Vlx-_E8vliiqys=.7ef125ae-993f-488a-8442-92b043ef2eb7@github.com>
Message-ID: <T2ot3FD0DfqsDGOKEmT-3aL6z04XeO_fiSIH46LHObc=.ceafeee8-f2c9-4950-9616-ec255198addf@github.com>

On Tue, 29 Mar 2022 07:06:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Trivial fix that replaces the non-ascii character `?` (UTF-8 `0xd0 0xa1` -> "CYRILLIC CAPITAL LETTER ES") by `C`.
> 
> Thanks,
> Tobias

Thanks, Christian!

-------------

PR: https://git.openjdk.java.net/jdk/pull/8011

From thartmann at openjdk.java.net  Tue Mar 29 07:24:46 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 29 Mar 2022 07:24:46 GMT
Subject: Integrated: 8283834: Unmappable character for US-ASCII encoding in
 TestPredicateInputBelowLoopPredicate
In-Reply-To: <Hiu7pc59EO6LTTU0FwDmOdX15Byv2Vlx-_E8vliiqys=.7ef125ae-993f-488a-8442-92b043ef2eb7@github.com>
References: <Hiu7pc59EO6LTTU0FwDmOdX15Byv2Vlx-_E8vliiqys=.7ef125ae-993f-488a-8442-92b043ef2eb7@github.com>
Message-ID: <R-AYTJFYJZzXlVs_HHvSLs070d0JY1fZQPPD2if---g=.4bcad685-1891-4669-bf8a-dc4ac2bf9643@github.com>

On Tue, 29 Mar 2022 07:06:45 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Trivial fix that replaces the non-ascii character `?` (UTF-8 `0xd0 0xa1` -> "CYRILLIC CAPITAL LETTER ES") by `C`.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: 23672288
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/236722883511ee6111ab1de80ebc3fbec350c61d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8283834: Unmappable character for US-ASCII encoding in TestPredicateInputBelowLoopPredicate

Reviewed-by: chagedorn

-------------

PR: https://git.openjdk.java.net/jdk/pull/8011

From roland at openjdk.java.net  Tue Mar 29 07:29:44 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 29 Mar 2022 07:29:44 GMT
Subject: RFR: 8275201: C2: hide klass() accessor from TypeOopPtr and
 typeKlassPtr subclasses [v2]
In-Reply-To: <IZNb8OqZiYD6dyr8-D9uda17r5Deb9KVGEHaGGtcNxk=.9fdfa5c7-220f-49d4-a882-6c3a4955f206@github.com>
References: <RguqZnhYbwV_trD7IoCvbUKTDCbfGNlyeg-1F0G54ls=.e8729cde-7189-4d36-8684-e765770e372d@github.com>
 <IZNb8OqZiYD6dyr8-D9uda17r5Deb9KVGEHaGGtcNxk=.9fdfa5c7-220f-49d4-a882-6c3a4955f206@github.com>
Message-ID: <OYpJZ7VH6cZV1mVMP5ijijaf42z5zI0KiqD7JVCUIEk=.23b7c5ed-f4b5-4f7b-8017-c630acb7f37f@github.com>

On Mon, 28 Feb 2022 14:28:40 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> Outside the type system code itself, c2 usually assumes that a
>> TypeOopPtr or a TypeKlassPtr's java type is fully represented by its
>> klass(). To have proper support for interfaces, that can't be true as
>> a type needs to be represented by an instance class and a set of
>> interfaces. This patch hides the klass() accessor of
>> TypeOopPtr/TypeKlassPtr and reworks c2 code that relies on it in a way
>> that makes that code suitable for proper interface support in a
>> subsequent change. This patch doesn't add proper interface support yet
>> and is mostly refactoring. "Mostly" because there are cases where the
>> previous logic would use a ciKlass but the new one works with a
>> TypeKlassPtr/TypeInstPtr which carries the ciKlass and whether the
>> klass is exact or not. That extra bit of information can sometimes
>> help and so could result in slightly different decisions.
>> 
>> To remove the klass() accessors, the new logic either relies on:
>> 
>> - new methods of TypeKlassPtr/TypeInstPtr. For instance, instead of:
>> toop->klass()->is_subtype_of(other_toop->klass())
>> the new code is:
>> toop->is_java_subtype_of(other_toop)
>> 
>> - variants of the klass() accessors for narrower cases like
>>   TypeInstPtr::instance_klass() (returns _klass except if _klass is an
>>   interface in which case it returns Object),
>>   TypeOopPtr::unloaded_klass() (returns _klass but only when the klass
>>   is unloaed), TypeOopPtr::exact_klass() (returns _klass but only when
>>   the type is exact).
>> 
>> When I tested this patch, for most changes in this patch, I had the
>> previous logic, the new logic and a check that verified that they
>> return the same result. I ran as much testing as I could that way.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into JDK-8275201
>  - Merge branch 'master' into JDK-8275201
>  - build fix
>  - Merge branch 'master' into JDK-8275201
>  - whitespaces
>  - remove klass accessor

Comment to keep alive

-------------

PR: https://git.openjdk.java.net/jdk/pull/6717

From njian at openjdk.java.net  Tue Mar 29 07:43:08 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Tue, 29 Mar 2022 07:43:08 GMT
Subject: RFR: 8282764: AArch64:
 compiler/vectorapi/reshape/TestVectorCastNeon.java failed with incorrect
 result [v2]
In-Reply-To: <5s9gVoO8BXDC9k_GYrcMupuP60CgvgvvuTwy6obPZqA=.dbbccd3f-f4f2-404f-a9f5-7b2e110cd84e@github.com>
References: <5s9gVoO8BXDC9k_GYrcMupuP60CgvgvvuTwy6obPZqA=.dbbccd3f-f4f2-404f-a9f5-7b2e110cd84e@github.com>
Message-ID: <tGc05DsOPxV48goBd2BQDYPCzIcyj8E1d4Yb0wp_NyU=.e11269be-1a52-48db-906b-861bf2e54998@github.com>

> Vector API long to float conversion operation on NEON converts vector of 2 longs to 2 floats. In current implementation, we convert 2 longs to 2 doubles first and then converts 2 doubles to 2 floats. However, this two-steps conversion may have two roundings, while the expected behavior, conversion from long to float directly, has only one rounding. This will result in inconsistent result. E.g. for the failure test case:
> 
> 
> jshell> long l = 0x561a524000000001L;
> l ==> 6204361871487664129
> 
> jshell> float l2f = (float)l;
> l2f ==> 6.2043621E18
> 
> jshell> float l2d2f = (float)((double)l);
> l2d2f ==> 6.2043616E18
> 
> 
> Since we don't have NEON instruction to support vector long to float conversion, we fix the codegen by doing it in scalar operation one element by one element.
> 
> TEST: vector api jtreg tests passed.

Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision:

  Add comment for special value usage.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7850/files
  - new: https://git.openjdk.java.net/jdk/pull/7850/files/790fa68f..bf094065

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7850&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7850&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7850.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7850/head:pull/7850

PR: https://git.openjdk.java.net/jdk/pull/7850

From njian at openjdk.java.net  Tue Mar 29 07:43:10 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Tue, 29 Mar 2022 07:43:10 GMT
Subject: RFR: 8282764: AArch64:
 compiler/vectorapi/reshape/TestVectorCastNeon.java failed with incorrect
 result [v2]
In-Reply-To: <jprkEaKlXP1SiUR1Pv1oaUVFchHOn1nA-b1mrtQXr4A=.798f40c0-2ba9-410f-99ea-964a8503bf4b@github.com>
References: <5s9gVoO8BXDC9k_GYrcMupuP60CgvgvvuTwy6obPZqA=.dbbccd3f-f4f2-404f-a9f5-7b2e110cd84e@github.com>
 <jprkEaKlXP1SiUR1Pv1oaUVFchHOn1nA-b1mrtQXr4A=.798f40c0-2ba9-410f-99ea-964a8503bf4b@github.com>
Message-ID: <PYmIYRj00s-PswkxpkeUXE0rKrTYY8htwRkrl7-FnTw=.1a2011f3-e8b5-4714-85e5-1bee1aadb4be@github.com>

On Mon, 28 Mar 2022 19:20:45 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Thanks for updating the copyright year. Java changes look good. Just one comment related to an additional value added for testing.

Thank you for the review @PaulSandoz ! Code comment added.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7850

From fyang at openjdk.java.net  Tue Mar 29 08:36:45 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Tue, 29 Mar 2022 08:36:45 GMT
Subject: RFR: 8283737: riscv: MacroAssembler::stop() should emit
 fixed-length instruction sequence
In-Reply-To: <SdQ6BVPC9MXxCD42wXnclX5bmDx6Ckl-1Z46axMtkkU=.0b278560-7ffe-4750-9483-ea5c31898918@github.com>
References: <SdQ6BVPC9MXxCD42wXnclX5bmDx6Ckl-1Z46axMtkkU=.0b278560-7ffe-4750-9483-ea5c31898918@github.com>
Message-ID: <JKAxHYgbKyF2gVMonmd8YuYwQS-Dwpv9PHBuC87bMJI=.826a5e8f-43cc-4d9e-982d-cbb2d43cd3da@github.com>

On Mon, 28 Mar 2022 04:41:11 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> Hi team,
> 
> Could I have a review of this simple patch? -
> 
> `PhaseOutput::fill_buffer` detects if the real size of a node matches (<=) the size of it in scratch_emit(). The call chain for MacroAssembler::stop() is:
> 
> 
> MachEpilogNode::emit
>     -> reserved_stack_check()
>          -> should_not_reach_here()
>               -> stop(const char *msg)
> 
> 
> `li()` on RISCV could generate 1~6 instructions, and the msg argument could be an on-stack buffer; `stop()` also uses `__ pc()` that could also be different in `scratch_emit()` and `emit()`. They both have the potential issue here so the size generated in `MacroAssembler::stop()` needs to be a fixed value.
> 
> Could be reproduced in the fastdebug build by adding one line:
> 
> 
> // Die now.
> instruct ShouldNotReachHere() %{
>   match(Halt);
>   ins_cost(BRANCH_COST);
>   format %{ "#@ShouldNotReachHere" %}
>   ins_encode %{
>     Assembler::CompressibleRegion cr(&_masm);
>     if (is_reachable()) {
>       __ halt();
> +     __ unimplemented("this is an on-stack char literal");  // assertion fail at 'assert(false, "wrong size of mach node");'
>     }
>   %}
>   ins_pipe(pipe_class_default);
> %}
> 
> 
> This patch also fixes a typo introduced in JDK-8278994: `c_bnez` is mistakenly written to `c_beqz`, though not used until now, needing a fix for future usage.
> 
> 
> Tests passed in hotspot tier1 & jdk tier1 without new errors found.
> 
> Thanks,
> Xiaolin

Changes requested by fyang (Committer).

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 532:

> 530: 
> 531: void MacroAssembler::stop(const char* msg) {
> 532:   // these shall generate fixed-length instruction sequences

Looks reasonable to me. (Not a JDK Reviewer)
Suggestion for the code comment:

@@ -531,6 +531,9 @@ void MacroAssembler::resolve_jobject(Register value, Register thread, Register t
 void MacroAssembler::stop(const char* msg) {
   address ip = pc();
   pusha();
+  // The length of the instruction sequence emitted should be independent
+  // of the values of msg and ip so that size of mach node for scratch emit
+  // and normal emit matches.
   li(c_rarg0, (uintptr_t)(address)msg);
   li(c_rarg1, (uintptr_t)(address)ip);
   mv(c_rarg2, sp);

-------------

PR: https://git.openjdk.java.net/jdk/pull/7982

From xlinzheng at openjdk.java.net  Tue Mar 29 08:46:44 2022
From: xlinzheng at openjdk.java.net (Xiaolin Zheng)
Date: Tue, 29 Mar 2022 08:46:44 GMT
Subject: RFR: 8283737: riscv: MacroAssembler::stop() should emit
 fixed-length instruction sequence [v2]
In-Reply-To: <SdQ6BVPC9MXxCD42wXnclX5bmDx6Ckl-1Z46axMtkkU=.0b278560-7ffe-4750-9483-ea5c31898918@github.com>
References: <SdQ6BVPC9MXxCD42wXnclX5bmDx6Ckl-1Z46axMtkkU=.0b278560-7ffe-4750-9483-ea5c31898918@github.com>
Message-ID: <ezcljs0Dppku3Q3T3GYgIWW3SZ3NZJKDTX87JtMNFmY=.4a111a54-8c67-4caf-9981-258a4eb2efda@github.com>

> Hi team,
> 
> Could I have a review of this simple patch? -
> 
> `PhaseOutput::fill_buffer` detects if the real size of a node matches (<=) the size of it in scratch_emit(). The call chain for MacroAssembler::stop() is:
> 
> 
> MachEpilogNode::emit
>     -> reserved_stack_check()
>          -> should_not_reach_here()
>               -> stop(const char *msg)
> 
> 
> `li()` on RISCV could generate 1~6 instructions, and the msg argument could be an on-stack buffer; `stop()` also uses `__ pc()` that could also be different in `scratch_emit()` and `emit()`. They both have the potential issue here so the size generated in `MacroAssembler::stop()` needs to be a fixed value.
> 
> Could be reproduced in the fastdebug build by adding one line:
> 
> 
> // Die now.
> instruct ShouldNotReachHere() %{
>   match(Halt);
>   ins_cost(BRANCH_COST);
>   format %{ "#@ShouldNotReachHere" %}
>   ins_encode %{
>     Assembler::CompressibleRegion cr(&_masm);
>     if (is_reachable()) {
>       __ halt();
> +     __ unimplemented("this is an on-stack char literal");  // assertion fail at 'assert(false, "wrong size of mach node");'
>     }
>   %}
>   ins_pipe(pipe_class_default);
> %}
> 
> 
> This patch also fixes a typo introduced in JDK-8278994: `c_bnez` is mistakenly written to `c_beqz`, though not used until now, needing a fix for future usage.
> 
> 
> Tests passed in hotspot tier1 & jdk tier1 without new errors found.
> 
> Thanks,
> Xiaolin

Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:

  Polish comments as the suggestion

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7982/files
  - new: https://git.openjdk.java.net/jdk/pull/7982/files/cd4a37b6..f3549b81

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7982&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7982&range=00-01

  Stats: 5 lines in 1 file changed: 3 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7982.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7982/head:pull/7982

PR: https://git.openjdk.java.net/jdk/pull/7982

From xlinzheng at openjdk.java.net  Tue Mar 29 08:46:45 2022
From: xlinzheng at openjdk.java.net (Xiaolin Zheng)
Date: Tue, 29 Mar 2022 08:46:45 GMT
Subject: RFR: 8283737: riscv: MacroAssembler::stop() should emit
 fixed-length instruction sequence [v2]
In-Reply-To: <JKAxHYgbKyF2gVMonmd8YuYwQS-Dwpv9PHBuC87bMJI=.826a5e8f-43cc-4d9e-982d-cbb2d43cd3da@github.com>
References: <SdQ6BVPC9MXxCD42wXnclX5bmDx6Ckl-1Z46axMtkkU=.0b278560-7ffe-4750-9483-ea5c31898918@github.com>
 <JKAxHYgbKyF2gVMonmd8YuYwQS-Dwpv9PHBuC87bMJI=.826a5e8f-43cc-4d9e-982d-cbb2d43cd3da@github.com>
Message-ID: <8VJ8ZNZzjH2iERBvzaR-nZ2XZKqhwtaW9WEIcJcSmzw=.44d7ed40-83ca-4d53-ba67-9256fe88473f@github.com>

On Tue, 29 Mar 2022 08:32:28 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Polish comments as the suggestion
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 532:
> 
>> 530: 
>> 531: void MacroAssembler::stop(const char* msg) {
>> 532:   // these shall generate fixed-length instruction sequences
> 
> Looks reasonable to me. (Not a JDK Reviewer)
> Suggestion for the code comment:
> 
> @@ -531,6 +531,9 @@ void MacroAssembler::resolve_jobject(Register value, Register thread, Register t
>  void MacroAssembler::stop(const char* msg) {
>    address ip = pc();
>    pusha();
> +  // The length of the instruction sequence emitted should be independent
> +  // of the values of msg and ip so that size of mach node for scratch emit
> +  // and normal emit matches.
>    li(c_rarg0, (uintptr_t)(address)msg);
>    li(c_rarg1, (uintptr_t)(address)ip);
>    mv(c_rarg2, sp);

Thanks for reviewing this patch and the polish of comments, Felix. It looks more precise than before.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7982

From xlinzheng at openjdk.java.net  Tue Mar 29 08:53:16 2022
From: xlinzheng at openjdk.java.net (Xiaolin Zheng)
Date: Tue, 29 Mar 2022 08:53:16 GMT
Subject: RFR: 8283737: riscv: MacroAssembler::stop() should emit
 fixed-length instruction sequence [v3]
In-Reply-To: <SdQ6BVPC9MXxCD42wXnclX5bmDx6Ckl-1Z46axMtkkU=.0b278560-7ffe-4750-9483-ea5c31898918@github.com>
References: <SdQ6BVPC9MXxCD42wXnclX5bmDx6Ckl-1Z46axMtkkU=.0b278560-7ffe-4750-9483-ea5c31898918@github.com>
Message-ID: <MxwYDXP63-lmhUYDRANE8_k6HXhmeSzBNY-Ebpc94Co=.7bb6097b-c4b0-456e-8248-024219c6ee3e@github.com>

> Hi team,
> 
> Could I have a review of this simple patch? -
> 
> `PhaseOutput::fill_buffer` detects if the real size of a node matches (<=) the size of it in scratch_emit(). The call chain for MacroAssembler::stop() is:
> 
> 
> MachEpilogNode::emit
>     -> reserved_stack_check()
>          -> should_not_reach_here()
>               -> stop(const char *msg)
> 
> 
> `li()` on RISCV could generate 1~6 instructions, and the msg argument could be an on-stack buffer; `stop()` also uses `__ pc()` that could also be different in `scratch_emit()` and `emit()`. They both have the potential issue here so the size generated in `MacroAssembler::stop()` needs to be a fixed value.
> 
> Could be reproduced in the fastdebug build by adding one line:
> 
> 
> // Die now.
> instruct ShouldNotReachHere() %{
>   match(Halt);
>   ins_cost(BRANCH_COST);
>   format %{ "#@ShouldNotReachHere" %}
>   ins_encode %{
>     Assembler::CompressibleRegion cr(&_masm);
>     if (is_reachable()) {
>       __ halt();
> +     __ unimplemented("this is an on-stack char literal");  // assertion fail at 'assert(false, "wrong size of mach node");'
>     }
>   %}
>   ins_pipe(pipe_class_default);
> %}
> 
> 
> This patch also fixes a typo introduced in JDK-8278994: `c_bnez` is mistakenly written to `c_beqz`, though not used until now, needing a fix for future usage.
> 
> 
> Tests passed in hotspot tier1 & jdk tier1 without new errors found.
> 
> Thanks,
> Xiaolin

Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:

  Polish comments as the suggestion

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7982/files
  - new: https://git.openjdk.java.net/jdk/pull/7982/files/f3549b81..1106943d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7982&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7982&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7982.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7982/head:pull/7982

PR: https://git.openjdk.java.net/jdk/pull/7982

From fyang at openjdk.java.net  Tue Mar 29 09:01:47 2022
From: fyang at openjdk.java.net (Fei Yang)
Date: Tue, 29 Mar 2022 09:01:47 GMT
Subject: RFR: 8283737: riscv: MacroAssembler::stop() should emit
 fixed-length instruction sequence [v3]
In-Reply-To: <MxwYDXP63-lmhUYDRANE8_k6HXhmeSzBNY-Ebpc94Co=.7bb6097b-c4b0-456e-8248-024219c6ee3e@github.com>
References: <SdQ6BVPC9MXxCD42wXnclX5bmDx6Ckl-1Z46axMtkkU=.0b278560-7ffe-4750-9483-ea5c31898918@github.com>
 <MxwYDXP63-lmhUYDRANE8_k6HXhmeSzBNY-Ebpc94Co=.7bb6097b-c4b0-456e-8248-024219c6ee3e@github.com>
Message-ID: <3i0fcwAt0upFSm_UJEGx_YxnjgxGq5rmuiGKchKm-G0=.cab31227-e368-4064-bf5a-ce66976bc0d3@github.com>

On Tue, 29 Mar 2022 08:53:16 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> Hi team,
>> 
>> Could I have a review of this simple patch? -
>> 
>> `PhaseOutput::fill_buffer` detects if the real size of a node matches (<=) the size of it in scratch_emit(). The call chain for MacroAssembler::stop() is:
>> 
>> 
>> MachEpilogNode::emit
>>     -> reserved_stack_check()
>>          -> should_not_reach_here()
>>               -> stop(const char *msg)
>> 
>> 
>> `li()` on RISCV could generate 1~6 instructions, and the msg argument could be an on-stack buffer; `stop()` also uses `__ pc()` that could also be different in `scratch_emit()` and `emit()`. They both have the potential issue here so the size generated in `MacroAssembler::stop()` needs to be a fixed value.
>> 
>> Could be reproduced in the fastdebug build by adding one line:
>> 
>> 
>> // Die now.
>> instruct ShouldNotReachHere() %{
>>   match(Halt);
>>   ins_cost(BRANCH_COST);
>>   format %{ "#@ShouldNotReachHere" %}
>>   ins_encode %{
>>     Assembler::CompressibleRegion cr(&_masm);
>>     if (is_reachable()) {
>>       __ halt();
>> +     __ unimplemented("this is an on-stack char literal");  // assertion fail at 'assert(false, "wrong size of mach node");'
>>     }
>>   %}
>>   ins_pipe(pipe_class_default);
>> %}
>> 
>> 
>> This patch also fixes a typo introduced in JDK-8278994: `c_bnez` is mistakenly written to `c_beqz`, though not used until now, needing a fix for future usage.
>> 
>> 
>> Tests passed in hotspot tier1 & jdk tier1 without new errors found.
>> 
>> Thanks,
>> Xiaolin
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Polish comments as the suggestion

Marked as reviewed by fyang (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7982

From tschatzl at openjdk.java.net  Tue Mar 29 12:47:53 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 29 Mar 2022 12:47:53 GMT
Subject: RFR: 8283494: Factor out calculation of actual number of XMM
 registers
In-Reply-To: <VWzCeBhLgEcnxHs1YZ73N3w2i5G3JcJwIR_jx9HiKls=.0e645b29-1809-4f05-950b-eecabc46010f@github.com>
References: <VWzCeBhLgEcnxHs1YZ73N3w2i5G3JcJwIR_jx9HiKls=.0e645b29-1809-4f05-950b-eecabc46010f@github.com>
Message-ID: <Y7MjPcmtfLWsBVDKqZmLhiC-r0p8TDRIjb9IhmS7g5E=.facc6f64-2732-4734-be78-e019e7678356@github.com>

On Wed, 23 Mar 2022 08:52:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that factors out calculation of the actually available number of XMM registers on a given processor/given command line options into a method and reuse that as much as possible?
> 
> This relates to this code snippet:
> 
>       int xmm_bypass_limit = FrameMap::nof_xmm_regs;
> #ifdef _LP64
>       if (UseAVX < 3) {
>         xmm_bypass_limit = xmm_bypass_limit / 2;
>       }
> #endif
> 
> 
> Also, there is already the method `FrameMap::get_num_caller_save_xmms()` that has been updated to use that new method `XMMRegisterImpl::available_xmm_registers()`; further I tried to appropriately use `FrameMap::get_num_caller_save_xmms` in the places where either would work. Please have a look in particular about that.
> 
> I did not change strange to me variable names like `xmm_bypass_limit` above as they probably make some sense to somebody as it's used quite often.
> 
> This also fixes a compilation error without configuring C1 introduced with [JDK-8283327](https://bugs.openjdk.java.net/browse/JDK-8283327).
> 
> Testing: tier1-5 (all but linux-aarch64 done), gha, local compilation with `configure --with-features=-compiler1`.
> 
> Thanks,
>   Thomas

Ping?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7917

From duke at openjdk.java.net  Tue Mar 29 13:51:48 2022
From: duke at openjdk.java.net (Evgeny Astigeevich)
Date: Tue, 29 Mar 2022 13:51:48 GMT
Subject: Integrated: 8283626: AArch64: Set relocInfo::offset_unit to 4
In-Reply-To: <7FGsw_mQVQ-BLGxv7WSSOh1OvyyL5X36X3lbLm_pMYM=.f9897ba8-0bf5-48fa-8d0a-bfb5030f4056@github.com>
References: <7FGsw_mQVQ-BLGxv7WSSOh1OvyyL5X36X3lbLm_pMYM=.f9897ba8-0bf5-48fa-8d0a-bfb5030f4056@github.com>
Message-ID: <Ryokhd90GMDImkGrURtHGjqOea3UfMBwZhFAQxkS6K8=.6b696848-9979-4e13-bc97-c2630ed8d411@github.com>

On Mon, 28 Mar 2022 12:26:17 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

> AArch64 instructions size is 4 bytes. Two lowest bits of `relocInfo` offsets can be discarded.
> Tested with release and fastdebug builds:
> - `gtest`: Passed.
> - `tier1`...`tier4`: Passed

This pull request has now been integrated.

Changeset: ab17f88f
Author:    Evgeny Astigeevich <eastig at amazon.com>
Committer: Volker Simonis <simonis at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ab17f88f6ccd793b718394987f868322a2cc0d1f
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8283626: AArch64: Set relocInfo::offset_unit to 4

Reviewed-by: simonis, aph

-------------

PR: https://git.openjdk.java.net/jdk/pull/7991

From chagedorn at openjdk.java.net  Tue Mar 29 15:27:10 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 29 Mar 2022 15:27:10 GMT
Subject: RFR: 8281429: PhiNode::Value() is too conservative for tripcount
 of CountedLoop [v4]
In-Reply-To: <TVfNcRf1PoQNhVICf9E1d_CZGUmJ9Dk6RoWDMq_u_Ko=.fbcf5126-75f9-4b15-bbf5-9246aae3bd6c@github.com>
References: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
 <Da1Z1ev11UNEZK79-GrvcfDF42Y_x0AJMkfrQe7111Y=.f9f350d1-c83d-4878-a89a-f50194d79872@github.com>
 <TVfNcRf1PoQNhVICf9E1d_CZGUmJ9Dk6RoWDMq_u_Ko=.fbcf5126-75f9-4b15-bbf5-9246aae3bd6c@github.com>
Message-ID: <FAizA5rK39BteP82IcnRr7fTb7C8lfEu1qySg4CFakY=.7c8a3150-919d-4cd2-a55d-f0ac02111c46@github.com>

On Tue, 22 Mar 2022 12:53:24 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> src/hotspot/share/opto/cfgnode.cpp line 1129:
>> 
>>> 1127:                   julong diff = (uhi - ulo - 1) / (-stride_t->lo_as_long()) * (-stride_t->lo_as_long());
>>> 1128:                   julong ufirst = hi->lo_as_long() - diff;
>>> 1129:                   first = reinterpret_cast<jlong &>(ufirst);
>> 
>> Could we also use a `static_cast` here and further down instead?
>
> Thanks for looking at this.
> I'm not sure. I modeled this code on java_add/java_substract etc.

I thought that just for a numeric conversion, one could use `static_cast` as `reinterpret_cast` operates on pointers or references. But I'm not entirely sure what the convention should be. I guess both should work fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7823

From chagedorn at openjdk.java.net  Tue Mar 29 15:27:16 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Tue, 29 Mar 2022 15:27:16 GMT
Subject: RFR: 8281429: PhiNode::Value() is too conservative for tripcount
 of CountedLoop [v4]
In-Reply-To: <_s5u6Mo55DSKvhPuAGSu0S64yFZH52q0quClp8NUoqw=.8fffa2d8-b92a-4f80-a600-656116abf542@github.com>
References: <lxE1Jz7qztpuxoMzdqSalu6j3_HNzQtF8FnoTz97XH0=.091cb82a-1f5f-4244-9b0d-73255496dd06@github.com>
 <_s5u6Mo55DSKvhPuAGSu0S64yFZH52q0quClp8NUoqw=.8fffa2d8-b92a-4f80-a600-656116abf542@github.com>
Message-ID: <7ZGKvjJe_k0DVdVKuNgZckQCaeJF5s-Gng32vwtqXD0=.576a2171-5079-4242-b50a-82c34d6a013c@github.com>

On Mon, 28 Mar 2022 07:29:20 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> The type for the iv phi of a counted loop is computed from the types
>> of the phi on loop entry and the type of the limit from the exit
>> test. Because the exit test is applied to the iv after increment, the
>> type of the iv phi is at least one less than the limit (for a positive
>> stride, one more for a negative stride).
>> 
>> Also, for a stride whose absolute value is not 1 and constant init and
>> limit values, it's possible to compute accurately the iv phi type.
>> 
>> This change caused a few failures and I had to make a few adjustments
>> to loop opts code as well.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - test fix
>  - more test
>  - test & fix
>  - other fix
>  - Merge branch 'master' into JDK-8281429
>  - exp
>  - review
>  - Merge branch 'master' into JDK-8281429
>  - Update src/hotspot/share/opto/cfgnode.cpp
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - Update src/hotspot/share/opto/cfgnode.cpp
>    
>    Co-authored-by: Tobias Hartmann <tobias.hartmann at oracle.com>
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/75d84a25...3a087b2c

src/hotspot/share/opto/loopnode.cpp line 846:

> 844:   }
> 845: 
> 846:   // May not have gone thru igvn yet so don't use _igvn.type(phi) (PhaseIdealLoop::is_counted_loop() sets the iv phi's type)

Comment seems to be outdated as we are not querying the type of the phi anymore. Can you update it?

test/hotspot/jtreg/compiler/c2/irTests/TestSkeletonPredicates.java line 33:

> 31:  * @test
> 32:  * @bug 8282592
> 33:  * @summary C2: assert(false) failed: graph should be schedulable

Are the changes to this file intended? They seem to be unrelated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7823

From neliasso at openjdk.java.net  Tue Mar 29 15:36:50 2022
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 29 Mar 2022 15:36:50 GMT
Subject: Integrated: 8283692: Add PrintIdealPhase that includes block
 scheduling
In-Reply-To: <PshDgWdf8qtkdZQdJCMJK3Mo-5zxN5sbW59nEtcoEz4=.c1ffc2db-a1aa-4ae5-bcb3-d445d6a58e08@github.com>
References: <PshDgWdf8qtkdZQdJCMJK3Mo-5zxN5sbW59nEtcoEz4=.c1ffc2db-a1aa-4ae5-bcb3-d445d6a58e08@github.com>
Message-ID: <o42P0ukazgG_MfU0nqpOEBtop7Ts3yfsPfdPS1KxJWU=.acb82edc-d173-45bf-9be1-008b4c5e3189@github.com>

On Fri, 25 Mar 2022 14:47:44 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> Hi,
> 
> This patch adds:
> 1) A new method Output::print_scheduling() that encapsulates the ir node printing on blocks
> 2) Modifying print_ideal_ir to use the print_scheduling() when there is a scheduling available
> 3) A new compiler phase MACH_ANALYSIS after the mach dependent optimizations.
> 
> Motivation:
> This is used by the IR-test framework when testing optimizations on mach-nodes, and is a requirement to be able to test peephole-optimizations (because peephole-removed nodes are only removed from the scheduling, not from the graph.)
> 
> Having a method for print_scheduling() is also very useful when debugging.
> 
> Please review,
> Nils Eliasson

This pull request has now been integrated.

Changeset: fe670ff4
Author:    Nils Eliasson <neliasso at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fe670ff403b259f94bb50e1aa1e0155b71fc6642
Stats:     40 lines in 4 files changed: 28 ins; 9 del; 3 mod

8283692: Add PrintIdealPhase that includes block scheduling

Reviewed-by: kvn, chagedorn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7960

From thartmann at openjdk.java.net  Tue Mar 29 16:53:53 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Tue, 29 Mar 2022 16:53:53 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v3]
In-Reply-To: <NQtRiYFx2_FiLpAUDa8qx96T27jFZt1yM0nk56rluno=.d9bc7262-4c90-4664-ba6b-88d5a1427f06@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <NQtRiYFx2_FiLpAUDa8qx96T27jFZt1yM0nk56rluno=.d9bc7262-4c90-4664-ba6b-88d5a1427f06@github.com>
Message-ID: <rL8r7k0H7xRO-bbAZ6HtCK1aU1rIGGHGV7zAF_tL9NA=.4afdd437-61b1-4056-b877-9e10fb2a1f82@github.com>

On Fri, 25 Mar 2022 10:29:00 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> This change adds a new view to the Ideal Graph Visualizer showing a classic control-flow graph (CFG) where nodes are serialized within basic blocks and arcs across basic blocks represent control flow:
>> 
>> ![cfg](https://user-images.githubusercontent.com/8792647/158367227-1ccfb9e0-bba1-4a80-963e-3e8c5f23c1c4.png)
>> 
>> The CFG provides a higher-level, more compact view of the graph than the existing views, where it can be hard to see the overall structure for all but the smallest graphs:
>> 
>> ![sea-vs-cfg](https://user-images.githubusercontent.com/8792647/158366842-f32b1b22-f7ed-4404-bb43-9d5c58a98ec4.png)
>> 
>> ![clusters-vs-cfg](https://user-images.githubusercontent.com/8792647/158366861-64561cfa-2553-4c9e-ad59-25acce6b4961.png)
>> 
>> If a schedule is available in the input graph (because it corresponds to the _Global code motion_ phase or later), the CFG, including the serialization of nodes within basic blocks, is derived from it. Otherwise, the CFG is approximated by the C2-specific `ServerCompilerScheduler` class. Dependencies among nodes are shown textually, by extending the label of each node with a list of its inputs:
>> 
>> <p align="center">
>>     <img width="35%" src="https://user-images.githubusercontent.com/8792647/158367428-5aa222e9-6a5c-4e78-871f-853e5b918599.png">
>> </p>
>> 
>> The exact information shown about each input can be configured in Tools -> Options -> Tiny Node Text.
>> 
>> The new CFG view is available at the same level as the existing "sea of nodes" (default) and "clustered sea-of-nodes" views. The view can be selected from the main toolbar:
>> 
>> ![toolbar](https://user-images.githubusercontent.com/8792647/158367502-ac8d8a29-5f35-4604-acc3-9d563c60e917.png)
>> 
>> The default view shown when opening a new graph can be configured in Tools -> Options -> Default View.
>> 
>> The same functionality available for the existing views also applies to the new CFG:
>> 
>> - node extraction:
>> 
>> ![node-extraction](https://user-images.githubusercontent.com/8792647/158371016-f7988eb6-368f-4805-ac7a-2b5611d16d7a.png)
>> 
>> - pop-up information on edges:
>> 
>> ![popup](https://user-images.githubusercontent.com/8792647/158367664-495189d5-384c-4b86-a62b-08863420c531.png)
>> 
>> - filtering:
>> 
>> ![filtering](https://user-images.githubusercontent.com/8792647/158367690-47b95bcd-7e8e-466e-b71b-f3e7d04c60ac.png)
>> 
>> - quick node and basic block search:
>> 
>> ![quick-search](https://user-images.githubusercontent.com/8792647/158367717-8bc90027-8ce7-4071-be04-1d67de6c91dd.png)
>> 
>> - and exporting.
>> 
>> The list of custom filters is extended with three new block-hiding filters:
>> 
>> - `Hide root block`: remove root block and hide all back-edges from exiting blocks that clutter the CFG.
>> 
>> - `Hide uncommon trap blocks`: remove blocks with uncommon traps to simplify following the "hot paths" in the CFG.
>> 
>> - `Hide exception blocks`: remove blocks that create and throw exceptions to also simplify following the "hot paths" in the CFG.
>> 
>> When using the CFG view, it is important to keep in mind that, in graphs corresponding to phases earlier than _Global code motion_, the presented CFG is just one of many possible projections of the sea-of-nodes representation, and that this projection is computed by an approximation of what C2 would do if it scheduled the graph at that stage. The approximation has some known limitations ([JDK-8280568](https://bugs.openjdk.java.net/browse/JDK-8280568), [JDK-8282053](https://bugs.openjdk.java.net/browse/JDK-8282053)). Future work should address these and warn the user when the approximated CFG is known to be inaccurate.
>> 
>> ### Testing
>> 
>> #### Functionality
>> 
>> - Tested the above functionality manually on a small selection of graphs.
>> 
>> - Tested automatically that scheduling (approximating C2's GCM and LCM algorithms) and viewing thousands of graphs in the three views does not trigger any assertion failure (by instrumenting IGV to schedule and view graphs as they are loaded and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).
>> 
>> #### Performance
>> 
>> - Measured the scheduling and view creation time for each of the three views on a selection of 22 large graphs (between 2515 and 7329 nodes). On average:
>> 
>> - The change introduces a slight overhead when creating the existing views (2% and 5% for the clustered and non-clustered sea-of-nodes views). This overhead is due to the introduction of abstractions and data structures required by the CFG view.
>> 
>> - The new CFG view is considerably faster to create than the existing ones (4.2x and 2.5x faster than the clustered and non-clustered sea-of-nodes views), as it can be expected, since only basic blocks have to be laid out. Furthermore, the CFG view scales better as the size of the graph increases.
>> 
>> - The change slows down scheduling by 27%. This overhead corresponds to the additional work of approximating C2's LCM, and it is essential for the CFG view. Fortunately, scheduling takes only a fraction of the time needed to create a view (typically no more than a third), and it only needs to run once for each graph, whereas views have to be re-created on node extraction, filtering, etc.
>> 
>> The performance results are [attached](https://github.com/openjdk/jdk/files/8252786/performance-evaluation.ods) (note that each measurement in the sheet corresponds to the median of ten runs).
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed last suggestion by Christian

Works like a charm for me and changes look reasonable. Approved!

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7817

From lucy at openjdk.java.net  Tue Mar 29 17:10:46 2022
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 29 Mar 2022 17:10:46 GMT
Subject: RFR: 8281079: [s390] Unify Address Operand Encoding in Instruction
 Emitters [v3]
In-Reply-To: <nesf35P-utm5j-xosWGl1mnu1XPvBvfcCTyOALC-CCo=.e27238c3-0a48-4d2b-a788-f6ec2bdb96ca@github.com>
References: <3jdwkLfde4-QZhILUQstfVekYOZzsO8wgT2cppmiot0=.15d30b40-c188-446b-9ff1-f3ea07807873@github.com>
 <nesf35P-utm5j-xosWGl1mnu1XPvBvfcCTyOALC-CCo=.e27238c3-0a48-4d2b-a788-f6ec2bdb96ca@github.com>
Message-ID: <GogmQiGQtfk1ThjZPARwbnYU7LfFjuPWVf8EY4KRQHY=.134abf8e-d14f-4002-a772-e52a39d5f481@github.com>

On Mon, 28 Feb 2022 17:10:26 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> May I please request reviews for this cleanup and unification change. It streamlines the address operand emitters for all instructions. As such, the modifications are widespread and may be cumbersome to review. Please ask questions if anything is unclear.
>> 
>> SAP does not maintain a full s390x build and test environment any longer. I would therefore very much appreciate if somebody would run a build and test cycle on s390x. 
>> 
>> As this is a s390x-only change, other platforms are not impacted.
>
> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor comment adaptations and code formatting

This PR has been lingering around for 14 days now since my last request for a second review. 
@backwaterred Could you please try to get approval from those in charge that I can integrate this PR? As mentioned above, we have a port of this PR to HotSpot 11 running in our in-house builds and tests since three weeks now - not a single issue. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7324

From kvn at openjdk.java.net  Tue Mar 29 17:26:44 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 29 Mar 2022 17:26:44 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con [v5]
In-Reply-To: <eDPR1Pnhl7pkWG3Epsc2X4sQWfOOPloJmZd9wy1SxLA=.8d7572bf-0a91-4c56-bb6a-ff580d6979e0@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
 <eDPR1Pnhl7pkWG3Epsc2X4sQWfOOPloJmZd9wy1SxLA=.8d7572bf-0a91-4c56-bb6a-ff580d6979e0@github.com>
Message-ID: <5tI1VxHY4Gh-mmsvS3WFF0nbOgV6PGAOpHHOw6o6JK4=.e63283a7-6607-4bc8-ade2-8d49a460be3e@github.com>

On Fri, 25 Mar 2022 21:16:03 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> `x + (con - y)  -> (x - y) + con` is a widely seen pattern; however it is missing in current implementation, which prevents some obvious constant folding from happening, such as `x + (1 - y) + 2` will be not optimized at all, rather than into `x - y + 3`.
>> 
>> This pull request adds this transformation.
>
> Zhiqiang Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge master.
>  - rename test cases.
>  - move tests to existing test classes.
>  - comment out "x+(0-y)" -> "(x-y)" and "(0-y)+x" -> "(x-y)" because they
>    are covered already.
>  - Merge master.
>  - include transformation from (con - y) + x into (x - y) + con and x + (con - y) into (x - y) + con.

src/hotspot/share/opto/addnode.cpp line 314:

> 312:   // Convert x + (con - y) into "(x - y) + con"
> 313:   if (op2 == Op_Sub(bt) && in2->in(1)->Opcode() == Op_ConIL(bt)) {
> 314:     return AddNode::make(phase->transform(SubNode::make(in1, in2->in(2), bt)), in2->in(1), bt);

Both of proposed transformations are similar one in `AddNode::Ideal()` lines 181-214.
There is exception there to avoid transformation if (y+con) could be increment for loop's variable. I wonder if we need the same check here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7795

From psandoz at openjdk.java.net  Tue Mar 29 17:38:49 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 29 Mar 2022 17:38:49 GMT
Subject: RFR: 8282764: AArch64:
 compiler/vectorapi/reshape/TestVectorCastNeon.java failed with incorrect
 result [v2]
In-Reply-To: <tGc05DsOPxV48goBd2BQDYPCzIcyj8E1d4Yb0wp_NyU=.e11269be-1a52-48db-906b-861bf2e54998@github.com>
References: <5s9gVoO8BXDC9k_GYrcMupuP60CgvgvvuTwy6obPZqA=.dbbccd3f-f4f2-404f-a9f5-7b2e110cd84e@github.com>
 <tGc05DsOPxV48goBd2BQDYPCzIcyj8E1d4Yb0wp_NyU=.e11269be-1a52-48db-906b-861bf2e54998@github.com>
Message-ID: <t_HQkYNa7stj1MqIw-I7c1UrMgDPMC6m-VMKexN_wPQ=.4e0f1d3f-add1-4196-80c3-1660593fc846@github.com>

On Tue, 29 Mar 2022 07:43:08 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

>> Vector API long to float conversion operation on NEON converts vector of 2 longs to 2 floats. In current implementation, we convert 2 longs to 2 doubles first and then converts 2 doubles to 2 floats. However, this two-steps conversion may have two roundings, while the expected behavior, conversion from long to float directly, has only one rounding. This will result in inconsistent result. E.g. for the failure test case:
>> 
>> 
>> jshell> long l = 0x561a524000000001L;
>> l ==> 6204361871487664129
>> 
>> jshell> float l2f = (float)l;
>> l2f ==> 6.2043621E18
>> 
>> jshell> float l2d2f = (float)((double)l);
>> l2d2f ==> 6.2043616E18
>> 
>> 
>> Since we don't have NEON instruction to support vector long to float conversion, we fix the codegen by doing it in scalar operation one element by one element.
>> 
>> TEST: vector api jtreg tests passed.
>
> Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment for special value usage.

Java changes are good.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7850

From psandoz at openjdk.java.net  Tue Mar 29 18:08:43 2022
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 29 Mar 2022 18:08:43 GMT
Subject: RFR: 8282162: [vector] Optimize integral vector negation API [v3]
In-Reply-To: <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
 <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com>
Message-ID: <yuwlO9Ou9wivrnXGqjg81FNs9jf7wCa-V3waCp9MC2s=.5a25ea85-fffc-4b2c-8561-2849d5c3b317@github.com>

On Mon, 28 Mar 2022 09:56:22 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE.
>> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern.
>> 
>> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture:
>>   - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation.
>>   - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`.
>> 
>> So with this patch, the following transformations are applied:
>> 
>> For non-masked negation with NEON:
>> 
>>   movi    v16.4s, #0x0
>>   sub v17.4s, v16.4s, v17.4s       ==> neg v17.4s, v17.4s
>> 
>> and with SVE:
>> 
>>   mov z16.s, #0
>>   sub z18.s, z16.s, z17.s          ==> neg z16.s, p7/m, z16.s
>> 
>> For masked negation with NEON:
>> 
>>   movi    v17.4s, #0x1
>>   mvn v19.16b, v18.16b
>>   mov v20.16b, v16.16b             ==>  neg v18.4s, v17.4s
>>   bsl v20.16b, v19.16b, v18.16b         bsl v19.16b, v18.16b, v17.16b
>>   add v19.4s, v20.4s, v17.4s
>>   mov v18.16b, v16.16b
>>   bsl v18.16b, v19.16b, v20.16b
>> 
>> and with SVE:
>> 
>>   mov z16.s, #-1
>>   mov z17.s, #1                    ==> neg z16.s, p0/m, z16.s
>>   eor z18.s, p0/m, z18.s, z16.s
>>   add z18.s, p0/m, z18.s, z17.s
>> 
>> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed):
>> 
>> NEON:
>> Benchmark                Gain
>> Byte128Vector.NEG        1.029
>> Byte128Vector.NEGMasked  1.757
>> Short128Vector.NEG       1.041
>> Short128Vector.NEGMasked 1.659
>> Int128Vector.NEG         1.005
>> Int128Vector.NEGMasked   1.513
>> Long128Vector.NEG        1.003
>> Long128Vector.NEGMasked  1.878
>> 
>> SVE with 512-bits:
>> Benchmark                Gain
>> ByteMaxVector.NEG        1.10
>> ByteMaxVector.NEGMasked  1.165
>> ShortMaxVector.NEG       1.056
>> ShortMaxVector.NEGMasked 1.195
>> IntMaxVector.NEG         1.002
>> IntMaxVector.NEGMasked   1.239
>> LongMaxVector.NEG        1.031
>> LongMaxVector.NEGMasked  1.191
>> 
>> X86 (non AVX-512):
>> Benchmark                Gain
>> ByteMaxVector.NEGMasked  1.254
>> ShortMaxVector.NEGMasked 1.359
>> IntMaxVector.NEGMasked   1.431
>> LongMaxVector.NEGMasked  1.989
>> 
>> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make "degenerate_vector_integral_negate" to be "NegVI" private

Java changes are good.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7782

From Divino.Cesar at microsoft.com  Tue Mar 29 18:45:46 2022
From: Divino.Cesar at microsoft.com (Cesar Soares Lucas)
Date: Tue, 29 Mar 2022 18:45:46 +0000
Subject: Regarding contributing for JDK-8282024
In-Reply-To: <b31a7581-16b1-3711-674f-c752416c13bb@oracle.com>
References: <CADRELN9r69QnKSEwx=Bcy9nr1tTDPuh1JR+OR7i6Pkc+BvHDFQ@mail.gmail.com>
 <ebe27eb1-3790-93ed-8049-b4061a017ce7@oracle.com>
 <b31a7581-16b1-3711-674f-c752416c13bb@oracle.com>
Message-ID: <BY5PR21MB14738AB47778CB8AE91BBC659A1E9@BY5PR21MB1473.namprd21.prod.outlook.com>

Hi Nithin,

Tobias is correct, there is a member of my team that already have a PR ready for this work item. They?re going to make it public the next few days.


Regards,
Cesar

From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
Date: Thursday, March 24, 2022 at 10:14 AM
To: Nithin Kashyap <nitinkashyapa at gmail.com>, hotspot-compiler-dev at openjdk.java.net <hotspot-compiler-dev at openjdk.java.net>
Cc: Cesar Soares Lucas <Divino.Cesar at microsoft.com>
Subject: Re: Regarding contributing for JDK-8282024
Nithin, please also follow [1] process to become OpenJDK contributor if you did not do it yet.

Thanks,
Vladimir K

[1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fcontribute%2F&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cc395456aad6a4bfbae5908da0db9b90c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637837388574120945%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=SqQ4Td7a9J6j4mOYubIEgZB996QJ0RK%2FIfuJ7etUHho%3D&amp;reserved=0

On 3/24/22 4:29 AM, Tobias Hartmann wrote:
> Hi Nithin,
>
> 8282024 is currently assigned to Cesar and from the comments it looks like as if he has a prototype
> ready. Please sync up with him before starting any work.
>
> Thanks,
> Tobias
>
>
> On 23.03.22 09:02, Nithin Kashyap wrote:
>> Hi
>>
>> This is my first time trying to contribute on the OpenJDK and I picked the
>> starter bug https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8282024&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cc395456aad6a4bfbae5908da0db9b90c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637837388574120945%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=xa4oTU4t3PmXDHhULd%2FWD7Cj0aksTYuZ9KStL1fn6co%3D&amp;reserved=0, Wanted to
>> contribute on this, if someone is actively contributing I can help them.
>> Please Let me know about this.
>>
>> Thanks and Regards
>> Nithin

From kvn at openjdk.java.net  Tue Mar 29 20:27:56 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 29 Mar 2022 20:27:56 GMT
Subject: RFR: 8183390: Fix and re-enable post loop vectorization [v6]
In-Reply-To: <4f4q-PLj6psH50mRQCVLAX8bMjzF4XWzAornt_t4PNE=.4331b19d-469b-4e0d-8a1f-d1eeb5aaf9ed@github.com>
References: <M1ojlBqpMKuAC-oAJdp1JC5vgvzhdkxjnJmTaX0v4sI=.932c9d8d-9663-4e7b-9deb-a88d54cc72bc@github.com>
 <4f4q-PLj6psH50mRQCVLAX8bMjzF4XWzAornt_t4PNE=.4331b19d-469b-4e0d-8a1f-d1eeb5aaf9ed@github.com>
Message-ID: <gLf71z-1YP0DLYGhVKPzwjXFO-BfomIfjRDJctbXctk=.61f15fdb-3533-46a2-86a9-af6dfef2e724@github.com>

On Mon, 14 Mar 2022 06:13:30 GMT, Pengfei Li <pli at openjdk.org> wrote:

>> ### Background
>> 
>> Post loop vectorization is a C2 compiler optimization in an experimental
>> VM feature called PostLoopMultiversioning. It transforms the range-check
>> eliminated post loop to a 1-iteration vectorized loop with vector mask.
>> This optimization was contributed by Intel in 2016 to support x86 AVX512
>> masked vector instructions. However, it was disabled soon after an issue
>> was found. Due to insufficient maintenance in these years, multiple bugs
>> have been accumulated inside. But we (Arm) still think this is a useful
>> framework for vector mask support in C2 auto-vectorized loops, for both
>> x86 AVX512 and AArch64 SVE. Hence, we propose this to fix and re-enable
>> post loop vectorization.
>> 
>> ### Changes in this patch
>> 
>> This patch reworks post loop vectorization. The most significant change
>> is removing vector mask support in C2 x86 backend and re-implementing
>> it in the mid-end. With this, we can re-enable post loop vectorization
>> for platforms other than x86.
>> 
>> Previous implementation hard-codes x86 k1 register as a reserved AVX512
>> opmask register and defines two routines (setvectmask/restorevectmask)
>> to set and restore the value of k1. But after [JDK-8211251](https://bugs.openjdk.java.net/browse/JDK-8211251) which encodes
>> AVX512 instructions as unmasked by default, generated vector masks are
>> no longer used in AVX512 vector instructions. To fix incorrect codegen
>> and add vector mask support for more platforms, we turn to add a vector
>> mask input to C2 mid-end IRs. Specifically, we use a VectorMaskGenNode
>> to generate a mask and replace all Load/Store nodes in the post loop
>> into LoadVectorMasked/StoreVectorMasked nodes with that mask input. This
>> IR form is exactly the same to those which are used in VectorAPI mask
>> support. For now, we only add mask inputs for Load/Store nodes because
>> we don't have reduction operations supported in post loop vectorization.
>> After this change, the x86 k1 register is no longer reserved and can be
>> allocated when PostLoopMultiversioning is enabled.
>> 
>> Besides this change, we have fixed a compiler crash and five incorrect
>> result issues with post loop vectorization.
>> 
>> **I) C2 crashes with segmentation fault in strip-mined loops**
>> 
>> Previous implementation was done before C2 loop strip-mining was merged
>> into JDK master so it didn't take strip-mined loops into consideration.
>> In C2's strip mined loops, post loop is not the sibling of the main loop
>> in ideal loop tree. Instead, it's the sibling of the main loop's parent.
>> This patch fixed a SIGSEGV issue caused by NULL pointer when locating
>> post loop from strip-mined main loop.
>> 
>> **II) Incorrect result issues with post loop vectorization**
>> 
>> We have also fixed five incorrect vectorization issues. Some of them are
>> hidden deep and can only be reproduced with corner cases. These issues
>> have a common cause that it assumes the post loop can be vectorized if
>> the vectorization in corresponding main loop is successful. But in many
>> cases this assumption is wrong. Below are details.
>> 
>> - **[Issue-1] Incorrect vectorization for partial vectorizable loops**
>> 
>> This issue can be reproduced by below loop where only some operations in
>> the loop body are vectorizable.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     res[i] = a[i] * b[i];
>>     k = 3 * k + 1;
>>   }
>> 
>> In the main loop, superword can work well if parts of the operations in
>> loop body are not vectorizable since those parts can be unrolled only.
>> But for post loops, we don't create vectors through combining scalar IRs
>> generated from loop unrolling. Instead, we are doing scalars to vectors
>> replacement for all operations in the loop body. Hence, all operations
>> should be either vectorized together or not vectorized at all. To fix
>> this kind of cases, we add an extra field "_slp_vector_pack_count" in
>> CountedLoopNode to record the eventual count of vector packs in the main
>> loop. This value is then passed to post loop and compared with post loop
>> pack count. Vectorization will be bailed out in post loop if it creates
>> more vector packs than in the main loop.
>> 
>> - **[Issue-2] Incorrect result in loops with growing-down vectors**
>> 
>> This issue appears with growing-down vectors, that is, vectors that grow
>> to smaller memory address as the loop iterates. It can be reproduced by
>> below counting-up loop with negative scale value in array index.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     a[MAX - i] = b[MAX - i];
>>   }
>> 
>> Cause of this issue is that for a growing-down vector, generated vector
>> mask value has reversed vector-lane order so it masks incorrect vector
>> lanes. Note that if negative scale value appears in counting-down loops,
>> the vector will be growing up. With this rule, we fix the issue by only
>> allowing positive array index scales in counting-up loops and negative
>> array index scales in counting-down loops. This check is done with the
>> help of SWPointer by comparing scale values in each memory access in the
>> loop with loop stride value.
>> 
>> - **[Issue-3] Incorrect result in manually unrolled loops**
>> 
>> This issue can be reproduced by below manually unrolled loop.
>> 
>>   for (int i = 0; i < 10000; i += 2) {
>>     c[i] = a[i] + b[i];
>>     c[i + 1] = a[i + 1] * b[i + 1];
>>   }
>> 
>> In this loop, operations in the 2nd statement duplicate those in the 1st
>> statement with a small memory address offset. Vectorization in the main
>> loop works well in this case because C2 does further unrolling and pack
>> combination. But we cannot vectorize the post loop through replacement
>> from scalars to vectors because it creates duplicated vector operations.
>> To fix this, we restrict post loop vectorization to loops with stride
>> values of 1 or -1.
>> 
>> - **[Issue-4] Incorrect result in loops with mixed vector element sizes**
>> 
>> This issue is found after we enable post loop vectorization for AArch64.
>> It's reproducible by multiple array operations with different element
>> sizes inside a loop. On x86, there is no issue because the values of x86
>> AVX512 opmasks only depend on which vector lanes are active. But AArch64
>> is different - the values of SVE predicates also depend on lane size of
>> the vector. Hence, on AArch64 SVE, if a loop has mixed vector element
>> sizes, we should use different vector masks. For now, we just support
>> loops with only one vector element size, i.e., "int + float" vectors in
>> a single loop is ok but "int + double" vectors in a single loop is not
>> vectorizable. This fix also enables subword vectors support to make all
>> primitive type array operations vectorizable.
>> 
>> - **[Issue-5] Incorrect result in loops with potential data dependence**
>> 
>> This issue can be reproduced by below corner case on AArch64 only.
>> 
>>   for (int i = 0; i < 10000; i++) {
>>     a[i] = x;
>>     a[i + OFFSET] = y;
>>   }
>> 
>> In this case, two stores in the loop have data dependence if the OFFSET
>> value is smaller than the vector length. So we cannot do vectorization
>> through replacing scalars to vectors. But the main loop vectorization
>> in this case is successful on AArch64 because AArch64 has partial vector
>> load/store support. It splits vector fill with different values in lanes
>> to several smaller-sized fills. In this patch, we add additional data
>> dependence check for this kind of cases. The check is also done with the
>> help of SWPointer class. In this check, we require that every two memory
>> accesses (with at least one store) of the same element type (or subword
>> size) in the loop has the same array index expression.
>> 
>> ### Tests
>> 
>> So far we have tested full jtreg on both x86 AVX512 and AArch64 SVE with
>> experimental VM option "PostLoopMultiversioning" turned on. We found no
>> issue in all tests. We notice that those existing cases are not enough
>> because some of above issues are not spotted by them. We would like to
>> add some new cases but we found existing vectorization tests are a bit
>> cumbersome - golden results must be pre-calculated and hard-coded in the
>> test code for correctness verification. Thus, in this patch, we propose
>> a new vectorization testing framework.
>> 
>> Our new framework brings a simpler way to add new cases. For a new test
>> case, we only need to create a new method annotated with "@Test". The
>> test runner will invoke each annotated method twice automatically. First
>> time it runs in the interpreter and second time it's forced compiled by
>> C2. Then the two return results are compared. So in this framework each
>> test method should return a primitive value or an array of primitives.
>> In this way, no extra verification code for vectorization correctness is
>> required. This test runner is still jtreg-based and takes advantages of
>> the jtreg WhiteBox API, which enables test methods running at specific
>> compilation levels. Each test class inside is also jtreg-based. It just
>> need to inherit from the test runner class and run with two additional
>> options "-Xbootclasspath/a:." and "-XX:+WhiteBoxAPI".
>> 
>> ### Summary & Future work
>> 
>> In this patch, we reworked post loop vectorization. We made it platform
>> independent and fixed several issues inside. We also implemented a new
>> vectorization testing framework with many test cases inside. Meanwhile,
>> we did some code cleanups.
>> 
>> This patch only touches C2 code guarded with PostLoopMultiversioning,
>> except a few data structure changes. So, there's no behavior change when
>> experimental VM option PostLoopMultiversioning is off. Also, to reduce
>> risks, we still propose to keep post loop vectorization experimental for
>> now. But if it receives positive feedback, we would like to change it to
>> non-experimental in the future.
>
> Pengfei Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update a few comments

Nice work. I have few comments.

src/hotspot/share/opto/superword.cpp line 2754:

> 2752:       swptrs.append(mem_p);
> 2753:     }
> 2754:     assert(is_java_primitive(bt), "only primitive types are allowed in post loop");

Should this be check to bailout instead of assert? Before `(n->is_Mem())` check.

src/hotspot/share/opto/superword.cpp line 2774:

> 2772:   if (unique_size * vlen != MaxVectorSize) {
> 2773:     return NULL;
> 2774:   }

Why not smaller than MaxVectorSize?  I don't think SuperWord guarantee that vectors in main loop are equal to MaxVectorSize.
Or this is simply restriction to simplify optimization?

src/hotspot/share/opto/superword.cpp line 2791:

> 2789:   // vector drain loop which is cloned from main loop before super-unrolling
> 2790:   // so the scalar post loop runs at most vlen-1 trips. Hence, this version
> 2791:   // only runs at most 1 iteration after vector mask transformation.

Where is the check that `cl->is_rce_post_loop()` runs only `vlen-1` trips?

src/hotspot/share/opto/superword.cpp line 2806:

> 2804:   Node* offset = new ConvI2LNode(trip_cnt);
> 2805:   _igvn.register_new_node_with_optimizer(offset);
> 2806:   Node* vmask = VectorMaskGenNode::make(offset, vmask_bt);

I think `offset` should be `length` here.

src/hotspot/share/opto/superword.hpp line 249:

> 247: // -------------------------VectorLaneSizeStats-------------------------
> 248: // Vector lane size statistics for loop vectorization with vector masks
> 249: class VectorLaneSizeStats {

Can you rename `Lane` to `Element` which what we use in other places in HotSpot?

-------------

PR: https://git.openjdk.java.net/jdk/pull/6828

From duke at openjdk.java.net  Tue Mar 29 20:49:48 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Tue, 29 Mar 2022 20:49:48 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con [v5]
In-Reply-To: <5tI1VxHY4Gh-mmsvS3WFF0nbOgV6PGAOpHHOw6o6JK4=.e63283a7-6607-4bc8-ade2-8d49a460be3e@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
 <eDPR1Pnhl7pkWG3Epsc2X4sQWfOOPloJmZd9wy1SxLA=.8d7572bf-0a91-4c56-bb6a-ff580d6979e0@github.com>
 <5tI1VxHY4Gh-mmsvS3WFF0nbOgV6PGAOpHHOw6o6JK4=.e63283a7-6607-4bc8-ade2-8d49a460be3e@github.com>
Message-ID: <9n9hnX7jdL_82OePnlU4x1CUmvOYHI7jLDoPoiWTB1Q=.55c29b95-062b-4382-8d28-44679482916c@github.com>

On Tue, 29 Mar 2022 17:23:37 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Zhiqiang Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge master.
>>  - rename test cases.
>>  - move tests to existing test classes.
>>  - comment out "x+(0-y)" -> "(x-y)" and "(0-y)+x" -> "(x-y)" because they
>>    are covered already.
>>  - Merge master.
>>  - include transformation from (con - y) + x into (x - y) + con and x + (con - y) into (x - y) + con.
>
> src/hotspot/share/opto/addnode.cpp line 314:
> 
>> 312:   // Convert x + (con - y) into "(x - y) + con"
>> 313:   if (op2 == Op_Sub(bt) && in2->in(1)->Opcode() == Op_ConIL(bt)) {
>> 314:     return AddNode::make(phase->transform(SubNode::make(in1, in2->in(2), bt)), in2->in(1), bt);
> 
> Both of proposed transformations are similar one in `AddNode::Ideal()` lines 181-214.
> There is exception there to avoid transformation if (y+con) could be increment for loop's variable. I wonder if we need the same check here.

Thanks for reviewing! That is indeed an interesting observation. I feel `con - y` could not be a loop increment so it should be sufficient to check `x` is not a loop induction variable?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7795

From kvn at openjdk.java.net  Tue Mar 29 20:59:42 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 29 Mar 2022 20:59:42 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con [v5]
In-Reply-To: <9n9hnX7jdL_82OePnlU4x1CUmvOYHI7jLDoPoiWTB1Q=.55c29b95-062b-4382-8d28-44679482916c@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
 <eDPR1Pnhl7pkWG3Epsc2X4sQWfOOPloJmZd9wy1SxLA=.8d7572bf-0a91-4c56-bb6a-ff580d6979e0@github.com>
 <5tI1VxHY4Gh-mmsvS3WFF0nbOgV6PGAOpHHOw6o6JK4=.e63283a7-6607-4bc8-ade2-8d49a460be3e@github.com>
 <9n9hnX7jdL_82OePnlU4x1CUmvOYHI7jLDoPoiWTB1Q=.55c29b95-062b-4382-8d28-44679482916c@github.com>
Message-ID: <iOvYK5J2dAo6EFT_q_QZ2mgVUUGa0oeKHzjLlQeSVFI=.b1d5f09f-7ff6-4d8a-92ff-29eac8b2f891@github.com>

On Tue, 29 Mar 2022 20:46:31 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

>> src/hotspot/share/opto/addnode.cpp line 314:
>> 
>>> 312:   // Convert x + (con - y) into "(x - y) + con"
>>> 313:   if (op2 == Op_Sub(bt) && in2->in(1)->Opcode() == Op_ConIL(bt)) {
>>> 314:     return AddNode::make(phase->transform(SubNode::make(in1, in2->in(2), bt)), in2->in(1), bt);
>> 
>> Both of proposed transformations are similar one in `AddNode::Ideal()` lines 181-214.
>> There is exception there to avoid transformation if (y+con) could be increment for loop's variable. I wonder if we need the same check here.
>
> Thanks for reviewing! That is indeed an interesting observation. I feel `con - y` could not be a loop increment so it should be sufficient to check `x` is not a loop induction variable?

I think we need to check `y`. For example:


for (int i = 0; i < 10000; i++) {
    a[MAX - i] = b[MAX - i];
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/7795

From duke at openjdk.java.net  Tue Mar 29 21:09:46 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Tue, 29 Mar 2022 21:09:46 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con [v5]
In-Reply-To: <iOvYK5J2dAo6EFT_q_QZ2mgVUUGa0oeKHzjLlQeSVFI=.b1d5f09f-7ff6-4d8a-92ff-29eac8b2f891@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
 <eDPR1Pnhl7pkWG3Epsc2X4sQWfOOPloJmZd9wy1SxLA=.8d7572bf-0a91-4c56-bb6a-ff580d6979e0@github.com>
 <5tI1VxHY4Gh-mmsvS3WFF0nbOgV6PGAOpHHOw6o6JK4=.e63283a7-6607-4bc8-ade2-8d49a460be3e@github.com>
 <9n9hnX7jdL_82OePnlU4x1CUmvOYHI7jLDoPoiWTB1Q=.55c29b95-062b-4382-8d28-44679482916c@github.com>
 <iOvYK5J2dAo6EFT_q_QZ2mgVUUGa0oeKHzjLlQeSVFI=.b1d5f09f-7ff6-4d8a-92ff-29eac8b2f891@github.com>
Message-ID: <7YDBYN1qMPRnQo4PfuIFqjVVu2pdg3HP6sItp8IVcZ4=.6ba73e62-1bd0-497e-a93c-7cc76033a2b1@github.com>

On Tue, 29 Mar 2022 20:56:02 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Thanks for reviewing! That is indeed an interesting observation. I feel `con - y` could not be a loop increment so it should be sufficient to check `x` is not a loop induction variable?
>
> I think we need to check `y`. For example:
> 
> 
> for (int i = 0; i < 10000; i++) {
>     a[MAX - i] = b[MAX - i];
> }

But in this case it seems OK to me to make the transformation, for example:

for (int i = 0; i < 10000; i++) {
    a[x + (MAX - i)] = b[x + (MAX - i)]; // a[(x - i) + MAX] = b[(x - i) + MAX]
}

Is there something I overlooked?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7795

From kvn at openjdk.java.net  Tue Mar 29 22:00:46 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 29 Mar 2022 22:00:46 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con [v5]
In-Reply-To: <7YDBYN1qMPRnQo4PfuIFqjVVu2pdg3HP6sItp8IVcZ4=.6ba73e62-1bd0-497e-a93c-7cc76033a2b1@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
 <eDPR1Pnhl7pkWG3Epsc2X4sQWfOOPloJmZd9wy1SxLA=.8d7572bf-0a91-4c56-bb6a-ff580d6979e0@github.com>
 <5tI1VxHY4Gh-mmsvS3WFF0nbOgV6PGAOpHHOw6o6JK4=.e63283a7-6607-4bc8-ade2-8d49a460be3e@github.com>
 <9n9hnX7jdL_82OePnlU4x1CUmvOYHI7jLDoPoiWTB1Q=.55c29b95-062b-4382-8d28-44679482916c@github.com>
 <iOvYK5J2dAo6EFT_q_QZ2mgVUUGa0oeKHzjLlQeSVFI=.b1d5f09f-7ff6-4d8a-92ff-29eac8b2f891@github.com>
 <7YDBYN1qMPRnQo4PfuIFqjVVu2pdg3HP6sItp8IVcZ4=.6ba73e62-1bd0-497e-a93c-7cc76033a2b1@github.com>
Message-ID: <woo_Up7h21ePVElETGmFn5NGi2p4KH4c-kPQQEPFJ18=.4d99be80-da36-43e9-a4be-fe2cdf25aecd@github.com>

On Tue, 29 Mar 2022 21:06:40 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

>> I think we need to check `y`. For example:
>> 
>> 
>> for (int i = 0; i < 10000; i++) {
>>     a[MAX - i] = b[MAX - i];
>> }
>
> But in this case it seems OK to me to make the transformation, for example:
> 
> for (int i = 0; i < 10000; i++) {
>     a[x + (MAX - i)] = b[x + (MAX - i)]; // a[(x - i) + MAX] = b[(x - i) + MAX]
> }
> 
> Is there something I overlooked?

In loopopts (and superword) we are loking for `(+-phi  +- const)` pattern for loop variable.
With your transformation we get `((+-phi +- x) + const)` which may prevent some optimizations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7795

From dlong at openjdk.java.net  Tue Mar 29 22:15:43 2022
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 29 Mar 2022 22:15:43 GMT
Subject: RFR: 8283494: Factor out calculation of actual number of XMM
 registers
In-Reply-To: <VWzCeBhLgEcnxHs1YZ73N3w2i5G3JcJwIR_jx9HiKls=.0e645b29-1809-4f05-950b-eecabc46010f@github.com>
References: <VWzCeBhLgEcnxHs1YZ73N3w2i5G3JcJwIR_jx9HiKls=.0e645b29-1809-4f05-950b-eecabc46010f@github.com>
Message-ID: <KS-Tsmwa-5Zh15_095SVyRQWyq1NrYUx-qwnkPkp0sU=.997ed753-5674-4cf7-ac4d-75573e85b3db@github.com>

On Wed, 23 Mar 2022 08:52:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that factors out calculation of the actually available number of XMM registers on a given processor/given command line options into a method and reuse that as much as possible?
> 
> This relates to this code snippet:
> 
>       int xmm_bypass_limit = FrameMap::nof_xmm_regs;
> #ifdef _LP64
>       if (UseAVX < 3) {
>         xmm_bypass_limit = xmm_bypass_limit / 2;
>       }
> #endif
> 
> 
> Also, there is already the method `FrameMap::get_num_caller_save_xmms()` that has been updated to use that new method `XMMRegisterImpl::available_xmm_registers()`; further I tried to appropriately use `FrameMap::get_num_caller_save_xmms` in the places where either would work. Please have a look in particular about that.
> 
> I did not change strange to me variable names like `xmm_bypass_limit` above as they probably make some sense to somebody as it's used quite often.
> 
> This also fixes a compilation error without configuring C1 introduced with [JDK-8283327](https://bugs.openjdk.java.net/browse/JDK-8283327).
> 
> Testing: tier1-5 (all but linux-aarch64 done), gha, local compilation with `configure --with-features=-compiler1`.
> 
> Thanks,
>   Thomas

LGTM.

-------------

Marked as reviewed by dlong (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7917

From kvn at openjdk.java.net  Tue Mar 29 23:07:18 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 29 Mar 2022 23:07:18 GMT
Subject: RFR: 8283494: Factor out calculation of actual number of XMM
 registers
In-Reply-To: <VWzCeBhLgEcnxHs1YZ73N3w2i5G3JcJwIR_jx9HiKls=.0e645b29-1809-4f05-950b-eecabc46010f@github.com>
References: <VWzCeBhLgEcnxHs1YZ73N3w2i5G3JcJwIR_jx9HiKls=.0e645b29-1809-4f05-950b-eecabc46010f@github.com>
Message-ID: <v2lh4gzUyt7UDCFJZS9HuF4s_yzJzaI3suRkTTXSsYg=.3b7647f4-5a2d-43a7-8bd1-fcde8075a2ca@github.com>

On Wed, 23 Mar 2022 08:52:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that factors out calculation of the actually available number of XMM registers on a given processor/given command line options into a method and reuse that as much as possible?
> 
> This relates to this code snippet:
> 
>       int xmm_bypass_limit = FrameMap::nof_xmm_regs;
> #ifdef _LP64
>       if (UseAVX < 3) {
>         xmm_bypass_limit = xmm_bypass_limit / 2;
>       }
> #endif
> 
> 
> Also, there is already the method `FrameMap::get_num_caller_save_xmms()` that has been updated to use that new method `XMMRegisterImpl::available_xmm_registers()`; further I tried to appropriately use `FrameMap::get_num_caller_save_xmms` in the places where either would work. Please have a look in particular about that.
> 
> I did not change strange to me variable names like `xmm_bypass_limit` above as they probably make some sense to somebody as it's used quite often.
> 
> This also fixes a compilation error without configuring C1 introduced with [JDK-8283327](https://bugs.openjdk.java.net/browse/JDK-8283327).
> 
> Testing: tier1-5 (all but linux-aarch64 done), gha, local compilation with `configure --with-features=-compiler1`.
> 
> Thanks,
>   Thomas

I thought I commented on this already but I can't find record.
Looks good. I have only one comment.

src/hotspot/cpu/x86/register_x86.hpp line 169:

> 167:   // Actually available XMM registers for use, depending on actual CPU capabilities
> 168:   // and flags.
> 169:   static int available_xmm_registers();

Why not define function's  body here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7917

From duke at openjdk.java.net  Tue Mar 29 23:21:37 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Tue, 29 Mar 2022 23:21:37 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con [v6]
In-Reply-To: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
Message-ID: <ljjKweEd2DZXi4rPoRR2LaMvVMW-D4yq_eNS4238ihg=.8c07a986-c97a-4bc0-b58b-20cd5054067c@github.com>

> Hello,
> 
> `x + (con - y)  -> (x - y) + con` is a widely seen pattern; however it is missing in current implementation, which prevents some obvious constant folding from happening, such as `x + (1 - y) + 2` will be not optimized at all, rather than into `x - y + 3`.
> 
> This pull request adds this transformation.

Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:

  do not transform for loop induction variable.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7795/files
  - new: https://git.openjdk.java.net/jdk/pull/7795/files/e9951dda..00b79922

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7795&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7795&range=04-05

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7795/head:pull/7795

PR: https://git.openjdk.java.net/jdk/pull/7795

From duke at openjdk.java.net  Tue Mar 29 23:21:37 2022
From: duke at openjdk.java.net (Zhiqiang Zang)
Date: Tue, 29 Mar 2022 23:21:37 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con [v5]
In-Reply-To: <woo_Up7h21ePVElETGmFn5NGi2p4KH4c-kPQQEPFJ18=.4d99be80-da36-43e9-a4be-fe2cdf25aecd@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
 <eDPR1Pnhl7pkWG3Epsc2X4sQWfOOPloJmZd9wy1SxLA=.8d7572bf-0a91-4c56-bb6a-ff580d6979e0@github.com>
 <5tI1VxHY4Gh-mmsvS3WFF0nbOgV6PGAOpHHOw6o6JK4=.e63283a7-6607-4bc8-ade2-8d49a460be3e@github.com>
 <9n9hnX7jdL_82OePnlU4x1CUmvOYHI7jLDoPoiWTB1Q=.55c29b95-062b-4382-8d28-44679482916c@github.com>
 <iOvYK5J2dAo6EFT_q_QZ2mgVUUGa0oeKHzjLlQeSVFI=.b1d5f09f-7ff6-4d8a-92ff-29eac8b2f891@github.com>
 <7YDBYN1qMPRnQo4PfuIFqjVVu2pdg3HP6sItp8IVcZ4=.6ba73e62-1bd0-497e-a93c-7cc76033a2b1@github.com>
 <woo_Up7h21ePVElETGmFn5NGi2p4KH4c-kPQQEPFJ18=.4d99be80-da36-43e9-a4be-fe2cdf25aecd@github.com>
Message-ID: <_HhE4o8zQuzKUX2aF07vh8W4g8l7n8tSYmHrL6cPg8c=.cb89a2eb-7a29-4c08-9c2f-36bc37d24ddf@github.com>

On Tue, 29 Mar 2022 21:57:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> But in this case it seems OK to me to make the transformation, for example:
>> 
>> for (int i = 0; i < 10000; i++) {
>>     a[x + (MAX - i)] = b[x + (MAX - i)]; // a[(x - i) + MAX] = b[(x - i) + MAX]
>> }
>> 
>> Is there something I overlooked?
>
> In loopopts (and superword) we are loking for `(+-phi  +- const)` pattern for loop variable.
> With your transformation we get `((+-phi +- x) + const)` which may prevent some optimizations.

Makes sense. Thanks for the explanation. I included the check in a new commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7795

From kvn at openjdk.java.net  Tue Mar 29 23:44:59 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 29 Mar 2022 23:44:59 GMT
Subject: RFR: 8283094: Add Ideal transformation: x + (con - y) -> (x - y) +
 con [v6]
In-Reply-To: <ljjKweEd2DZXi4rPoRR2LaMvVMW-D4yq_eNS4238ihg=.8c07a986-c97a-4bc0-b58b-20cd5054067c@github.com>
References: <k4MBp_wDSrzdTdLPVFkos8BmB9SfNYWjbpwPrGCWVsI=.519426ab-a6fa-4a00-a996-3dbc8fb046f1@github.com>
 <ljjKweEd2DZXi4rPoRR2LaMvVMW-D4yq_eNS4238ihg=.8c07a986-c97a-4bc0-b58b-20cd5054067c@github.com>
Message-ID: <dgCV4ZG1NYXxpN3DDvFY-Hr9UJF_4FkgR9i0jFe83X4=.e5e031a4-7cfe-4b95-b6b5-3da0a316f405@github.com>

On Tue, 29 Mar 2022 23:21:37 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

>> Hello,
>> 
>> `x + (con - y)  -> (x - y) + con` is a widely seen pattern; however it is missing in current implementation, which prevents some obvious constant folding from happening, such as `x + (1 - y) + 2` will be not optimized at all, rather than into `x - y + 3`.
>> 
>> This pull request adds this transformation.
>
> Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do not transform for loop induction variable.

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7795

From Divino.Cesar at microsoft.com  Wed Mar 30 00:34:42 2022
From: Divino.Cesar at microsoft.com (Cesar Soares Lucas)
Date: Wed, 30 Mar 2022 00:34:42 +0000
Subject: [External] : Re: RFC : Approach to handle Allocation Merges in C2
 Scalar Replacement
In-Reply-To: <cbe335c5-7fb5-ce01-d113-c098f9b6a6b6@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
 <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
 <806f2baa-9b48-e57a-d153-0a19fc3e709d@oracle.com>
 <BY5PR21MB14735BCBF26C72B09051613E9A379@BY5PR21MB1473.namprd21.prod.outlook.com>
 <3cd5e4b1-5a0e-28ef-2445-1bf65fca4422@oracle.com>
 <BY5PR21MB147353D5267885877DFB47D79A3B9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <BY5PR21MB1473482D25CF302438F83A289A129@BY5PR21MB1473.namprd21.prod.outlook.com>
 <cbe335c5-7fb5-ce01-d113-c098f9b6a6b6@oracle.com>
Message-ID: <DM6PR21MB148490B67DC149401571356E9A1F9@DM6PR21MB1484.namprd21.prod.outlook.com>

Hi, Vladimir.

Thank you for getting back to me. What you describe is exactly what I understand and what I tried to implement. I also noticed the issue with the nodes floating up and I even tried to prevent that.. but I think the root of the problem is somewhere else.

Please take a look at this printout: https://www.dropbox.com/s/ao30zadovwqswlp/splitted.txt?dl=0 . C2 tells me that this graph has bad dominance: ?Use 228 isn?t dominated by def 231?. This error message is result of this verification: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L5361

I agree and disagree with the message. I?m not sure if it?s my limited knowledge of C2 IR or some wording problem in the message: why would 228 need to be dominated by 231 - after all 228 doesn?t use 231? The opposite makes more sense to me: 228 needs to dominate 231 ? and that is true AFAICT. Nonetheless, I agree with the message that there is something wrong in the graph: this graph allows for execution to reach node 231 without node 124 being executed!

I created this DRAFT PR so that you can look at the code if you want: https://github.com/openjdk/jdk/pull/8023 .

Please let me know what you think. TIA!
Cesar


From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
Date: Monday, March 28, 2022 at 10:48 AM
To: Cesar Soares Lucas <Divino.Cesar at microsoft.com>, Vladimir Ivanov <vladimir.x.ivanov at oracle.com>, hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
Cc: Brian Stafford <Brian.Stafford at microsoft.com>, Martijn Verburg <Martijn.Verburg at microsoft.com>
Subject: Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
Hi Cesar

On 3/17/22 12:15 PM, Cesar Soares Lucas wrote:
> Hi all,
>
> I?ve been experimenting with the idea explained by Vladimir Ivanov and I was able to implement it and have a few
> non-trivial merges untangled and scalar replaced. However, I found an obstacle on the road. I was able to overcome it,
> but I?d very much appreciate your opinion about the matter. Assume we start off with the piece of code below.
>
> if (?)     p0 = ?
>
> else       p1 = ?
>
> p = phi(p0, p1)
>
> return p.x
>
> The idea proposed suggests, AFAIU, that we change the code to be something like the below **where we use the bases
> directly**.
>
> if (?)   p0 = ?
>
> else     p1 = ?
>
> s = # selector phi #
>
> if (s == id_base0)           x0 = p0.x
>
> elseif (s == id_base1)    x1 = p1.x
>
> else                                  halt()
>
> x = phi(x0, x1)
>
> return x
>
> The problem here is that the definition of ?p0? and/or ?p1? doesn?t dominate their use in the loads ?x0 = p0.x? / ?x1 =
> p1.x?, therefore certain IR verification steps in C2 fail. I was able to work around the issue by adding Phi nodes where
> all inputs are the same (excluding the ctrl), thus creating a ?fake? definition for the value. Please see code below.

You have original `p = phi(p0, p1)` which is attached to Region node which merges paths with p0 and p1. `Selector ID
Phi(id_p0, id_p1)` should be attached to the same Region and guarantee that p0 and p1 are defined at that point. The
only issue could be is that load nodes don't have control edges and depend on memory edges to schedule. So they could
float up. I think they should be attached (control edge) to id checks (s == id_base*) to prevent them move up as new
special case [1]. At least as first approach for experiment.

Thanks,
Vladimir K

[1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2Fmaster%2Fsrc%2Fhotspot%2Fshare%2Fopto%2Fmemnode.cpp%23L1737&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd6152056b06744f7359e08da10e33a44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637840865379084345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HaPBCqckab%2BpOcIoYEccL04u1o1pqqaUjsYMCslfP7Y%3D&amp;reserved=0

>
> if (?)   p0 = ?
>
> else     p1 = ?
>
> phi0 = phi(p0, p0)
>
> phi1 = Phi(p1, p1)
>
> s = # selector phi #
>
> if (s == id_base0)           x0 = phi0.x
>
> elseif (s == id_base1)    x1 = phi1.x
>
> else                                  halt()
>
> x = phi(x0, x1)
>
> return x
>
> Transforming the code to look like the above silenced the verifications ( :-] ) and at the end EA+SR was able to remove
> the allocations **and get rid of all the Phi?s**.
>
> So, my question is: is this workaround acceptable? Do you have a suggestion of a better solution?
>
> TIA, Cesar
>
> *From: *hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.java.net> on behalf of Cesar Soares Lucas
> <Divino.Cesar at microsoft.com>
> *Date: *Tuesday, February 22, 2022 at 10:01 AM
> *To: *Vladimir Ivanov <vladimir.x.ivanov at oracle.com>, Vladimir Kozlov <vladimir.kozlov at oracle.com>, hotspot compiler
> <hotspot-compiler-dev at openjdk.java.net>
> *Cc: *Brian Stafford <Brian.Stafford at microsoft.com>, Martijn Verburg <Martijn.Verburg at microsoft.com>
> *Subject: *Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>
> Hi Vladimir,
>
> I think I've enough feedback to start working on a prototype and see how things play out. Thank you for sharing your
> ideas/expertise!
>
>
> Cheers,
> Cesar
>
> ________________________________________
> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> Sent: February 21, 2022 10:26 AM
> To: Cesar Soares Lucas; Vladimir Kozlov; hotspot compiler
> Cc: Brian Stafford; Martijn Verburg
> Subject: Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>
> Hi Cesar,
>
>> I with the selector-based base splitting idea using some examples and I think I understand the mechanics well. It's conceptually simple and quite effective, I like it! I've another question, though. From your previous message I had understood that we needed  the clustering because split_unique_types can't handle multiple bases at once, which makes sense to me. _This time I
> don't understand why we need to do the clustering before doing the selector-based transformation_. AFAIU this
> transformation won't be creating any memory slices but rather just assigning IDs to different bases and then creating
> specialized memory operations conditionally using the different bases.
>
> Yes, that's a valid simplification. It does sound like introducing
> selector ID doesn't require a separate memory graph (and can be
> performed before split_unique_types()), but I don't have a good
> understanding how complicated simplifying selector-based IR shapes would
> be compared to original (memory op-based) ones. It's definitely worth
> experimenting with.
>
> Best regards,
> Vladimir Ivanov
>
>> ________________________________________
>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>> Sent: February 17, 2022 7:37 AM
>> To: Vladimir Kozlov; Cesar Soares Lucas; hotspot compiler
>> Cc: Brian Stafford; Martijn Verburg
>> Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>
>>
>>> But depending on the actual shape of the base pointer (here it's
>>> Phi(obj1,obj2)), it may become infeasible (from performance perspective)
>>> or even impossible (e.g., for complex loop variant conditions) to
>>> separate instance slices.
>>
>> I'd like to correct myself. After thinking more about the problem, I see
>> a universal way to scalarize clusters of interfering non-escaping
>> allocations even in presence of accesses with indeterminate base.
>>
>> The crucial property for such cluster of interacting non-escaping
>> allocations is for any memory access its base is either part of the
>> cluster or not (it's a static property for every access). Then, when it
>> is part of the cluster, then the number of possible base values at
>> runtime is finite and is a subset of the cluster.
>>
>> So, memory graph for the cluster can be scalarized as follows:
>>
>>     (1) separate memory graph for the cluster
>>
>>     (2) on the newly constructed graph:
>>
>>        (a) replace every base pointer with an ID ("selector id") and
>> recreate data graph for selector IDs from base pointers graph;
>>
>>        (b) for accesses with indeterminate base pointer, replace them
>> with a merge of states from relevant allocations selected by "selector id"
>>
>>        (c) after 2b, all memory accesses from the cluster memory graph
>> should have fixed base pointing at a particular allocation
>>
>>     (3) scalarize individual allocations from the cluster one by one
>> (since they are independent now)
>>
>>        - additional transformation (like, split-through-phi) should
>> simplify the graph by reducing the number of cases at merge points to
>> care about (ideally, leaving only a single one);
>>
>>
>>
>> As an illustration:
>>
>>     val = Load (AddP (Phi R base1 base2) offset) mem # load A.i
>>
>> ==(pseudo-code)==>
>>
>>     selector = (Phi R #base1 #base2)
>>
>>     if (selector == #base1) {
>>       val1 = Load (base1 + offset) mem
>>     } else if (selector == #base2) {
>>       val2 = Load (base2 + offset) mem
>>     } else {
>>       halt(); // impossible
>>     }
>>
>>     val = Phi(R1, val1, val2)
>>
>> ======
>>
>>     Store (AddP (Phi R base1 base2) offset) mem v # store A.i v
>>
>> ==(pseudo-code)==>
>>
>>     selector = (Phi R #base1 #base2)
>>
>>     if (selector == #base1) {
>>       Store base1 mem v ==> mem1
>>     } else if (selector == #base2) {
>>       Store base2 mem v ==> mem2
>>     } else {
>>       halt(); // impossible
>>     }
>>
>>     mem = Phi(R1, mem1, mem2);
>>
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>>
>>> So, gradual approach seems the way to go:
>>>     (1) split memory graph for clusters of interacting non-escaping
>>> allocations;
>>>
>>>     (2) perform adhoc transformation targeted at untangling aliasing
>>> accesses (e.g, split-through-phi);
>>>
>>>     (3) extract unique instance types where possible, thus making the
>>> corresponding allocation scalar replaceable
>>>
>>> =====================================================================
>>>
>>> Also, one observation: interacting allocations don't have to be of the
>>> same class.
>>>
>>>       static int testPolluted(int r, boolean b) {
>>>           A obj1 = new B1(r);
>>>           A obj2 = new B2(r);
>>>
>>>           A obj = (b ? obj1 : obj2);
>>>           for (int i = 1; i < r; i++) {
>>>               obj.i++;
>>>           }
>>>
>>>           return obj1.i + obj2.i;
>>>       }
>>>
>>> Requiring unique instance types to perform SR (and not enhancing SR to
>>> handle aliasing allocations case) helps avoid some challenges in
>>> instance rematerialization logic at safepoints, because actual shape of
>>> the scalarized object (its class and exact set of fields) becomes a
>>> runtime property.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>>>>
>>>>>> Otherwise, I believe wide memory states/merges would pose serious
>>>>>> problems. E.g., when a load is split through a phi, you need to pick
>>>>>> correct memory states for the new loads above the phi which quickly
>>>>>> becomes quite a challenging task.
>>>>>
>>>>> Especially in loops. Actually I did tried such approach before and I
>>>>> agree that it is hard.
>>>>>
>>>>> Thanks,
>>>>> Vladimir K
>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Vladimir Ivanov
>>>>>>
>>>>>>>
>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>       p0 = Allocate(...);
>>>>>>>       ...
>>>>>>>       p0.x = first;
>>>>>>>       p0.y = second;
>>>>>>>
>>>>>>>       if (cond) {
>>>>>>>           p1 = Allocate(...);
>>>>>>>           ...
>>>>>>>           p1.x = second;
>>>>>>>           p1.y = first;
>>>>>>>       }
>>>>>>>
>>>>>>>       p = phi(p0, p1) // unused and will be removed
>>>>>>>
>>>>>>>
>>>>>>>       return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>>>>> }
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir K
>>>>>>>
>>>>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>>>>> (BCCing hotspot-dev and moving the discussion to
>>>>>>>> hotspot-compiler-dev.)
>>>>>>>>
>>>>>>>> Hi Cesar,
>>>>>>>>
>>>>>>>> Thanks for looking into enhancing EA.
>>>>>>>>
>>>>>>>> Overall, the proposal looks reasonable.
>>>>>>>>
>>>>>>>> I suggest to look more closely at split_unique_types().
>>>>>>>> It introduces a dedicated class of alias categories for fields of
>>>>>>>> the allocation being eliminated and clones memory graph. I don't
>>>>>>>> see why it shouldn't work for multiple allocations.
>>>>>>>>
>>>>>>>> Moreover, split_unique_types() will break if you start optimizing
>>>>>>>> multiple allocations at once. The notion of unique alias should be
>>>>>>>> adjusted and cover the union of unique aliases for all interacting
>>>>>>>> allocations.
>>>>>>>>
>>>>>>>> Seems like you need to enhance SR to work on non-intersecting
>>>>>>>> clusters of allocations.
>>>>>>>>
>>>>>>>> One thing to take care of: scalar replacement relies on
>>>>>>>> TypeOopPtr::instance_id().
>>>>>>>>
>>>>>>>>     // If not InstanceTop or InstanceBot, indicates that this is
>>>>>>>>     // a particular instance of this type which is distinct.
>>>>>>>>     // This is the node index of the allocation node creating this
>>>>>>>> instance.
>>>>>>>>     int           _instance_id;
>>>>>>>>
>>>>>>>> It'll break when multiple allocations are in play.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Vladimir Ivanov
>>>>>>>>
>>>>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>>>>> Hi there again!
>>>>>>>>>
>>>>>>>>> Can you please give me feedback on the following approach to at
>>>>>>>>> least partially
>>>>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>>>>
>>>>>>>>> The problem that I am trying to solve arises when allocations are
>>>>>>>>> merged after a
>>>>>>>>> control flow split. The code below shows _one example_ of such a
>>>>>>>>> situation.
>>>>>>>>>
>>>>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>>>>>       Point p = new Point(x, y);
>>>>>>>>>       if (cond)
>>>>>>>>>           p = new Point(y, x);
>>>>>>>>>       // Allocations for p are merged here.
>>>>>>>>>       return p.calc();
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Assuming the method calls on "p" are inlined then the allocations
>>>>>>>>> will not
>>>>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>>>>
>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>       p0 = Allocate(...);
>>>>>>>>>       ...
>>>>>>>>>       p0.x = first;
>>>>>>>>>       p0.y = second;
>>>>>>>>>
>>>>>>>>>       if (cond) {
>>>>>>>>>           p1 = Allocate(...);
>>>>>>>>>           ...
>>>>>>>>>           p1.x = second;
>>>>>>>>>           p1.y = first;
>>>>>>>>>       }
>>>>>>>>>
>>>>>>>>>       p = phi(p0, p1)
>>>>>>>>>
>>>>>>>>>       return p.x - p.y;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> However, one of the constraints implemented here [2],
>>>>>>>>> specifically the third
>>>>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>>>>
>>>>>>>>> The approach that I'm considering for solving the problem is to
>>>>>>>>> replace the Phi
>>>>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields
>>>>>>>>> of the objects
>>>>>>>>> in the original Phi. The IR for `ex1` would look something like
>>>>>>>>> this after the
>>>>>>>>> transformation:
>>>>>>>>>
>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>       p0 = Allocate(...);
>>>>>>>>>       ...
>>>>>>>>>       p0.x = first;
>>>>>>>>>       p0.y = second;
>>>>>>>>>
>>>>>>>>>       if (cond) {
>>>>>>>>>           p1 = Allocate(...);
>>>>>>>>>           ...
>>>>>>>>>           p1.x = second;
>>>>>>>>>           p1.y = first;
>>>>>>>>>       }
>>>>>>>>>
>>>>>>>>>       pX = phi(first, second)
>>>>>>>>>       pY = phi(second, first)
>>>>>>>>>
>>>>>>>>>       return pX - pY;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> I understand that this transformation might not be applicable for
>>>>>>>>> all cases and
>>>>>>>>> that it's not as simple as illustrated above. Also, it seems to
>>>>>>>>> me that much of
>>>>>>>>> what I'd have to implement is already implemented in other steps
>>>>>>>>> of the Scalar
>>>>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>>>>> implementation details I plan to use as much of the existing code
>>>>>>>>> as possible.
>>>>>>>>> The algorithm for the transformation would be like this:
>>>>>>>>>
>>>>>>>>> split_phis(phi)
>>>>>>>>>       # If output of phi escapes, or something uses its identity, etc
>>>>>>>>>       # then we can't remove it. The conditions here might
>>>>>>>>> possible be the
>>>>>>>>>       # same as the ones implemented in
>>>>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>>>>>       if cant_remove_phi_output(phi)
>>>>>>>>>           return ;
>>>>>>>>>
>>>>>>>>>       # Collect a set of tuples(F,U) containing nodes U that uses
>>>>>>>>> field F
>>>>>>>>>       # member of the object resulting from `phi`.
>>>>>>>>>       fields_used = collect_fields_used_after_phi(phi)
>>>>>>>>>
>>>>>>>>>       foreach field in fields_used
>>>>>>>>>           producers = {}
>>>>>>>>>
>>>>>>>>>           # Create a list with the last Store for each field
>>>>>>>>> "field" on the
>>>>>>>>>           # scope of each of the Phi input objects.
>>>>>>>>>           foreach o in phi.inputs
>>>>>>>>>               # The function called below might re-use a lot of
>>>>>>>>> the code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>>>>>               producers += last_store_to_o_field(0, field)
>>>>>>>>>           # Create a new phi node whose inputs are the Store's to
>>>>>>>>> 'field'
>>>>>>>>>           field_phi = create_new_phi(producers)
>>>>>>>>>
>>>>>>>>>           update_consumers(field, field_phi)
>>>>>>>>>
>>>>>>>>> The implementation that I envisioned would be as a "pre-process"
>>>>>>>>> [3] step just
>>>>>>>>> after EA but before the constraint checks in
>>>>>>>>> `adjust_scalar_replaceable_state`
>>>>>>>>> [2]. If we agree that the overall Scalar Replacement
>>>>>>>>> implementation goes through
>>>>>>>>> the following major phases:
>>>>>>>>>
>>>>>>>>>       1. Identify the Escape Status of objects.
>>>>>>>>>       2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>>> based on a set of constraints.
>>>>>>>>>       3. Make call to Split_unique_types [4].
>>>>>>>>>       4 Iterate over object and array allocations.
>>>>>>>>>           4.1 Check if allocation can be eliminated.
>>>>>>>>>           4.2 Perform scalar replacement. Replace uses of object
>>>>>>>>> in Safepoints.
>>>>>>>>>           4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>>
>>>>>>>>> The transformation that I am proposing would change the overall
>>>>>>>>> flow to look
>>>>>>>>> like this:
>>>>>>>>>
>>>>>>>>>       1. Identify the Escape Status of objects.
>>>>>>>>>       2. ----> New: "Split phi functions" <----
>>>>>>>>>       2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>>> based on a set of constraints.
>>>>>>>>>       3. Make call to Split_unique_types [14].
>>>>>>>>>       4 Iterate over object and array allocations.
>>>>>>>>>           4.1 ----> Moved to split_phi: "Check if allocation can
>>>>>>>>> be eliminated" <----
>>>>>>>>>           4.2 Perform scalar replacement. Replace uses of object
>>>>>>>>> in Safepoints.
>>>>>>>>>           4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>>
>>>>>>>>> Please let me know what you think and thank you for taking the
>>>>>>>>> time to review
>>>>>>>>> this!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Cesar
>>>>>>>>>
>>>>>>>>> Notes:
>>>>>>>>>
>>>>>>>>>       [1] I am not sure yet how this approach will play with the
>>>>>>>>> case of a merge
>>>>>>>>>           with NULL.
>>>>>>>>>       [2]
>>>>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809%26amp%3Bdata%3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd6152056b06744f7359e08da10e33a44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637840865379134331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2uggNczR4bPxDv15gREOFA65mta6qrilwlZxblgQcYc%3D&amp;reserved=0
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24%26amp%3Bdata%3D04*7C01*7Cdivino.cesar*40microsoft.com*7C8c1737b992e847651e8d08d9f62d649b*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637811497098895122*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3D8hLm9BcYVRF810gFqf2*2B*2Fd28jzqU2k7htD*2FDLqR9vAM*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!c3mFGaPH2PWpbeiHR44WrjfJKF0Ymg6aPQ8EOEMK0t5iYjdL4XwgsEvifrlDVrer2pCrdQ%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd6152056b06744f7359e08da10e33a44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637840865379134331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=MX%2BMB2A%2FyA1sLbSbXPp0uIsckxM5OOc%2Fg%2BqPAMwSgAw%3D&amp;reserved=0>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>       [3] Another option would be to "patch" the current
>>>>>>>>> implementation to be able
>>>>>>>>>           to handle the merges. I am not certain that the "patch"
>>>>>>>>> approach would be
>>>>>>>>>           better, however, the "pre-process" approach is certainly
>>>>>>>>> much easier to test
>>>>>>>>>           and more readable.
>>>>>>>>>
>>>>>>>>>       [4] I cannot say I understand 100% the effects of executing
>>>>>>>>>           split_unique_types(). Would the transformation that I am
>>>>>>>>> proposing need to
>>>>>>>>>           be after the call to split_unique_types?
>

From njian at openjdk.java.net  Wed Mar 30 01:24:45 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Wed, 30 Mar 2022 01:24:45 GMT
Subject: RFR: 8282162: [vector] Optimize integral vector negation API [v3]
In-Reply-To: <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
 <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com>
Message-ID: <7Vq50g457PgQqxorybsnpP2N4frte8_-AKtJCHY5OdU=.cdf5b05c-fc17-4c63-b522-8866aa3bceb9@github.com>

On Mon, 28 Mar 2022 09:56:22 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE.
>> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern.
>> 
>> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture:
>>   - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation.
>>   - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`.
>> 
>> So with this patch, the following transformations are applied:
>> 
>> For non-masked negation with NEON:
>> 
>>   movi    v16.4s, #0x0
>>   sub v17.4s, v16.4s, v17.4s       ==> neg v17.4s, v17.4s
>> 
>> and with SVE:
>> 
>>   mov z16.s, #0
>>   sub z18.s, z16.s, z17.s          ==> neg z16.s, p7/m, z16.s
>> 
>> For masked negation with NEON:
>> 
>>   movi    v17.4s, #0x1
>>   mvn v19.16b, v18.16b
>>   mov v20.16b, v16.16b             ==>  neg v18.4s, v17.4s
>>   bsl v20.16b, v19.16b, v18.16b         bsl v19.16b, v18.16b, v17.16b
>>   add v19.4s, v20.4s, v17.4s
>>   mov v18.16b, v16.16b
>>   bsl v18.16b, v19.16b, v20.16b
>> 
>> and with SVE:
>> 
>>   mov z16.s, #-1
>>   mov z17.s, #1                    ==> neg z16.s, p0/m, z16.s
>>   eor z18.s, p0/m, z18.s, z16.s
>>   add z18.s, p0/m, z18.s, z17.s
>> 
>> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed):
>> 
>> NEON:
>> Benchmark                Gain
>> Byte128Vector.NEG        1.029
>> Byte128Vector.NEGMasked  1.757
>> Short128Vector.NEG       1.041
>> Short128Vector.NEGMasked 1.659
>> Int128Vector.NEG         1.005
>> Int128Vector.NEGMasked   1.513
>> Long128Vector.NEG        1.003
>> Long128Vector.NEGMasked  1.878
>> 
>> SVE with 512-bits:
>> Benchmark                Gain
>> ByteMaxVector.NEG        1.10
>> ByteMaxVector.NEGMasked  1.165
>> ShortMaxVector.NEG       1.056
>> ShortMaxVector.NEGMasked 1.195
>> IntMaxVector.NEG         1.002
>> IntMaxVector.NEGMasked   1.239
>> LongMaxVector.NEG        1.031
>> LongMaxVector.NEGMasked  1.191
>> 
>> X86 (non AVX-512):
>> Benchmark                Gain
>> ByteMaxVector.NEGMasked  1.254
>> ShortMaxVector.NEGMasked 1.359
>> IntMaxVector.NEGMasked   1.431
>> LongMaxVector.NEGMasked  1.989
>> 
>> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881
>> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896
>
> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make "degenerate_vector_integral_negate" to be "NegVI" private

AArch64 changes look good to me.

-------------

Marked as reviewed by njian (Committer).

PR: https://git.openjdk.java.net/jdk/pull/7782

From xgong at openjdk.java.net  Wed Mar 30 01:31:39 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 30 Mar 2022 01:31:39 GMT
Subject: RFR: 8282162: [vector] Optimize integral vector negation API [v3]
In-Reply-To: <yuwlO9Ou9wivrnXGqjg81FNs9jf7wCa-V3waCp9MC2s=.5a25ea85-fffc-4b2c-8561-2849d5c3b317@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
 <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com>
 <yuwlO9Ou9wivrnXGqjg81FNs9jf7wCa-V3waCp9MC2s=.5a25ea85-fffc-4b2c-8561-2849d5c3b317@github.com>
Message-ID: <fY6FqO7aT4A0H-CMKE8X7xGMXnoOIIb_LAo_lvdAq-U=.c5b98141-fe51-4c91-91e6-2c7164eb666d@github.com>

On Tue, 29 Mar 2022 18:05:56 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make "degenerate_vector_integral_negate" to be "NegVI" private
>
> Java changes are good.

Thanks for the review @PaulSandoz @nsjian !

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From xgong at openjdk.java.net  Wed Mar 30 01:42:41 2022
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 30 Mar 2022 01:42:41 GMT
Subject: Integrated: 8282162: [vector] Optimize integral vector negation API
In-Reply-To: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
References: <DfN2CR5uafy21uQ-vrjOEN2TobRf0CjuhQaWUNHEcBA=.a0a68064-8a2c-4735-8387-3a03ebaafef6@github.com>
Message-ID: <5MWaq1vZaLt2tM_0lFQ_QJcHxe5iWZ_VTNFYsUmmGm4=.1b73fdb1-2450-4419-ab63-fe851659cbd3@github.com>

On Fri, 11 Mar 2022 06:29:22 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE.
> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern.
> 
> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture:
>   - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation.
>   - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`.
> 
> So with this patch, the following transformations are applied:
> 
> For non-masked negation with NEON:
> 
>   movi    v16.4s, #0x0
>   sub v17.4s, v16.4s, v17.4s       ==> neg v17.4s, v17.4s
> 
> and with SVE:
> 
>   mov z16.s, #0
>   sub z18.s, z16.s, z17.s          ==> neg z16.s, p7/m, z16.s
> 
> For masked negation with NEON:
> 
>   movi    v17.4s, #0x1
>   mvn v19.16b, v18.16b
>   mov v20.16b, v16.16b             ==>  neg v18.4s, v17.4s
>   bsl v20.16b, v19.16b, v18.16b         bsl v19.16b, v18.16b, v17.16b
>   add v19.4s, v20.4s, v17.4s
>   mov v18.16b, v16.16b
>   bsl v18.16b, v19.16b, v20.16b
> 
> and with SVE:
> 
>   mov z16.s, #-1
>   mov z17.s, #1                    ==> neg z16.s, p0/m, z16.s
>   eor z18.s, p0/m, z18.s, z16.s
>   add z18.s, p0/m, z18.s, z17.s
> 
> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed):
> 
> NEON:
> Benchmark                Gain
> Byte128Vector.NEG        1.029
> Byte128Vector.NEGMasked  1.757
> Short128Vector.NEG       1.041
> Short128Vector.NEGMasked 1.659
> Int128Vector.NEG         1.005
> Int128Vector.NEGMasked   1.513
> Long128Vector.NEG        1.003
> Long128Vector.NEGMasked  1.878
> 
> SVE with 512-bits:
> Benchmark                Gain
> ByteMaxVector.NEG        1.10
> ByteMaxVector.NEGMasked  1.165
> ShortMaxVector.NEG       1.056
> ShortMaxVector.NEGMasked 1.195
> IntMaxVector.NEG         1.002
> IntMaxVector.NEGMasked   1.239
> LongMaxVector.NEG        1.031
> LongMaxVector.NEGMasked  1.191
> 
> X86 (non AVX-512):
> Benchmark                Gain
> ByteMaxVector.NEGMasked  1.254
> ShortMaxVector.NEGMasked 1.359
> IntMaxVector.NEGMasked   1.431
> LongMaxVector.NEGMasked  1.989
> 
> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881
> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896

This pull request has now been integrated.

Changeset: d0668568
Author:    Xiaohong Gong <xgong at openjdk.org>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d06685680c17583d56dc3d788d9a2ecea8812bc8
Stats:     325 lines in 15 files changed: 275 ins; 25 del; 25 mod

8282162: [vector] Optimize integral vector negation API

Reviewed-by: jiefu, psandoz, njian

-------------

PR: https://git.openjdk.java.net/jdk/pull/7782

From serb at openjdk.java.net  Wed Mar 30 04:15:40 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 30 Mar 2022 04:15:40 GMT
Subject: RFR: 8283422: Create a new test for JDK-8254790 [v2]
In-Reply-To: <9ZQqrMPVWSjmkh3Riwbd7UR1kMD5VzCsNOugmJigMCQ=.d8ae041a-80d6-485c-bc95-ef2a0c1a0605@github.com>
References: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
 <9ZQqrMPVWSjmkh3Riwbd7UR1kMD5VzCsNOugmJigMCQ=.d8ae041a-80d6-485c-bc95-ef2a0c1a0605@github.com>
Message-ID: <QzkZfdu4-U1mt-YmxoPvYT1WITDvNU9YCdZlqRScIDw=.60abc8c5-3ea2-43a2-884e-10ea834333c4@github.com>

On Mon, 28 Mar 2022 20:30:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The [JDK-8254790](https://bugs.openjdk.java.net/browse/JDK-8254790) initially was reported on macOS.
>> It was found by the "javax/xml/crypto/dsig/GenerationTests.java" test which for some reason worked fine on Linux/Windows most? of the time.
>> 
>> I tried to run that test on Linux/Windows many times on a few systems and it always pass. Also, I got the same result for the tier1...tier4 tests.
>> 
>> I have found that the easiest way to reproduce the crash is to pass the result of the string.indexOf to the str.charAt when the heap is big enough. The test below[1] trigger the crash 1000 time in a row on win/lin on systems I have tested.
>> 
>> I am not sure what is the best way to contribute to the test, should I create a stand-alone test like[1], or update an existing test as I did for the first version of this PR?
>> 
>> [1]:
>> 
>> package compiler.intrinsics.string;
>> 
>> import static jdk.test.lib.Asserts.assertTrue;
>> 
>> public final class TestStringIndexOfLargeHeap {
>>     static final int[] data = new int[Integer.MAX_VALUE / 2];
>>     public static void main(String[] args) throws Exception {
>>         test('a');
>>         test('\ubeef');
>>     }
>>     private static void test(char ch) {
>>         String str = ("0123456789" + ch).repeat(100);
>>         for (int i = 0; i < 1_000_000; ++i) {
>>             assertTrue(ch == str.charAt(str.indexOf(ch)));
>>         }
>>     }
>> }
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Request 8G of heap
>  - Merge branch 'master' into JDK-8283422
>  - Add vm.bits == "64"
>  - Initial version

I have found the bug where some tests tried to allocate same huge amount of memory and fail:
https://bugs.openjdk.java.net/browse/JDK-8227645
The solution was to move them to the special folder "hotspot/jtreg/resourcehogs" so they will have "exclusiveAccess" flag.
I'll "move" the new test there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7883

From serb at openjdk.java.net  Wed Mar 30 05:07:37 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 30 Mar 2022 05:07:37 GMT
Subject: RFR: 8283422: Create a new test for JDK-8254790 [v3]
In-Reply-To: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
References: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
Message-ID: <q2_dhgoOK6iTmfd8L5HlmPpqHNhHfQgEUuqpTr6B9Mo=.a86f6f2e-0d56-4a10-ad24-df34bb54e72f@github.com>

> The [JDK-8254790](https://bugs.openjdk.java.net/browse/JDK-8254790) initially was reported on macOS.
> It was found by the "javax/xml/crypto/dsig/GenerationTests.java" test which for some reason worked fine on Linux/Windows most? of the time.
> 
> I tried to run that test on Linux/Windows many times on a few systems and it always pass. Also, I got the same result for the tier1...tier4 tests.
> 
> I have found that the easiest way to reproduce the crash is to pass the result of the string.indexOf to the str.charAt when the heap is big enough. The test below[1] trigger the crash 1000 time in a row on win/lin on systems I have tested.
> 
> I am not sure what is the best way to contribute to the test, should I create a stand-alone test like[1], or update an existing test as I did for the first version of this PR?
> 
> [1]:
> 
> package compiler.intrinsics.string;
> 
> import static jdk.test.lib.Asserts.assertTrue;
> 
> public final class TestStringIndexOfLargeHeap {
>     static final int[] data = new int[Integer.MAX_VALUE / 2];
>     public static void main(String[] args) throws Exception {
>         test('a');
>         test('\ubeef');
>     }
>     private static void test(char ch) {
>         String str = ("0123456789" + ch).repeat(100);
>         for (int i = 0; i < 1_000_000; ++i) {
>             assertTrue(ch == str.charAt(str.indexOf(ch)));
>         }
>     }
> }

Sergey Bylokhov has updated the pull request incrementally with three additional commits since the last revision:

 - Update TestStringIntrinsics2.java
 - Update TestStringIntrinsics2.java
 - Create TestStringIntrinsics2LargeArray.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7883/files
  - new: https://git.openjdk.java.net/jdk/pull/7883/files/ab2fbc35..358813a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7883&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7883&range=01-02

  Stats: 88 lines in 2 files changed: 61 ins; 26 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7883.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7883/head:pull/7883

PR: https://git.openjdk.java.net/jdk/pull/7883

From serb at openjdk.java.net  Wed Mar 30 07:03:21 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 30 Mar 2022 07:03:21 GMT
Subject: RFR: 8283422: Create a new test for JDK-8254790 [v4]
In-Reply-To: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
References: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
Message-ID: <Hv14ENxfjEfYrWC_6BhOykIdwv4JdEC_E81DILqCz9U=.71a5fa31-6b03-44dd-9b9b-0e93203e6697@github.com>

> The [JDK-8254790](https://bugs.openjdk.java.net/browse/JDK-8254790) initially was reported on macOS.
> It was found by the "javax/xml/crypto/dsig/GenerationTests.java" test which for some reason worked fine on Linux/Windows most? of the time.
> 
> I tried to run that test on Linux/Windows many times on a few systems and it always pass. Also, I got the same result for the tier1...tier4 tests.
> 
> I have found that the easiest way to reproduce the crash is to pass the result of the string.indexOf to the str.charAt when the heap is big enough. The test below[1] trigger the crash 1000 time in a row on win/lin on systems I have tested.
> 
> I am not sure what is the best way to contribute to the test, should I create a stand-alone test like[1], or update an existing test as I did for the first version of this PR?
> 
> [1]:
> 
> package compiler.intrinsics.string;
> 
> import static jdk.test.lib.Asserts.assertTrue;
> 
> public final class TestStringIndexOfLargeHeap {
>     static final int[] data = new int[Integer.MAX_VALUE / 2];
>     public static void main(String[] args) throws Exception {
>         test('a');
>         test('\ubeef');
>     }
>     private static void test(char ch) {
>         String str = ("0123456789" + ch).repeat(100);
>         for (int i = 0; i < 1_000_000; ++i) {
>             assertTrue(ch == str.charAt(str.indexOf(ch)));
>         }
>     }
> }

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  Add resourcehogs/compiler  to the hotspot_slow_compiler

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7883/files
  - new: https://git.openjdk.java.net/jdk/pull/7883/files/358813a5..feded853

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7883&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7883&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7883.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7883/head:pull/7883

PR: https://git.openjdk.java.net/jdk/pull/7883

From shade at openjdk.java.net  Wed Mar 30 07:13:44 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 30 Mar 2022 07:13:44 GMT
Subject: RFR: 8283787: C1: Remove unused ArrayStoreExceptionStub::_info
In-Reply-To: <n8TuFg0xCQ7ODclXppRkIiUz7Rw3DUmOdDX4IEMAA5w=.0b3c7edf-9553-4d7a-a0a6-75d2b39338f1@github.com>
References: <n8TuFg0xCQ7ODclXppRkIiUz7Rw3DUmOdDX4IEMAA5w=.0b3c7edf-9553-4d7a-a0a6-75d2b39338f1@github.com>
Message-ID: <KtX-DIy5Z5iVFJ0c8BkjFcQOPFi3UNsPkksYaksE1zU=.7ad81176-6d85-4a50-aebb-814fe4f77533@github.com>

On Mon, 28 Mar 2022 12:45:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains `ArrayStoreExceptionStub::_info` field is not initialized. It is not actually used, and the incoming `CodeEmitInfo*` gets passed to superclass instead.

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7992

From shade at openjdk.java.net  Wed Mar 30 07:14:40 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 30 Mar 2022 07:14:40 GMT
Subject: RFR: 8283789: CompilerPhaseTypeHelper::to_bitmask should operate
 on uint64_t
In-Reply-To: <Wg8QF4tB5ZV_zOg5nOG1NcPm05ME6DBZGXT-mWzFMgk=.89d42e05-22da-42a0-94d4-95d1f5b972d6@github.com>
References: <Wg8QF4tB5ZV_zOg5nOG1NcPm05ME6DBZGXT-mWzFMgk=.89d42e05-22da-42a0-94d4-95d1f5b972d6@github.com>
Message-ID: <HnF1PwTTb_QB2Xk7tUFPRjAFIxafKt6Urr6AxJ1y2SU=.f92bd46e-22a0-4de8-b0b6-960ca4d21202@github.com>

On Mon, 28 Mar 2022 13:02:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8281505](https://bugs.openjdk.java.net/browse/JDK-8281505) added this helper method that operates on `uint64_t` masks, but it operates on `int`s. So it is subtly broken on 32-bit platforms, for example. SonarCloud complains about it: "The result of the left shift is undefined due to shifting by '32', which is greater or equal to the width of type 'int'"
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `compiler/oracle` passes
>  - [x] Linux x86_32 fastdebug, `compiler/oracle` passes

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7994

From rcastanedalo at openjdk.java.net  Wed Mar 30 07:14:46 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 30 Mar 2022 07:14:46 GMT
Subject: RFR: 8282547: IGV: add control-flow graph view [v3]
In-Reply-To: <rL8r7k0H7xRO-bbAZ6HtCK1aU1rIGGHGV7zAF_tL9NA=.4afdd437-61b1-4056-b877-9e10fb2a1f82@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
 <NQtRiYFx2_FiLpAUDa8qx96T27jFZt1yM0nk56rluno=.d9bc7262-4c90-4664-ba6b-88d5a1427f06@github.com>
 <rL8r7k0H7xRO-bbAZ6HtCK1aU1rIGGHGV7zAF_tL9NA=.4afdd437-61b1-4056-b877-9e10fb2a1f82@github.com>
Message-ID: <LsGrVT1nyZGlkjN9V5O9E04qeqttI-h8DmYtvkO60VY=.8c61dbd5-be88-407c-8a08-62040f9b566a@github.com>

On Tue, 29 Mar 2022 16:50:17 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Works like a charm for me and changes look reasonable. Approved!

Thanks for reviewing, Tobias!

-------------

PR: https://git.openjdk.java.net/jdk/pull/7817

From shade at openjdk.java.net  Wed Mar 30 07:14:41 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 30 Mar 2022 07:14:41 GMT
Subject: Integrated: 8283789: CompilerPhaseTypeHelper::to_bitmask should
 operate on uint64_t
In-Reply-To: <Wg8QF4tB5ZV_zOg5nOG1NcPm05ME6DBZGXT-mWzFMgk=.89d42e05-22da-42a0-94d4-95d1f5b972d6@github.com>
References: <Wg8QF4tB5ZV_zOg5nOG1NcPm05ME6DBZGXT-mWzFMgk=.89d42e05-22da-42a0-94d4-95d1f5b972d6@github.com>
Message-ID: <XkkS2pt2CXWHjo1_bf49ud70B72G19dic1QTXY4kpqE=.809fa1e1-2b23-4eca-a42a-34cce2713094@github.com>

On Mon, 28 Mar 2022 13:02:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8281505](https://bugs.openjdk.java.net/browse/JDK-8281505) added this helper method that operates on `uint64_t` masks, but it operates on `int`s. So it is subtly broken on 32-bit platforms, for example. SonarCloud complains about it: "The result of the left shift is undefined due to shifting by '32', which is greater or equal to the width of type 'int'"
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `compiler/oracle` passes
>  - [x] Linux x86_32 fastdebug, `compiler/oracle` passes

This pull request has now been integrated.

Changeset: 8b656117
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8b656117dd1521ff23d6039eff7d13ef63a291c8
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8283789: CompilerPhaseTypeHelper::to_bitmask should operate on uint64_t

Reviewed-by: chagedorn, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7994

From shade at openjdk.java.net  Wed Mar 30 07:16:47 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 30 Mar 2022 07:16:47 GMT
Subject: Integrated: 8283787: C1: Remove unused ArrayStoreExceptionStub::_info
In-Reply-To: <n8TuFg0xCQ7ODclXppRkIiUz7Rw3DUmOdDX4IEMAA5w=.0b3c7edf-9553-4d7a-a0a6-75d2b39338f1@github.com>
References: <n8TuFg0xCQ7ODclXppRkIiUz7Rw3DUmOdDX4IEMAA5w=.0b3c7edf-9553-4d7a-a0a6-75d2b39338f1@github.com>
Message-ID: <RVb9Vffg0lqTCnlQDDjqpmqPvujqRNs2hRsG3DRPxco=.79619c2c-bde5-4ad1-8de6-6d1106f3a19f@github.com>

On Mon, 28 Mar 2022 12:45:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud complains `ArrayStoreExceptionStub::_info` field is not initialized. It is not actually used, and the incoming `CodeEmitInfo*` gets passed to superclass instead.

This pull request has now been integrated.

Changeset: aa335258
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/aa3352588bd9357c04550026e1af9fe503b237cf
Stats:     3 lines in 1 file changed: 0 ins; 3 del; 0 mod

8283787: C1: Remove unused ArrayStoreExceptionStub::_info

Reviewed-by: thartmann, chagedorn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7992

From rcastanedalo at openjdk.java.net  Wed Mar 30 07:18:52 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 30 Mar 2022 07:18:52 GMT
Subject: Integrated: 8282547: IGV: add control-flow graph view
In-Reply-To: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
References: <fyFtUzHcbzkQJl196d6KCzu-4yromJHCXTNCUzEaTPs=.03e08c3f-825c-4de5-91b4-fa678621b3b9@github.com>
Message-ID: <mpAtsoZbF74U4Y6IzyIDVftL_VwXA1zEHsMs4Pv24M4=.05309c79-8488-4ea6-830f-835eb07b543e@github.com>

On Tue, 15 Mar 2022 11:36:21 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> This change adds a new view to the Ideal Graph Visualizer showing a classic control-flow graph (CFG) where nodes are serialized within basic blocks and arcs across basic blocks represent control flow:
> 
> ![cfg](https://user-images.githubusercontent.com/8792647/158367227-1ccfb9e0-bba1-4a80-963e-3e8c5f23c1c4.png)
> 
> The CFG provides a higher-level, more compact view of the graph than the existing views, where it can be hard to see the overall structure for all but the smallest graphs:
> 
> ![sea-vs-cfg](https://user-images.githubusercontent.com/8792647/158366842-f32b1b22-f7ed-4404-bb43-9d5c58a98ec4.png)
> 
> ![clusters-vs-cfg](https://user-images.githubusercontent.com/8792647/158366861-64561cfa-2553-4c9e-ad59-25acce6b4961.png)
> 
> If a schedule is available in the input graph (because it corresponds to the _Global code motion_ phase or later), the CFG, including the serialization of nodes within basic blocks, is derived from it. Otherwise, the CFG is approximated by the C2-specific `ServerCompilerScheduler` class. Dependencies among nodes are shown textually, by extending the label of each node with a list of its inputs:
> 
> <p align="center">
>     <img width="35%" src="https://user-images.githubusercontent.com/8792647/158367428-5aa222e9-6a5c-4e78-871f-853e5b918599.png">
> </p>
> 
> The exact information shown about each input can be configured in Tools -> Options -> Tiny Node Text.
> 
> The new CFG view is available at the same level as the existing "sea of nodes" (default) and "clustered sea-of-nodes" views. The view can be selected from the main toolbar:
> 
> ![toolbar](https://user-images.githubusercontent.com/8792647/158367502-ac8d8a29-5f35-4604-acc3-9d563c60e917.png)
> 
> The default view shown when opening a new graph can be configured in Tools -> Options -> Default View.
> 
> The same functionality available for the existing views also applies to the new CFG:
> 
> - node extraction:
> 
> ![node-extraction](https://user-images.githubusercontent.com/8792647/158371016-f7988eb6-368f-4805-ac7a-2b5611d16d7a.png)
> 
> - pop-up information on edges:
> 
> ![popup](https://user-images.githubusercontent.com/8792647/158367664-495189d5-384c-4b86-a62b-08863420c531.png)
> 
> - filtering:
> 
> ![filtering](https://user-images.githubusercontent.com/8792647/158367690-47b95bcd-7e8e-466e-b71b-f3e7d04c60ac.png)
> 
> - quick node and basic block search:
> 
> ![quick-search](https://user-images.githubusercontent.com/8792647/158367717-8bc90027-8ce7-4071-be04-1d67de6c91dd.png)
> 
> - and exporting.
> 
> The list of custom filters is extended with three new block-hiding filters:
> 
> - `Hide root block`: remove root block and hide all back-edges from exiting blocks that clutter the CFG.
> 
> - `Hide uncommon trap blocks`: remove blocks with uncommon traps to simplify following the "hot paths" in the CFG.
> 
> - `Hide exception blocks`: remove blocks that create and throw exceptions to also simplify following the "hot paths" in the CFG.
> 
> When using the CFG view, it is important to keep in mind that, in graphs corresponding to phases earlier than _Global code motion_, the presented CFG is just one of many possible projections of the sea-of-nodes representation, and that this projection is computed by an approximation of what C2 would do if it scheduled the graph at that stage. The approximation has some known limitations ([JDK-8280568](https://bugs.openjdk.java.net/browse/JDK-8280568), [JDK-8282053](https://bugs.openjdk.java.net/browse/JDK-8282053)). Future work should address these and warn the user when the approximated CFG is known to be inaccurate.
> 
> ### Testing
> 
> #### Functionality
> 
> - Tested the above functionality manually on a small selection of graphs.
> 
> - Tested automatically that scheduling (approximating C2's GCM and LCM algorithms) and viewing thousands of graphs in the three views does not trigger any assertion failure (by instrumenting IGV to schedule and view graphs as they are loaded and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).
> 
> #### Performance
> 
> - Measured the scheduling and view creation time for each of the three views on a selection of 22 large graphs (between 2515 and 7329 nodes). On average:
> 
> - The change introduces a slight overhead when creating the existing views (2% and 5% for the clustered and non-clustered sea-of-nodes views). This overhead is due to the introduction of abstractions and data structures required by the CFG view.
> 
> - The new CFG view is considerably faster to create than the existing ones (4.2x and 2.5x faster than the clustered and non-clustered sea-of-nodes views), as it can be expected, since only basic blocks have to be laid out. Furthermore, the CFG view scales better as the size of the graph increases.
> 
> - The change slows down scheduling by 27%. This overhead corresponds to the additional work of approximating C2's LCM, and it is essential for the CFG view. Fortunately, scheduling takes only a fraction of the time needed to create a view (typically no more than a third), and it only needs to run once for each graph, whereas views have to be re-created on node extraction, filtering, etc.
> 
> The performance results are [attached](https://github.com/openjdk/jdk/files/8252786/performance-evaluation.ods) (note that each measurement in the sheet corresponds to the median of ten runs).

This pull request has now been integrated.

Changeset: edb42d7b
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/edb42d7b0aabd07ef9f46cb1f0e862f7bb912378
Stats:     2361 lines in 70 files changed: 1854 ins; 270 del; 237 mod

8282547: IGV: add control-flow graph view

Co-authored-by: Christian Hagedorn <chagedorn at openjdk.org>
Reviewed-by: chagedorn, xliu, thartmann

-------------

PR: https://git.openjdk.java.net/jdk/pull/7817

From shade at openjdk.java.net  Wed Mar 30 07:19:45 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 30 Mar 2022 07:19:45 GMT
Subject: RFR: 8283737: riscv: MacroAssembler::stop() should emit
 fixed-length instruction sequence [v3]
In-Reply-To: <MxwYDXP63-lmhUYDRANE8_k6HXhmeSzBNY-Ebpc94Co=.7bb6097b-c4b0-456e-8248-024219c6ee3e@github.com>
References: <SdQ6BVPC9MXxCD42wXnclX5bmDx6Ckl-1Z46axMtkkU=.0b278560-7ffe-4750-9483-ea5c31898918@github.com>
 <MxwYDXP63-lmhUYDRANE8_k6HXhmeSzBNY-Ebpc94Co=.7bb6097b-c4b0-456e-8248-024219c6ee3e@github.com>
Message-ID: <vd5Q7bB_PfxsfnO4z2ikdBJYecmpFGzi3Jyewd7oFvI=.030fe7f0-32c8-4ed3-a553-f1cce5eb3ce1@github.com>

On Tue, 29 Mar 2022 08:53:16 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> Hi team,
>> 
>> Could I have a review of this simple patch? -
>> 
>> `PhaseOutput::fill_buffer` detects if the real size of a node matches (<=) the size of it in scratch_emit(). The call chain for MacroAssembler::stop() is:
>> 
>> 
>> MachEpilogNode::emit
>>     -> reserved_stack_check()
>>          -> should_not_reach_here()
>>               -> stop(const char *msg)
>> 
>> 
>> `li()` on RISCV could generate 1~6 instructions, and the msg argument could be an on-stack buffer; `stop()` also uses `__ pc()` that could also be different in `scratch_emit()` and `emit()`. They both have the potential issue here so the size generated in `MacroAssembler::stop()` needs to be a fixed value.
>> 
>> Could be reproduced in the fastdebug build by adding one line:
>> 
>> 
>> // Die now.
>> instruct ShouldNotReachHere() %{
>>   match(Halt);
>>   ins_cost(BRANCH_COST);
>>   format %{ "#@ShouldNotReachHere" %}
>>   ins_encode %{
>>     Assembler::CompressibleRegion cr(&_masm);
>>     if (is_reachable()) {
>>       __ halt();
>> +     __ unimplemented("this is an on-stack char literal");  // assertion fail at 'assert(false, "wrong size of mach node");'
>>     }
>>   %}
>>   ins_pipe(pipe_class_default);
>> %}
>> 
>> 
>> This patch also fixes a typo introduced in JDK-8278994: `c_bnez` is mistakenly written to `c_beqz`, though not used until now, needing a fix for future usage.
>> 
>> 
>> Tests passed in hotspot tier1 & jdk tier1 without new errors found.
>> 
>> Thanks,
>> Xiaolin
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Polish comments as the suggestion

Looks fine. But I would rather push `c_beqz` change under a separate PR, so that the issue tracking is clean.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7982

From serb at openjdk.java.net  Wed Mar 30 07:56:42 2022
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 30 Mar 2022 07:56:42 GMT
Subject: RFR: 8283422: Create a new test for JDK-8254790 [v4]
In-Reply-To: <Hv14ENxfjEfYrWC_6BhOykIdwv4JdEC_E81DILqCz9U=.71a5fa31-6b03-44dd-9b9b-0e93203e6697@github.com>
References: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
 <Hv14ENxfjEfYrWC_6BhOykIdwv4JdEC_E81DILqCz9U=.71a5fa31-6b03-44dd-9b9b-0e93203e6697@github.com>
Message-ID: <WOrbaBA4W0OKlopTMx3XSduvHpCeKqgdwKSj2xhDKRE=.e650b03a-b4bc-41cb-a0ac-8f9300d61fd2@github.com>

On Wed, 30 Mar 2022 07:03:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The [JDK-8254790](https://bugs.openjdk.java.net/browse/JDK-8254790) initially was reported on macOS.
>> It was found by the "javax/xml/crypto/dsig/GenerationTests.java" test which for some reason worked fine on Linux/Windows most? of the time.
>> 
>> I tried to run that test on Linux/Windows many times on a few systems and it always pass. Also, I got the same result for the tier1...tier4 tests.
>> 
>> I have found that the easiest way to reproduce the crash is to pass the result of the string.indexOf to the str.charAt when the heap is big enough. The test below[1] trigger the crash 1000 time in a row on win/lin on systems I have tested.
>> 
>> I am not sure what is the best way to contribute to the test, should I create a stand-alone test like[1], or update an existing test as I did for the first version of this PR?
>> 
>> [1]:
>> 
>> package compiler.intrinsics.string;
>> 
>> import static jdk.test.lib.Asserts.assertTrue;
>> 
>> public final class TestStringIndexOfLargeHeap {
>>     static final int[] data = new int[Integer.MAX_VALUE / 2];
>>     public static void main(String[] args) throws Exception {
>>         test('a');
>>         test('\ubeef');
>>     }
>>     private static void test(char ch) {
>>         String str = ("0123456789" + ch).repeat(100);
>>         for (int i = 0; i < 1_000_000; ++i) {
>>             assertTrue(ch == str.charAt(str.indexOf(ch)));
>>         }
>>     }
>> }
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add resourcehogs/compiler  to the hotspot_slow_compiler

The test is updated:
 - The special wrapper `TestStringIntrinsics2LargeArray` for the `TestStringIntrinsics2` is added to the test/hotspot/jtreg/resourcehogs/. This approach is based on the similar [test](https://github.com/openjdk/jdk/blob/edb42d7b0aabd07ef9f46cb1f0e862f7bb912378/test/hotspot/jtreg/resourcehogs/serviceability/sa/LingeredAppWithLargeArray.java#L28). Note that the tests in the `resourcehogs` folder use the `exclusiveAccess` property.
 - The new test will be executed as part of the hotspot:tier3

-------------

PR: https://git.openjdk.java.net/jdk/pull/7883

From ngasson at openjdk.java.net  Wed Mar 30 07:58:38 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 30 Mar 2022 07:58:38 GMT
Subject: RFR: 8282764: AArch64:
 compiler/vectorapi/reshape/TestVectorCastNeon.java failed with incorrect
 result [v2]
In-Reply-To: <tGc05DsOPxV48goBd2BQDYPCzIcyj8E1d4Yb0wp_NyU=.e11269be-1a52-48db-906b-861bf2e54998@github.com>
References: <5s9gVoO8BXDC9k_GYrcMupuP60CgvgvvuTwy6obPZqA=.dbbccd3f-f4f2-404f-a9f5-7b2e110cd84e@github.com>
 <tGc05DsOPxV48goBd2BQDYPCzIcyj8E1d4Yb0wp_NyU=.e11269be-1a52-48db-906b-861bf2e54998@github.com>
Message-ID: <oAWO5xDZAjWAgu7bkabhzK8qT_6KE9aHs5AlnSJd6-c=.5b5add5f-384c-44bf-85ba-0f3f2ea4ceb2@github.com>

On Tue, 29 Mar 2022 07:43:08 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

>> Vector API long to float conversion operation on NEON converts vector of 2 longs to 2 floats. In current implementation, we convert 2 longs to 2 doubles first and then converts 2 doubles to 2 floats. However, this two-steps conversion may have two roundings, while the expected behavior, conversion from long to float directly, has only one rounding. This will result in inconsistent result. E.g. for the failure test case:
>> 
>> 
>> jshell> long l = 0x561a524000000001L;
>> l ==> 6204361871487664129
>> 
>> jshell> float l2f = (float)l;
>> l2f ==> 6.2043621E18
>> 
>> jshell> float l2d2f = (float)((double)l);
>> l2d2f ==> 6.2043616E18
>> 
>> 
>> Since we don't have NEON instruction to support vector long to float conversion, we fix the codegen by doing it in scalar operation one element by one element.
>> 
>> TEST: vector api jtreg tests passed.
>
> Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment for special value usage.

cpu/aarch64 changes look OK to me and the Windows x64 failure is some unrelated environment setup problem.

-------------

Marked as reviewed by ngasson (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7850

From thartmann at openjdk.java.net  Wed Mar 30 08:18:53 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 30 Mar 2022 08:18:53 GMT
Subject: RFR: 8249893: AARCH64: optimize the construction of the value from
 the bits of the other two [v6]
In-Reply-To: <gkAWbsifcD9c07PXP3iylRJprzjltmXXW0gzu9v9jcw=.02274971-3567-4744-933d-c678c232acad@github.com>
References: <a9Y6VAl7PQHz-7sXdEXLo83i2KRyi7Ci5N5bYbw5k9c=.503d9695-9f81-4fff-834e-1bf45d650ce8@github.com>
 <5n3SJE02oD_SW_psT84VEJh22lomGJfJtARdyjf0Kcw=.acff1dc7-3dbd-4c8d-8889-f434570e6da2@github.com>
 <Tu9o9ynIQoEjtjKeKbWHwWr4V515V8RJ8ndeqstzBd0=.8eec84fb-00b9-4cb0-b50c-14bc0677d6d4@github.com>
 <NgyZMauLC7Tu8rovdEmYzhyLYmO0YvsA24L55Mblwbs=.f9ad6f5c-61ed-44ed-8494-6c962b1d0936@github.com>
 <fSFfdNo4HQ8enbL4jooEea8LnsGc-KsRTR1fE7WW26I=.1a385733-0c6b-4225-a0c1-31f54f235920@github.com>
 <gkAWbsifcD9c07PXP3iylRJprzjltmXXW0gzu9v9jcw=.02274971-3567-4744-933d-c678c232acad@github.com>
Message-ID: <mRv9RovxXhRAzC1v88uqj0JPbZKkZ69M02HymBYo7Rc=.176b45b6-dacd-410f-84fc-c26192984303@github.com>

On Thu, 5 Nov 2020 10:21:07 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

>> Thanks for clarifying the code. I still have one thing I'd like to establish and, perhaps, document in the code or maybe just in this thread.
>> 
>> I may have missed something in the preceding email thread but at present I am not aware of why you need to delay application of this transform to a new post-loops optimization stage (you said it was needed but I didn't see any reason given). Since that adds more complexity to the overall optimization process I think it needs carefully justifying. Of course, it might be that this requirement also applies for other Ideal transforms, so I am not suggesting adding this extra step is necessarily a bad idea. Could you explain why it is needed in this case?
>
>>  why you need to delay application of this transform to a new post-loops optimization stage
> 
> Unfortunately, BitfieldInsert transformation conflicts with vectorization:
> - if or/and/shift was converted to BFI it is no longer vectorized
> - vectorized or/and/shift operations are faster than BFI
> 
> I delayed my transformation to be sure loop and vectorization transformations is already done at the moment.

@bulasevich any plans to re-open and fix this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/511

From tschatzl at openjdk.java.net  Wed Mar 30 08:51:24 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 30 Mar 2022 08:51:24 GMT
Subject: RFR: 8283494: Factor out calculation of actual number of XMM
 registers [v2]
In-Reply-To: <VWzCeBhLgEcnxHs1YZ73N3w2i5G3JcJwIR_jx9HiKls=.0e645b29-1809-4f05-950b-eecabc46010f@github.com>
References: <VWzCeBhLgEcnxHs1YZ73N3w2i5G3JcJwIR_jx9HiKls=.0e645b29-1809-4f05-950b-eecabc46010f@github.com>
Message-ID: <6bTFyyxs88dyy8zMP0VDc0DRQilIL1Epv5lh6lOaer0=.7155cc98-2c22-41ce-ac38-b71aef78bae2@github.com>

> Hi all,
> 
>   can I have reviews for this change that factors out calculation of the actually available number of XMM registers on a given processor/given command line options into a method and reuse that as much as possible?
> 
> This relates to this code snippet:
> 
>       int xmm_bypass_limit = FrameMap::nof_xmm_regs;
> #ifdef _LP64
>       if (UseAVX < 3) {
>         xmm_bypass_limit = xmm_bypass_limit / 2;
>       }
> #endif
> 
> 
> Also, there is already the method `FrameMap::get_num_caller_save_xmms()` that has been updated to use that new method `XMMRegisterImpl::available_xmm_registers()`; further I tried to appropriately use `FrameMap::get_num_caller_save_xmms` in the places where either would work. Please have a look in particular about that.
> 
> I did not change strange to me variable names like `xmm_bypass_limit` above as they probably make some sense to somebody as it's used quite often.
> 
> This also fixes a compilation error without configuring C1 introduced with [JDK-8283327](https://bugs.openjdk.java.net/browse/JDK-8283327).
> 
> Testing: tier1-5 (all but linux-aarch64 done), gha, local compilation with `configure --with-features=-compiler1`.
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  Put method implementation in hpp file

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7917/files
  - new: https://git.openjdk.java.net/jdk/pull/7917/files/60c99edf..ad11cee6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7917&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7917&range=00-01

  Stats: 21 lines in 2 files changed: 9 ins; 11 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7917.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7917/head:pull/7917

PR: https://git.openjdk.java.net/jdk/pull/7917

From xlinzheng at openjdk.java.net  Wed Mar 30 08:53:26 2022
From: xlinzheng at openjdk.java.net (Xiaolin Zheng)
Date: Wed, 30 Mar 2022 08:53:26 GMT
Subject: RFR: 8283737: riscv: MacroAssembler::stop() should emit
 fixed-length instruction sequence [v4]
In-Reply-To: <SdQ6BVPC9MXxCD42wXnclX5bmDx6Ckl-1Z46axMtkkU=.0b278560-7ffe-4750-9483-ea5c31898918@github.com>
References: <SdQ6BVPC9MXxCD42wXnclX5bmDx6Ckl-1Z46axMtkkU=.0b278560-7ffe-4750-9483-ea5c31898918@github.com>
Message-ID: <Sjv9AXCASVXcQp1Tem2Mfmxn_ZELecVg_dHNNYhOU-I=.dc1395ac-8c52-4936-9c0d-3419b34769e9@github.com>

> Hi team,
> 
> Could I have a review of this simple patch? -
> 
> `PhaseOutput::fill_buffer` detects if the real size of a node matches (<=) the size of it in scratch_emit(). The call chain for MacroAssembler::stop() is:
> 
> 
> MachEpilogNode::emit
>     -> reserved_stack_check()
>          -> should_not_reach_here()
>               -> stop(const char *msg)
> 
> 
> `li()` on RISCV could generate 1~6 instructions, and the msg argument could be an on-stack buffer; `stop()` also uses `__ pc()` that could also be different in `scratch_emit()` and `emit()`. They both have the potential issue here so the size generated in `MacroAssembler::stop()` needs to be a fixed value.
> 
> Could be reproduced in the fastdebug build by adding one line:
> 
> 
> // Die now.
> instruct ShouldNotReachHere() %{
>   match(Halt);
>   ins_cost(BRANCH_COST);
>   format %{ "#@ShouldNotReachHere" %}
>   ins_encode %{
>     Assembler::CompressibleRegion cr(&_masm);
>     if (is_reachable()) {
>       __ halt();
> +     __ unimplemented("this is an on-stack char literal");  // assertion fail at 'assert(false, "wrong size of mach node");'
>     }
>   %}
>   ins_pipe(pipe_class_default);
> %}
> 
> 
> This patch also fixes a typo introduced in JDK-8278994: `c_bnez` is mistakenly written to `c_beqz`, though not used until now, needing a fix for future usage.
> 
> 
> Tests passed in hotspot tier1 & jdk tier1 without new errors found.
> 
> Thanks,
> Xiaolin

Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:

  Revert the c.beqz commit: put it into another patch as the suggestion
  
  This reverts commit cd4a37b655af41f20d00b71a542b00161ff88e22.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7982/files
  - new: https://git.openjdk.java.net/jdk/pull/7982/files/1106943d..91341179

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7982&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7982&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7982.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7982/head:pull/7982

PR: https://git.openjdk.java.net/jdk/pull/7982

From shade at openjdk.java.net  Wed Mar 30 09:01:38 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 30 Mar 2022 09:01:38 GMT
Subject: RFR: 8283737: riscv: MacroAssembler::stop() should emit
 fixed-length instruction sequence [v4]
In-Reply-To: <Sjv9AXCASVXcQp1Tem2Mfmxn_ZELecVg_dHNNYhOU-I=.dc1395ac-8c52-4936-9c0d-3419b34769e9@github.com>
References: <SdQ6BVPC9MXxCD42wXnclX5bmDx6Ckl-1Z46axMtkkU=.0b278560-7ffe-4750-9483-ea5c31898918@github.com>
 <Sjv9AXCASVXcQp1Tem2Mfmxn_ZELecVg_dHNNYhOU-I=.dc1395ac-8c52-4936-9c0d-3419b34769e9@github.com>
Message-ID: <5mK8d7b3Y_ng-3wdeY1Hu8H09JzgzXwopQOZLSGiI4s=.eb6b8e9c-ed2d-4efb-bf86-43b18caebbff@github.com>

On Wed, 30 Mar 2022 08:53:26 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

>> Hi team,
>> 
>> Could I have a review of this simple patch? -
>> 
>> `PhaseOutput::fill_buffer` detects if the real size of a node matches (<=) the size of it in scratch_emit(). The call chain for MacroAssembler::stop() is:
>> 
>> 
>> MachEpilogNode::emit
>>     -> reserved_stack_check()
>>          -> should_not_reach_here()
>>               -> stop(const char *msg)
>> 
>> 
>> `li()` on RISCV could generate 1~6 instructions, and the msg argument could be an on-stack buffer; `stop()` also uses `__ pc()` that could also be different in `scratch_emit()` and `emit()`. They both have the potential issue here so the size generated in `MacroAssembler::stop()` needs to be a fixed value.
>> 
>> Could be reproduced in the fastdebug build by adding one line:
>> 
>> 
>> // Die now.
>> instruct ShouldNotReachHere() %{
>>   match(Halt);
>>   ins_cost(BRANCH_COST);
>>   format %{ "#@ShouldNotReachHere" %}
>>   ins_encode %{
>>     Assembler::CompressibleRegion cr(&_masm);
>>     if (is_reachable()) {
>>       __ halt();
>> +     __ unimplemented("this is an on-stack char literal");  // assertion fail at 'assert(false, "wrong size of mach node");'
>>     }
>>   %}
>>   ins_pipe(pipe_class_default);
>> %}
>> 
>> 
>> Tests passed in hotspot tier1 & jdk tier1 without new errors found.
>> 
>> Thanks,
>> Xiaolin
>
> Xiaolin Zheng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert the c.beqz commit: put it into another patch as the suggestion
>   
>   This reverts commit cd4a37b655af41f20d00b71a542b00161ff88e22.

Yes, looks good. Submit another PR for that change, and I'll approve too.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7982

From xlinzheng at openjdk.java.net  Wed Mar 30 09:01:38 2022
From: xlinzheng at openjdk.java.net (Xiaolin Zheng)
Date: Wed, 30 Mar 2022 09:01:38 GMT
Subject: RFR: 8283737: riscv: MacroAssembler::stop() should emit
 fixed-length instruction sequence [v3]
In-Reply-To: <vd5Q7bB_PfxsfnO4z2ikdBJYecmpFGzi3Jyewd7oFvI=.030fe7f0-32c8-4ed3-a553-f1cce5eb3ce1@github.com>
References: <SdQ6BVPC9MXxCD42wXnclX5bmDx6Ckl-1Z46axMtkkU=.0b278560-7ffe-4750-9483-ea5c31898918@github.com>
 <MxwYDXP63-lmhUYDRANE8_k6HXhmeSzBNY-Ebpc94Co=.7bb6097b-c4b0-456e-8248-024219c6ee3e@github.com>
 <vd5Q7bB_PfxsfnO4z2ikdBJYecmpFGzi3Jyewd7oFvI=.030fe7f0-32c8-4ed3-a553-f1cce5eb3ce1@github.com>
Message-ID: <SUaZ0EP8FKJ1n7bJHNCWnY5-2qjtqo25g7c02UwOYFk=.3066c09a-9d19-47f7-8e1c-7cb07ede61fd@github.com>

On Wed, 30 Mar 2022 07:15:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks fine. But I would rather push `c_beqz` change under a separate PR, so that the issue tracking is clean.

Thank you for the review and the quite reasonable suggestion, Aleksey. I have removed the unrelated part from this patch and the JBS issue and will put it into another patch. - 
If it looks okay for you, I would type one integrate then.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7982

From xlinzheng at openjdk.java.net  Wed Mar 30 09:04:35 2022
From: xlinzheng at openjdk.java.net (Xiaolin Zheng)
Date: Wed, 30 Mar 2022 09:04:35 GMT
Subject: RFR: 8283737: riscv: MacroAssembler::stop() should emit
 fixed-length instruction sequence [v4]
In-Reply-To: <5mK8d7b3Y_ng-3wdeY1Hu8H09JzgzXwopQOZLSGiI4s=.eb6b8e9c-ed2d-4efb-bf86-43b18caebbff@github.com>
References: <SdQ6BVPC9MXxCD42wXnclX5bmDx6Ckl-1Z46axMtkkU=.0b278560-7ffe-4750-9483-ea5c31898918@github.com>
 <Sjv9AXCASVXcQp1Tem2Mfmxn_ZELecVg_dHNNYhOU-I=.dc1395ac-8c52-4936-9c0d-3419b34769e9@github.com>
 <5mK8d7b3Y_ng-3wdeY1Hu8H09JzgzXwopQOZLSGiI4s=.eb6b8e9c-ed2d-4efb-bf86-43b18caebbff@github.com>
Message-ID: <eFKhV5BkTlfICESf64-K0WJLbe4aHbasPx7wrIfVHfc=.9d015afb-1eb0-4dc8-9524-71e6339b03a6@github.com>

On Wed, 30 Mar 2022 08:58:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Yes, looks good. Submit another PR for that change, and I'll approve too.

Thank you for the reviews Team! @RealFYang @shipilev

-------------

PR: https://git.openjdk.java.net/jdk/pull/7982

From xlinzheng at openjdk.java.net  Wed Mar 30 09:08:41 2022
From: xlinzheng at openjdk.java.net (Xiaolin Zheng)
Date: Wed, 30 Mar 2022 09:08:41 GMT
Subject: Integrated: 8283737: riscv: MacroAssembler::stop() should emit
 fixed-length instruction sequence
In-Reply-To: <SdQ6BVPC9MXxCD42wXnclX5bmDx6Ckl-1Z46axMtkkU=.0b278560-7ffe-4750-9483-ea5c31898918@github.com>
References: <SdQ6BVPC9MXxCD42wXnclX5bmDx6Ckl-1Z46axMtkkU=.0b278560-7ffe-4750-9483-ea5c31898918@github.com>
Message-ID: <kWB5HfK8wU87plIM-hyM6meKczUxrNJorkedTKitMAU=.6baefd01-ebf0-488e-8301-fba9dbac96de@github.com>

On Mon, 28 Mar 2022 04:41:11 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> Hi team,
> 
> Could I have a review of this simple patch? -
> 
> `PhaseOutput::fill_buffer` detects if the real size of a node matches (<=) the size of it in scratch_emit(). The call chain for MacroAssembler::stop() is:
> 
> 
> MachEpilogNode::emit
>     -> reserved_stack_check()
>          -> should_not_reach_here()
>               -> stop(const char *msg)
> 
> 
> `li()` on RISCV could generate 1~6 instructions, and the msg argument could be an on-stack buffer; `stop()` also uses `__ pc()` that could also be different in `scratch_emit()` and `emit()`. They both have the potential issue here so the size generated in `MacroAssembler::stop()` needs to be a fixed value.
> 
> Could be reproduced in the fastdebug build by adding one line:
> 
> 
> // Die now.
> instruct ShouldNotReachHere() %{
>   match(Halt);
>   ins_cost(BRANCH_COST);
>   format %{ "#@ShouldNotReachHere" %}
>   ins_encode %{
>     Assembler::CompressibleRegion cr(&_masm);
>     if (is_reachable()) {
>       __ halt();
> +     __ unimplemented("this is an on-stack char literal");  // assertion fail at 'assert(false, "wrong size of mach node");'
>     }
>   %}
>   ins_pipe(pipe_class_default);
> %}
> 
> 
> Tests passed in hotspot tier1 & jdk tier1 without new errors found.
> 
> Thanks,
> Xiaolin

This pull request has now been integrated.

Changeset: b82b0090
Author:    Xiaolin Zheng <xlinzheng at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b82b0090474d1873ec8a42a3bfc71de972782e78
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8283737: riscv: MacroAssembler::stop() should emit fixed-length instruction sequence

Reviewed-by: fyang, shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/7982

From xlinzheng at openjdk.java.net  Wed Mar 30 09:24:18 2022
From: xlinzheng at openjdk.java.net (Xiaolin Zheng)
Date: Wed, 30 Mar 2022 09:24:18 GMT
Subject: RFR: 8283937: riscv: RVC: Fix c_beqz to c_bnez
Message-ID: <CRuP6RY79EAY1U0zjuNbhlEbf_panxPvFqmQJ4FCQqw=.08892534-da33-4bae-b37e-97ade7cc813d@github.com>

Hi team,

As the appointment (mentioned in #7982 ), submit another PR for reviews.

This patch fixes a typo introduced in [JDK-8278994](https://bugs.openjdk.java.net/browse/JDK-8278994): `c_bnez` is mistakenly written to `c_beqz`, though not used until now, needing a fix for future usage.

Thanks,
Xiaolin

-------------

Commit messages:
 - Fix a typo instroduced when refactoring: c.beqz

Changes: https://git.openjdk.java.net/jdk/pull/8034/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8034&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283937
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8034.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8034/head:pull/8034

PR: https://git.openjdk.java.net/jdk/pull/8034

From tschatzl at openjdk.java.net  Wed Mar 30 09:28:42 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 30 Mar 2022 09:28:42 GMT
Subject: RFR: 8283494: Factor out calculation of actual number of XMM
 registers [v2]
In-Reply-To: <v2lh4gzUyt7UDCFJZS9HuF4s_yzJzaI3suRkTTXSsYg=.3b7647f4-5a2d-43a7-8bd1-fcde8075a2ca@github.com>
References: <VWzCeBhLgEcnxHs1YZ73N3w2i5G3JcJwIR_jx9HiKls=.0e645b29-1809-4f05-950b-eecabc46010f@github.com>
 <v2lh4gzUyt7UDCFJZS9HuF4s_yzJzaI3suRkTTXSsYg=.3b7647f4-5a2d-43a7-8bd1-fcde8075a2ca@github.com>
Message-ID: <GzikJmevYYd19MLem2fbsP6evHlAajfNdIteTb8z8x4=.89e4c0d1-30fb-4090-91d6-13f80090572b@github.com>

On Tue, 29 Mar 2022 22:34:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Put method implementation in hpp file
>
> src/hotspot/cpu/x86/register_x86.hpp line 169:
> 
>> 167:   // Actually available XMM registers for use, depending on actual CPU capabilities
>> 168:   // and flags.
>> 169:   static int available_xmm_registers();
> 
> Why not define function's  body here?

I do not think its use is performance critical considering its use in the surrounding code then that goes on and does something per xmm register.

There is no strong opinion from me about this, so I moved it to the hpp file. Build times do not significantly change afaict.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7917

From shade at openjdk.java.net  Wed Mar 30 09:33:39 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 30 Mar 2022 09:33:39 GMT
Subject: RFR: 8283937: riscv: RVC: Fix c_beqz to c_bnez
In-Reply-To: <CRuP6RY79EAY1U0zjuNbhlEbf_panxPvFqmQJ4FCQqw=.08892534-da33-4bae-b37e-97ade7cc813d@github.com>
References: <CRuP6RY79EAY1U0zjuNbhlEbf_panxPvFqmQJ4FCQqw=.08892534-da33-4bae-b37e-97ade7cc813d@github.com>
Message-ID: <h0a7kkm8BT7oY23EuaCLJGFhgcafLOJMrJNZ26mdpOY=.a03f5d90-9730-43d2-b8bb-f8d24e535401@github.com>

On Wed, 30 Mar 2022 09:17:14 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> Hi team,
> 
> As the appointment (mentioned in #7982 ), submit another PR for reviews.
> 
> This patch fixes a typo introduced in [JDK-8278994](https://bugs.openjdk.java.net/browse/JDK-8278994): `c_bnez` is mistakenly written to `c_beqz`, though not used until now, needing a fix for future usage.
> 
> Thanks,
> Xiaolin

Looks fine.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8034

From xlinzheng at openjdk.java.net  Wed Mar 30 09:42:39 2022
From: xlinzheng at openjdk.java.net (Xiaolin Zheng)
Date: Wed, 30 Mar 2022 09:42:39 GMT
Subject: RFR: 8283937: riscv: RVC: Fix c_beqz to c_bnez
In-Reply-To: <h0a7kkm8BT7oY23EuaCLJGFhgcafLOJMrJNZ26mdpOY=.a03f5d90-9730-43d2-b8bb-f8d24e535401@github.com>
References: <CRuP6RY79EAY1U0zjuNbhlEbf_panxPvFqmQJ4FCQqw=.08892534-da33-4bae-b37e-97ade7cc813d@github.com>
 <h0a7kkm8BT7oY23EuaCLJGFhgcafLOJMrJNZ26mdpOY=.a03f5d90-9730-43d2-b8bb-f8d24e535401@github.com>
Message-ID: <EtCKHtQECEmfLWKW-V1GbRtmf_EO6naixgRxB-kC0UI=.7e779584-4a6a-4d0e-89ce-289157ce1919@github.com>

On Wed, 30 Mar 2022 09:30:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi team,
>> 
>> As the appointment (mentioned in #7982 ), submit another PR for reviews.
>> 
>> This patch fixes a typo introduced in [JDK-8278994](https://bugs.openjdk.java.net/browse/JDK-8278994): `c_bnez` is mistakenly written to `c_beqz`, though not used until now, needing a fix for future usage.
>> 
>> Thanks,
>> Xiaolin
>
> Looks fine.

Thanks again for the review! @shipilev

-------------

PR: https://git.openjdk.java.net/jdk/pull/8034

From njian at openjdk.java.net  Wed Mar 30 09:46:40 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Wed, 30 Mar 2022 09:46:40 GMT
Subject: RFR: 8282764: AArch64:
 compiler/vectorapi/reshape/TestVectorCastNeon.java failed with incorrect
 result [v2]
In-Reply-To: <oAWO5xDZAjWAgu7bkabhzK8qT_6KE9aHs5AlnSJd6-c=.5b5add5f-384c-44bf-85ba-0f3f2ea4ceb2@github.com>
References: <5s9gVoO8BXDC9k_GYrcMupuP60CgvgvvuTwy6obPZqA=.dbbccd3f-f4f2-404f-a9f5-7b2e110cd84e@github.com>
 <tGc05DsOPxV48goBd2BQDYPCzIcyj8E1d4Yb0wp_NyU=.e11269be-1a52-48db-906b-861bf2e54998@github.com>
 <oAWO5xDZAjWAgu7bkabhzK8qT_6KE9aHs5AlnSJd6-c=.5b5add5f-384c-44bf-85ba-0f3f2ea4ceb2@github.com>
Message-ID: <w6p9NC-P9yg1ZmABTkXytx6nJ-YQd4aTYP2IlF_P5zA=.0f35af2a-5add-4416-bebd-4d9f29989915@github.com>

On Wed, 30 Mar 2022 07:55:31 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> Ningsheng Jian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment for special value usage.
>
> cpu/aarch64 changes look OK to me and the Windows x64 failure is some unrelated environment setup problem.

Thanks for the review! @nick-arm

-------------

PR: https://git.openjdk.java.net/jdk/pull/7850

From njian at openjdk.java.net  Wed Mar 30 09:50:47 2022
From: njian at openjdk.java.net (Ningsheng Jian)
Date: Wed, 30 Mar 2022 09:50:47 GMT
Subject: Integrated: 8282764: AArch64:
 compiler/vectorapi/reshape/TestVectorCastNeon.java failed with incorrect
 result
In-Reply-To: <5s9gVoO8BXDC9k_GYrcMupuP60CgvgvvuTwy6obPZqA=.dbbccd3f-f4f2-404f-a9f5-7b2e110cd84e@github.com>
References: <5s9gVoO8BXDC9k_GYrcMupuP60CgvgvvuTwy6obPZqA=.dbbccd3f-f4f2-404f-a9f5-7b2e110cd84e@github.com>
Message-ID: <dNZZMVldkgwZ95iu0SbaxtmekmJfeu-WG4MbeuAiTeY=.927904e3-8933-444e-815c-210a79353e56@github.com>

On Thu, 17 Mar 2022 04:33:59 GMT, Ningsheng Jian <njian at openjdk.org> wrote:

> Vector API long to float conversion operation on NEON converts vector of 2 longs to 2 floats. In current implementation, we convert 2 longs to 2 doubles first and then converts 2 doubles to 2 floats. However, this two-steps conversion may have two roundings, while the expected behavior, conversion from long to float directly, has only one rounding. This will result in inconsistent result. E.g. for the failure test case:
> 
> 
> jshell> long l = 0x561a524000000001L;
> l ==> 6204361871487664129
> 
> jshell> float l2f = (float)l;
> l2f ==> 6.2043621E18
> 
> jshell> float l2d2f = (float)((double)l);
> l2d2f ==> 6.2043616E18
> 
> 
> Since we don't have NEON instruction to support vector long to float conversion, we fix the codegen by doing it in scalar operation one element by one element.
> 
> TEST: vector api jtreg tests passed.

This pull request has now been integrated.

Changeset: 51c05e82
Author:    Ningsheng Jian <njian at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/51c05e8219db5f47d7f56eeb9cdaaee0785b5e7e
Stats:     51 lines in 12 files changed: 26 ins; 0 del; 25 mod

8282764: AArch64: compiler/vectorapi/reshape/TestVectorCastNeon.java failed with incorrect result

Reviewed-by: psandoz, ngasson, eliu

-------------

PR: https://git.openjdk.java.net/jdk/pull/7850

From shade at openjdk.java.net  Wed Mar 30 10:06:41 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 30 Mar 2022 10:06:41 GMT
Subject: RFR: 8283937: riscv: RVC: Fix c_beqz to c_bnez
In-Reply-To: <CRuP6RY79EAY1U0zjuNbhlEbf_panxPvFqmQJ4FCQqw=.08892534-da33-4bae-b37e-97ade7cc813d@github.com>
References: <CRuP6RY79EAY1U0zjuNbhlEbf_panxPvFqmQJ4FCQqw=.08892534-da33-4bae-b37e-97ade7cc813d@github.com>
Message-ID: <XhCyG_YVYJXt8RrBKQ0_Y64_0VmUVOX0z91zIfWtig4=.4057a60c-8e02-4269-b454-8f5830a6f9f7@github.com>

On Wed, 30 Mar 2022 09:17:14 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> Hi team,
> 
> As the appointment (mentioned in #7982 ), submit another PR for reviews.
> 
> This patch fixes a typo introduced in [JDK-8278994](https://bugs.openjdk.java.net/browse/JDK-8278994): `c_bnez` is mistakenly written to `c_beqz`, though not used until now, needing a fix for future usage.
> 
> Thanks,
> Xiaolin

The affected instruction does not seem to be used anywhere, and the change is trivially correct. I'll sponsor now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8034

From xlinzheng at openjdk.java.net  Wed Mar 30 10:06:41 2022
From: xlinzheng at openjdk.java.net (Xiaolin Zheng)
Date: Wed, 30 Mar 2022 10:06:41 GMT
Subject: Integrated: 8283937: riscv: RVC: Fix c_beqz to c_bnez
In-Reply-To: <CRuP6RY79EAY1U0zjuNbhlEbf_panxPvFqmQJ4FCQqw=.08892534-da33-4bae-b37e-97ade7cc813d@github.com>
References: <CRuP6RY79EAY1U0zjuNbhlEbf_panxPvFqmQJ4FCQqw=.08892534-da33-4bae-b37e-97ade7cc813d@github.com>
Message-ID: <8MDAg6r9P3oamygBTOh7RhmH706hY4JhzltB5-PClqo=.af58dddd-d88e-4265-aa18-81fb0d19a024@github.com>

On Wed, 30 Mar 2022 09:17:14 GMT, Xiaolin Zheng <xlinzheng at openjdk.org> wrote:

> Hi team,
> 
> As the appointment (mentioned in #7982 ), submit another PR for reviews.
> 
> This patch fixes a typo introduced in [JDK-8278994](https://bugs.openjdk.java.net/browse/JDK-8278994): `c_bnez` is mistakenly written to `c_beqz`, though not used until now, needing a fix for future usage.
> 
> Thanks,
> Xiaolin

This pull request has now been integrated.

Changeset: 720e751f
Author:    Xiaolin Zheng <xlinzheng at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/720e751f35150251cab05bc9fca3add39daf70af
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8283937: riscv: RVC: Fix c_beqz to c_bnez

Reviewed-by: shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/8034

From rcastanedalo at openjdk.java.net  Wed Mar 30 11:50:10 2022
From: rcastanedalo at openjdk.java.net (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Wed, 30 Mar 2022 11:50:10 GMT
Subject: RFR: 8282043: IGV: speed up schedule approximation
Message-ID: <keRZXZ5lfMvnXhehvfU1D3mTpM-CiIxiKS_C0BJOFQI=.c2c00f46-064b-4089-8b24-bdd48f538c3e@github.com>

Schedule approximation for building the _clustered sea-of-nodes_ and _control-flow graph_ views is an expensive computation that can sometimes take as much time as computing the layout of the graph itself. This change removes the main bottleneck in schedule approximation by computing common dominators on-demand instead of pre-computing them.

Pre-computation of common dominators requires _(no. blocks)^2_ calls to `getCommonDominator()`. On-demand computation requires, in the worst case, _(no. Ideal nodes)^2_ calls, but in practice the number of calls is linear due to the sparseness of the Ideal graph, and the change speeds up scheduling by more than an order of magnitude (see details below).

#### Testing

##### Functionality

- Tested manually the approximated schedule on a small selection of graphs.

- Tested automatically that scheduling and viewing thousands of graphs in the _clustered sea-of-nodes_ and _control-flow graph_ views does not trigger any assertion failure (by instrumenting IGV to schedule and view graphs as they are loaded and running `java -Xcomp -XX:-TieredCompilation -XX:PrintIdealGraphLevel=4`).

##### Performance

 Measured the scheduling time for a selection of 100 large graphs (2511-7329 nodes). On average, this change speeds up scheduling by more than an order of magnitude (15x), where the largest improvements are seen on the largest graphs. The performance results are [attached](https://github.com/openjdk/jdk/files/8380091/performance-evaluation.ods) (note that each measurement in the sheet corresponds to the median of ten runs).

-------------

Commit messages:
 - Do not precompute common dominators

Changes: https://git.openjdk.java.net/jdk/pull/8037/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8037&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8282043
  Stats: 24 lines in 1 file changed: 0 ins; 22 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8037.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8037/head:pull/8037

PR: https://git.openjdk.java.net/jdk/pull/8037

From thartmann at openjdk.java.net  Wed Mar 30 11:55:07 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 30 Mar 2022 11:55:07 GMT
Subject: RFR: 8283997: Unused argument in GraphKit::builtin_throw
Message-ID: <3nWtLT79gwqK--J7bzNg5t9dNdd1rU_kgnEG_jJIvOw=.0a5a7e8a-8a8e-4e3b-812f-5e4284b5ffa9@github.com>

Trivial fix that removes an unused argument and adjust a comment accordingly.

Thanks,
Tobias

-------------

Commit messages:
 - 8283997: Unused argument in GraphKit::builtin_throw

Changes: https://git.openjdk.java.net/jdk/pull/8038/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8038&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283997
  Stats: 7 lines in 2 files changed: 0 ins; 4 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8038/head:pull/8038

PR: https://git.openjdk.java.net/jdk/pull/8038

From roland at openjdk.java.net  Wed Mar 30 12:01:39 2022
From: roland at openjdk.java.net (Roland Westrelin)
Date: Wed, 30 Mar 2022 12:01:39 GMT
Subject: RFR: 8283997: Unused argument in GraphKit::builtin_throw
In-Reply-To: <3nWtLT79gwqK--J7bzNg5t9dNdd1rU_kgnEG_jJIvOw=.0a5a7e8a-8a8e-4e3b-812f-5e4284b5ffa9@github.com>
References: <3nWtLT79gwqK--J7bzNg5t9dNdd1rU_kgnEG_jJIvOw=.0a5a7e8a-8a8e-4e3b-812f-5e4284b5ffa9@github.com>
Message-ID: <-dHmrNhDKJdt8jQcuw6NwxxD6b9XCAjddkqXmHz86cg=.05068ca5-5f47-48ca-a228-098f0e258bff@github.com>

On Wed, 30 Mar 2022 11:48:28 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Trivial fix that removes an unused argument and adjust a comment accordingly.
> 
> Thanks,
> Tobias

Looks good.

-------------

Marked as reviewed by roland (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8038

From redestad at openjdk.java.net  Wed Mar 30 12:05:39 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 30 Mar 2022 12:05:39 GMT
Subject: RFR: 8283997: Unused argument in GraphKit::builtin_throw
In-Reply-To: <3nWtLT79gwqK--J7bzNg5t9dNdd1rU_kgnEG_jJIvOw=.0a5a7e8a-8a8e-4e3b-812f-5e4284b5ffa9@github.com>
References: <3nWtLT79gwqK--J7bzNg5t9dNdd1rU_kgnEG_jJIvOw=.0a5a7e8a-8a8e-4e3b-812f-5e4284b5ffa9@github.com>
Message-ID: <wVvm5YxZbtud0eTY9Fms4iwHp-hEku6Zy8FjvPR3Py8=.46797038-7615-45ca-a0f2-543f76f2812e@github.com>

On Wed, 30 Mar 2022 11:48:28 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Trivial fix that removes an unused argument and adjust a comment accordingly.
> 
> Thanks,
> Tobias

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8038

From chagedorn at openjdk.java.net  Wed Mar 30 12:21:41 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 30 Mar 2022 12:21:41 GMT
Subject: RFR: 8283997: Unused argument in GraphKit::builtin_throw
In-Reply-To: <3nWtLT79gwqK--J7bzNg5t9dNdd1rU_kgnEG_jJIvOw=.0a5a7e8a-8a8e-4e3b-812f-5e4284b5ffa9@github.com>
References: <3nWtLT79gwqK--J7bzNg5t9dNdd1rU_kgnEG_jJIvOw=.0a5a7e8a-8a8e-4e3b-812f-5e4284b5ffa9@github.com>
Message-ID: <WzGsdoWVqqp0toV7aus68m62Mm_uV8dug-VR3dggyX4=.c33bf469-3e51-4e79-9ca9-efd725a0b96a@github.com>

On Wed, 30 Mar 2022 11:48:28 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Trivial fix that removes an unused argument and adjust a comment accordingly.
> 
> Thanks,
> Tobias

<empty>

-------------

Changes requested by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8038

From thartmann at openjdk.java.net  Wed Mar 30 12:21:41 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 30 Mar 2022 12:21:41 GMT
Subject: RFR: 8283997: Unused argument in GraphKit::builtin_throw
In-Reply-To: <3nWtLT79gwqK--J7bzNg5t9dNdd1rU_kgnEG_jJIvOw=.0a5a7e8a-8a8e-4e3b-812f-5e4284b5ffa9@github.com>
References: <3nWtLT79gwqK--J7bzNg5t9dNdd1rU_kgnEG_jJIvOw=.0a5a7e8a-8a8e-4e3b-812f-5e4284b5ffa9@github.com>
Message-ID: <kLziNKVoQMI2lxcJ0gJbvaVytOGXijIJVAQH3GVs29w=.7e94295c-839c-4d59-add7-ec6cb5bfd38a@github.com>

On Wed, 30 Mar 2022 11:48:28 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Trivial fix that removes an unused argument and adjust a comment accordingly.
> 
> Thanks,
> Tobias

Roland, Claes, thanks for the quick reviews!

Just noticed that I forgot to push the changes in the calling methods.

-------------

PR: https://git.openjdk.java.net/jdk/pull/8038

From thartmann at openjdk.java.net  Wed Mar 30 12:26:23 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 30 Mar 2022 12:26:23 GMT
Subject: RFR: 8283997: Unused argument in GraphKit::builtin_throw [v2]
In-Reply-To: <3nWtLT79gwqK--J7bzNg5t9dNdd1rU_kgnEG_jJIvOw=.0a5a7e8a-8a8e-4e3b-812f-5e4284b5ffa9@github.com>
References: <3nWtLT79gwqK--J7bzNg5t9dNdd1rU_kgnEG_jJIvOw=.0a5a7e8a-8a8e-4e3b-812f-5e4284b5ffa9@github.com>
Message-ID: <RBGt0hfhrbddoTJ1Glvb0wA5bf0b0FEMDO5zWTlPLV8=.a5039a5b-2706-4714-9e39-1e292d64ca65@github.com>

> Trivial fix that removes an unused argument and adjust a comment accordingly.
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Adjusting callers

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8038/files
  - new: https://git.openjdk.java.net/jdk/pull/8038/files/3cb8750c..fb796f0a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8038&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8038&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8038.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8038/head:pull/8038

PR: https://git.openjdk.java.net/jdk/pull/8038

From thartmann at openjdk.java.net  Wed Mar 30 12:26:24 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 30 Mar 2022 12:26:24 GMT
Subject: RFR: 8283997: Unused argument in GraphKit::builtin_throw
In-Reply-To: <3nWtLT79gwqK--J7bzNg5t9dNdd1rU_kgnEG_jJIvOw=.0a5a7e8a-8a8e-4e3b-812f-5e4284b5ffa9@github.com>
References: <3nWtLT79gwqK--J7bzNg5t9dNdd1rU_kgnEG_jJIvOw=.0a5a7e8a-8a8e-4e3b-812f-5e4284b5ffa9@github.com>
Message-ID: <Adyaug3NQyWSU-B34DRrt4aNgV2sT2Kf76wLLAwPcsE=.fe23dedb-f7bc-493e-b2aa-0674b29e6d6f@github.com>

On Wed, 30 Mar 2022 11:48:28 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Trivial fix that removes an unused argument and adjust a comment accordingly.
> 
> Thanks,
> Tobias

Fixed :)

-------------

PR: https://git.openjdk.java.net/jdk/pull/8038

From redestad at openjdk.java.net  Wed Mar 30 12:28:15 2022
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 30 Mar 2022 12:28:15 GMT
Subject: RFR: 8283997: Unused argument in GraphKit::builtin_throw [v2]
In-Reply-To: <RBGt0hfhrbddoTJ1Glvb0wA5bf0b0FEMDO5zWTlPLV8=.a5039a5b-2706-4714-9e39-1e292d64ca65@github.com>
References: <3nWtLT79gwqK--J7bzNg5t9dNdd1rU_kgnEG_jJIvOw=.0a5a7e8a-8a8e-4e3b-812f-5e4284b5ffa9@github.com>
 <RBGt0hfhrbddoTJ1Glvb0wA5bf0b0FEMDO5zWTlPLV8=.a5039a5b-2706-4714-9e39-1e292d64ca65@github.com>
Message-ID: <iCAhBqWbG2RBjKZuNqR02leWTvMWLdm2XDo_wICJVnM=.a05f0d00-ccee-4cd3-b5a4-717e95c9274c@github.com>

On Wed, 30 Mar 2022 12:26:23 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Trivial fix that removes an unused argument and adjust a comment accordingly.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusting callers

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8038

From fparain at openjdk.java.net  Wed Mar 30 12:38:59 2022
From: fparain at openjdk.java.net (Frederic Parain)
Date: Wed, 30 Mar 2022 12:38:59 GMT
Subject: RFR: 8283890: Changes in CFG file format break C1Visualizer
Message-ID: <_jDDHXKQOqAZHsbX4M1aMKMyPiyOT8IRZ51zD9AC3ls=.9ed1bf78-8921-47a2-9051-ab9c40ec0065@github.com>

Please review this small fix reverting a change in the format of the CFG log file which prevent those files from being loaded by the C1Visualizer tool.

Thank you,

Fred

-------------

Commit messages:
 - Fix CFG file format

Changes: https://git.openjdk.java.net/jdk/pull/8041/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8041&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8283890
  Stats: 4 lines in 1 file changed: 1 ins; 3 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8041.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8041/head:pull/8041

PR: https://git.openjdk.java.net/jdk/pull/8041

From aph at openjdk.java.net  Wed Mar 30 13:36:35 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 30 Mar 2022 13:36:35 GMT
Subject: RFR: 8282875: AArch64: [vectorapi] Optimize Vector.reduceLane for
 SVE 64/128 vector size
In-Reply-To: <6KkmSzP3na8JUnMFh3Yfzm6yuzk1EWr1LORhDLDPxRM=.c4bf6878-3964-4b9e-9225-f0fe3da1fc16@github.com>
References: <6KkmSzP3na8JUnMFh3Yfzm6yuzk1EWr1LORhDLDPxRM=.c4bf6878-3964-4b9e-9225-f0fe3da1fc16@github.com>
Message-ID: <WOhqs1je4kbTxpVAKdge5WV69saIc6kYogDcRbTaPww=.aa3cd9bd-9801-4968-85c5-21fa4f45ec28@github.com>

On Mon, 28 Mar 2022 16:39:08 GMT, Eric Liu <eliu at openjdk.org> wrote:

> This patch speeds up add/mul/min/max reductions for SVE for 64/128
> vector size.
> 
> According to Neoverse N2/V1 software optimization guide[1][2], for
> 128-bit vector size reduction operations, we prefer using NEON
> instructions instead of SVE instructions. This patch adds some rules to
> distinguish 64/128 bits vector size with others, so that for these two
> special cases, they can generate code the same as NEON. E.g., For
> ByteVector.SPECIES_128, "ByteVector.reduceLanes(VectorOperators.ADD)"
> generates code as below:
> 
> 
>         Before:
>         uaddv   d17, p0, z16.b
>         smov    x15, v17.b[0]
>         add     w15, w14, w15, sxtb
> 
>         After:
>         addv    b17, v16.16b
>         smov    x12, v17.b[0]
>         add     w12, w12, w16, sxtb
> 
> No multiply reduction instruction in SVE, this patch generates code for
> MulReductionVL by using scalar insnstructions for 128-bit vector size.
> 
> With this patch, all of them have performance gain for specific vector
> micro benchmarks in my SVE testing system.
> 
> [1] https://developer.arm.com/documentation/pjdoc466751330-9685/latest/
> [2] https://developer.arm.com/documentation/PJDOC-466751330-18256/0001
> 
> Change-Id: I4bef0b3eb6ad1bac582e4236aef19787ccbd9b1c

Please include the benchmarks in this patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7999

From ngasson at openjdk.java.net  Wed Mar 30 14:19:46 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 30 Mar 2022 14:19:46 GMT
Subject: RFR: 8282926: AArch64: Optimize out WHILELO with PTRUE
In-Reply-To: <eiqjLHtDLFDiGzOv5r5soUA5j70X71nYhyCcJ5JgYrI=.2762d722-06d3-469f-811e-f10096278a6b@github.com>
References: <eiqjLHtDLFDiGzOv5r5soUA5j70X71nYhyCcJ5JgYrI=.2762d722-06d3-469f-811e-f10096278a6b@github.com>
Message-ID: <MJHPSayYQ4mcM8e9moHqBBPHP31DYbb-tTdoqr5AU3I=.8591f0c7-41de-493d-bff7-dc9bc0d4474d@github.com>

On Fri, 11 Mar 2022 10:40:00 GMT, Eric Liu <eliu at openjdk.org> wrote:

> This patch uses PTRUE instruction instead of WHILELO instruction to
> create vector masks for certain length. It would be more efficient than
> WHILELO instruction according to the software optimization guide of
> Neoverse N2[1], Neoverse V1[2], and A64FX[3].
> 
> The final code changes as shown below:
> 
> Before:
> 
>     0x0000ffff6d4747b4:   orr     x8, xzr, #0x10
>     0x0000ffff6d4747b8:   whilelo p0.b, xzr, x8
> 
> After:
> 
>     0x0000ffff89476aec:   ptrue   p0.b, vl16
> 
> The micro benchmark improves 15% ~ 20% in my SVE test system.
> 
> [TEST]
> jdk/incubator/vector, hotspot/compiler/vectorapi passed on my SVE test
> machine.
> 
> [1] https://developer.arm.com/documentation/PJDOC-466751330-18256/0001
> [2] https://developer.arm.com/documentation/pjdoc466751330-9685/latest/
> [3] https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_Microarchitecture_Manual_en_1.6.pdf

Marked as reviewed by ngasson (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/7786

From chagedorn at openjdk.java.net  Wed Mar 30 14:23:38 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 30 Mar 2022 14:23:38 GMT
Subject: RFR: 8283890: Changes in CFG file format break C1Visualizer
In-Reply-To: <_jDDHXKQOqAZHsbX4M1aMKMyPiyOT8IRZ51zD9AC3ls=.9ed1bf78-8921-47a2-9051-ab9c40ec0065@github.com>
References: <_jDDHXKQOqAZHsbX4M1aMKMyPiyOT8IRZ51zD9AC3ls=.9ed1bf78-8921-47a2-9051-ab9c40ec0065@github.com>
Message-ID: <M4Lk3ORX6rHA_HFkApzikDJQ7qs8vmVYcrJTTjdr5y8=.10545c55-2821-4093-83c6-1db86cc9e19c@github.com>

On Wed, 30 Mar 2022 12:32:42 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this small fix reverting a change in the format of the CFG log file which prevent those files from being loaded by the C1Visualizer tool.
> 
> Thank you,
> 
> Fred

Looks good, thanks for fixing this! I also already ran into this problem recently.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8041

From chagedorn at openjdk.java.net  Wed Mar 30 14:27:38 2022
From: chagedorn at openjdk.java.net (Christian Hagedorn)
Date: Wed, 30 Mar 2022 14:27:38 GMT
Subject: RFR: 8283997: Unused argument in GraphKit::builtin_throw [v2]
In-Reply-To: <RBGt0hfhrbddoTJ1Glvb0wA5bf0b0FEMDO5zWTlPLV8=.a5039a5b-2706-4714-9e39-1e292d64ca65@github.com>
References: <3nWtLT79gwqK--J7bzNg5t9dNdd1rU_kgnEG_jJIvOw=.0a5a7e8a-8a8e-4e3b-812f-5e4284b5ffa9@github.com>
 <RBGt0hfhrbddoTJ1Glvb0wA5bf0b0FEMDO5zWTlPLV8=.a5039a5b-2706-4714-9e39-1e292d64ca65@github.com>
Message-ID: <VNmzIBFZC4vS6XcX5177gSJBYM8MV4X7qEXy4_jP_fY=.2e105d2a-0a69-4561-8b7b-5a88854b2834@github.com>

On Wed, 30 Mar 2022 12:26:23 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Trivial fix that removes an unused argument and adjust a comment accordingly.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusting callers

Marked as reviewed by chagedorn (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/8038

From thartmann at openjdk.java.net  Wed Mar 30 14:42:38 2022
From: thartmann at openjdk.java.net (Tobias Hartmann)
Date: Wed, 30 Mar 2022 14:42:38 GMT
Subject: RFR: 8283890: Changes in CFG file format break C1Visualizer
In-Reply-To: <_jDDHXKQOqAZHsbX4M1aMKMyPiyOT8IRZ51zD9AC3ls=.9ed1bf78-8921-47a2-9051-ab9c40ec0065@github.com>
References: <_jDDHXKQOqAZHsbX4M1aMKMyPiyOT8IRZ51zD9AC3ls=.9ed1bf78-8921-47a2-9051-ab9c40ec0065@github.com>
Message-ID: <iIPV1F6wemGfHANUTrM9-MsrnubNxlQ2dY53BBA7uIQ=.0f8ce664-40b3-4f37-9678-674b84e9fc6d@github.com>

On Wed, 30 Mar 2022 12:32:42 GMT, Frederic Parain <fparain at openjdk.org> wrote:

> Please review this small fix reverting a change in the format of the CFG log file which prevent those files from being loaded by the C1Visualizer tool.
> 
> Thank you,
> 
> Fred

Looks good.

-------------

Marked as reviewed by thartmann (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8041

From eliu at openjdk.java.net  Wed Mar 30 14:55:38 2022
From: eliu at openjdk.java.net (Eric Liu)
Date: Wed, 30 Mar 2022 14:55:38 GMT
Subject: RFR: 8282875: AArch64: [vectorapi] Optimize Vector.reduceLane for
 SVE 64/128 vector size
In-Reply-To: <WOhqs1je4kbTxpVAKdge5WV69saIc6kYogDcRbTaPww=.aa3cd9bd-9801-4968-85c5-21fa4f45ec28@github.com>
References: <6KkmSzP3na8JUnMFh3Yfzm6yuzk1EWr1LORhDLDPxRM=.c4bf6878-3964-4b9e-9225-f0fe3da1fc16@github.com>
 <WOhqs1je4kbTxpVAKdge5WV69saIc6kYogDcRbTaPww=.aa3cd9bd-9801-4968-85c5-21fa4f45ec28@github.com>
Message-ID: <heI-gH-tUgUMHX4SdlB0ZX57VYEObhcLB5mW45_6PPM=.ae43e2e9-8104-489d-9e31-5f0f3aa7e577@github.com>

On Wed, 30 Mar 2022 13:33:20 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Please include the benchmarks in this patch.

We tested with the benchmarks in the vectorIntrinsics branch of openjdk/panama-vector, e.g, Byte128Vector.ADDLanes[1], Byte128Vector.MINLanes[2], Byte128Vector.MAXLanes[3], Byte128Vector.MULLanes[4]. Currently they are not in JDK main-line. I'm not sure if it's necessary to rewrite the same code for this tests in this patch.

[1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1022
[2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1086
[3] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1118
[4] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1054

-------------

PR: https://git.openjdk.java.net/jdk/pull/7999

From eliu at openjdk.java.net  Wed Mar 30 15:02:38 2022
From: eliu at openjdk.java.net (Eric Liu)
Date: Wed, 30 Mar 2022 15:02:38 GMT
Subject: Integrated: 8282926: AArch64: Optimize out WHILELO with PTRUE
In-Reply-To: <eiqjLHtDLFDiGzOv5r5soUA5j70X71nYhyCcJ5JgYrI=.2762d722-06d3-469f-811e-f10096278a6b@github.com>
References: <eiqjLHtDLFDiGzOv5r5soUA5j70X71nYhyCcJ5JgYrI=.2762d722-06d3-469f-811e-f10096278a6b@github.com>
Message-ID: <7CMWOCPm89M7Sk_Cuwllvqx7QXHYSBMu2Rjp5-HNyRU=.5a31b7d0-f29d-4769-9a86-ec2c78368817@github.com>

On Fri, 11 Mar 2022 10:40:00 GMT, Eric Liu <eliu at openjdk.org> wrote:

> This patch uses PTRUE instruction instead of WHILELO instruction to
> create vector masks for certain length. It would be more efficient than
> WHILELO instruction according to the software optimization guide of
> Neoverse N2[1], Neoverse V1[2], and A64FX[3].
> 
> The final code changes as shown below:
> 
> Before:
> 
>     0x0000ffff6d4747b4:   orr     x8, xzr, #0x10
>     0x0000ffff6d4747b8:   whilelo p0.b, xzr, x8
> 
> After:
> 
>     0x0000ffff89476aec:   ptrue   p0.b, vl16
> 
> The micro benchmark improves 15% ~ 20% in my SVE test system.
> 
> [TEST]
> jdk/incubator/vector, hotspot/compiler/vectorapi passed on my SVE test
> machine.
> 
> [1] https://developer.arm.com/documentation/PJDOC-466751330-18256/0001
> [2] https://developer.arm.com/documentation/pjdoc466751330-9685/latest/
> [3] https://github.com/fujitsu/A64FX/blob/master/doc/A64FX_Microarchitecture_Manual_en_1.6.pdf

This pull request has now been integrated.

Changeset: e8e9b8dc
Author:    Eric Liu <eliu at openjdk.org>
Committer: Nick Gasson <ngasson at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e8e9b8dc89059b606d16ba950f0d7e57185151e7
Stats:     174 lines in 3 files changed: 0 ins; 71 del; 103 mod

8282926: AArch64: Optimize out WHILELO with PTRUE

Reviewed-by: njian, ngasson

-------------

PR: https://git.openjdk.java.net/jdk/pull/7786

From ngasson at openjdk.java.net  Wed Mar 30 15:18:42 2022
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 30 Mar 2022 15:18:42 GMT
Subject: RFR: 8282182: Document algorithm used to encode aarch64 logical
 immediate operands. [v3]
In-Reply-To: <_mcHOjaHB3O6M6B9vFnu6d-SWwTNu14mX2-iVAHYKz4=.2e9b79d3-fe2f-45b0-9942-48eccb1cfa11@github.com>
References: <dd7y8tkaDFRy7OQGykzQ_to0zAgexVv7_KvaVIlqF2U=.22a2870d-928a-47c1-93fe-0ede3f22293e@github.com>
 <_mcHOjaHB3O6M6B9vFnu6d-SWwTNu14mX2-iVAHYKz4=.2e9b79d3-fe2f-45b0-9942-48eccb1cfa11@github.com>
Message-ID: <0_aLcGUmvG6Vx3UVyb6ruGqUGePpArszPuoh0SHyuGQ=.394a5087-5349-44c8-80f3-9c3f5ddd3edd@github.com>

On Mon, 21 Feb 2022 13:15:34 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> This *documentation only* change explains how logical immediate mask values are derived from valid logical instruction operands. The encoding function is used to populate a sparse array that maps valid masks to a unique set of input operand values and a reverse lookup array that maps inputs to the associated mask.
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include unsaved changes

src/hotspot/cpu/aarch64/immediate_aarch64.cpp line 197:

> 195: // derivation of k and p and validity checks:
> 196: //
> 197: // when immN is 1 then k == 6 and immr/imms are masked to 6 bit

There's a comment below "looks like 7 given the spec above but this cannot be!" - which spec is that referring to?

-------------

PR: https://git.openjdk.java.net/jdk/pull/7536

From aph at openjdk.java.net  Wed Mar 30 15:56:36 2022
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 30 Mar 2022 15:56:36 GMT
Subject: RFR: 8282875: AArch64: [vectorapi] Optimize Vector.reduceLane for
 SVE 64/128 vector size
In-Reply-To: <6KkmSzP3na8JUnMFh3Yfzm6yuzk1EWr1LORhDLDPxRM=.c4bf6878-3964-4b9e-9225-f0fe3da1fc16@github.com>
References: <6KkmSzP3na8JUnMFh3Yfzm6yuzk1EWr1LORhDLDPxRM=.c4bf6878-3964-4b9e-9225-f0fe3da1fc16@github.com>
Message-ID: <RlOpEAWfQUlS5zUNYo4Nos8GA3wnMXLwND1Ge4DSInA=.e07f3433-1e16-4e97-8dc4-52d8566bfa03@github.com>

On Mon, 28 Mar 2022 16:39:08 GMT, Eric Liu <eliu at openjdk.org> wrote:

> This patch speeds up add/mul/min/max reductions for SVE for 64/128
> vector size.
> 
> According to Neoverse N2/V1 software optimization guide[1][2], for
> 128-bit vector size reduction operations, we prefer using NEON
> instructions instead of SVE instructions. This patch adds some rules to
> distinguish 64/128 bits vector size with others, so that for these two
> special cases, they can generate code the same as NEON. E.g., For
> ByteVector.SPECIES_128, "ByteVector.reduceLanes(VectorOperators.ADD)"
> generates code as below:
> 
> 
>         Before:
>         uaddv   d17, p0, z16.b
>         smov    x15, v17.b[0]
>         add     w15, w14, w15, sxtb
> 
>         After:
>         addv    b17, v16.16b
>         smov    x12, v17.b[0]
>         add     w12, w12, w16, sxtb
> 
> No multiply reduction instruction in SVE, this patch generates code for
> MulReductionVL by using scalar insnstructions for 128-bit vector size.
> 
> With this patch, all of them have performance gain for specific vector
> micro benchmarks in my SVE testing system.
> 
> [1] https://developer.arm.com/documentation/pjdoc466751330-9685/latest/
> [2] https://developer.arm.com/documentation/PJDOC-466751330-18256/0001
> 
> Change-Id: I4bef0b3eb6ad1bac582e4236aef19787ccbd9b1c

On 3/30/22 15:52, Eric Liu wrote:
> We tested with the benchmarks in the vectorIntrinsics branch of openjdk/panama-vector, e.g, Byte128Vector.ADDLanes[1], Byte128Vector.MINLanes[2], Byte128Vector.MAXLanes[3], Byte128Vector.MULLanes[4]. Currently they are not in JDK main-line. I'm not sure if it's necessary to rewrite the same code for this tests in this patch.

Oh, I see. Sorry for the noise.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7999

From kvn at openjdk.java.net  Wed Mar 30 17:00:39 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 30 Mar 2022 17:00:39 GMT
Subject: RFR: 8283422: Create a new test for JDK-8254790 [v4]
In-Reply-To: <Hv14ENxfjEfYrWC_6BhOykIdwv4JdEC_E81DILqCz9U=.71a5fa31-6b03-44dd-9b9b-0e93203e6697@github.com>
References: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
 <Hv14ENxfjEfYrWC_6BhOykIdwv4JdEC_E81DILqCz9U=.71a5fa31-6b03-44dd-9b9b-0e93203e6697@github.com>
Message-ID: <ujqLbEcO55E10S3Yo0HK6pJU4se2XC0DcSv3FXz5TU8=.657ca32b-cc18-45ef-becd-c7f49186efaa@github.com>

On Wed, 30 Mar 2022 07:03:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The [JDK-8254790](https://bugs.openjdk.java.net/browse/JDK-8254790) initially was reported on macOS.
>> It was found by the "javax/xml/crypto/dsig/GenerationTests.java" test which for some reason worked fine on Linux/Windows most? of the time.
>> 
>> I tried to run that test on Linux/Windows many times on a few systems and it always pass. Also, I got the same result for the tier1...tier4 tests.
>> 
>> I have found that the easiest way to reproduce the crash is to pass the result of the string.indexOf to the str.charAt when the heap is big enough. The test below[1] trigger the crash 1000 time in a row on win/lin on systems I have tested.
>> 
>> I am not sure what is the best way to contribute to the test, should I create a stand-alone test like[1], or update an existing test as I did for the first version of this PR?
>> 
>> [1]:
>> 
>> package compiler.intrinsics.string;
>> 
>> import static jdk.test.lib.Asserts.assertTrue;
>> 
>> public final class TestStringIndexOfLargeHeap {
>>     static final int[] data = new int[Integer.MAX_VALUE / 2];
>>     public static void main(String[] args) throws Exception {
>>         test('a');
>>         test('\ubeef');
>>     }
>>     private static void test(char ch) {
>>         String str = ("0123456789" + ch).repeat(100);
>>         for (int i = 0; i < 1_000_000; ++i) {
>>             assertTrue(ch == str.charAt(str.indexOf(ch)));
>>         }
>>     }
>> }
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add resourcehogs/compiler  to the hotspot_slow_compiler

I agree with your proposed test configuration. Let me test it before approval.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7883

From kvn at openjdk.java.net  Wed Mar 30 17:31:41 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 30 Mar 2022 17:31:41 GMT
Subject: RFR: 8283494: Factor out calculation of actual number of XMM
 registers [v2]
In-Reply-To: <6bTFyyxs88dyy8zMP0VDc0DRQilIL1Epv5lh6lOaer0=.7155cc98-2c22-41ce-ac38-b71aef78bae2@github.com>
References: <VWzCeBhLgEcnxHs1YZ73N3w2i5G3JcJwIR_jx9HiKls=.0e645b29-1809-4f05-950b-eecabc46010f@github.com>
 <6bTFyyxs88dyy8zMP0VDc0DRQilIL1Epv5lh6lOaer0=.7155cc98-2c22-41ce-ac38-b71aef78bae2@github.com>
Message-ID: <OZyKUTV_dzLdnz2aOj_rLdGdukMZmxDxM8yGLElp0Ik=.d28e4d7f-1ff7-457d-b024-99db98dd3aed@github.com>

On Wed, 30 Mar 2022 08:51:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for this change that factors out calculation of the actually available number of XMM registers on a given processor/given command line options into a method and reuse that as much as possible?
>> 
>> This relates to this code snippet:
>> 
>>       int xmm_bypass_limit = FrameMap::nof_xmm_regs;
>> #ifdef _LP64
>>       if (UseAVX < 3) {
>>         xmm_bypass_limit = xmm_bypass_limit / 2;
>>       }
>> #endif
>> 
>> 
>> Also, there is already the method `FrameMap::get_num_caller_save_xmms()` that has been updated to use that new method `XMMRegisterImpl::available_xmm_registers()`; further I tried to appropriately use `FrameMap::get_num_caller_save_xmms` in the places where either would work. Please have a look in particular about that.
>> 
>> I did not change strange to me variable names like `xmm_bypass_limit` above as they probably make some sense to somebody as it's used quite often.
>> 
>> This also fixes a compilation error without configuring C1 introduced with [JDK-8283327](https://bugs.openjdk.java.net/browse/JDK-8283327).
>> 
>> Testing: tier1-5 (all but linux-aarch64 done), gha, local compilation with `configure --with-features=-compiler1`.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Put method implementation in hpp file

Good.

In 32-bit VM it would just one instruction when inlined.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7917

From kvn at openjdk.java.net  Wed Mar 30 18:17:34 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 30 Mar 2022 18:17:34 GMT
Subject: RFR: 8283422: Create a new test for JDK-8254790 [v4]
In-Reply-To: <Hv14ENxfjEfYrWC_6BhOykIdwv4JdEC_E81DILqCz9U=.71a5fa31-6b03-44dd-9b9b-0e93203e6697@github.com>
References: <zTG70EH5IT-WK9Wt2lVNCjiqxMBkhmfG61LWsPtv4qA=.ea664711-b159-4a62-89e0-4fe8d061769b@github.com>
 <Hv14ENxfjEfYrWC_6BhOykIdwv4JdEC_E81DILqCz9U=.71a5fa31-6b03-44dd-9b9b-0e93203e6697@github.com>
Message-ID: <vWe5W-usp11x9I8hQRSa5xFqvvlUMprEsfCuWmiTCa4=.16388468-83a6-4941-864a-a82fd44708c7@github.com>

On Wed, 30 Mar 2022 07:03:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The [JDK-8254790](https://bugs.openjdk.java.net/browse/JDK-8254790) initially was reported on macOS.
>> It was found by the "javax/xml/crypto/dsig/GenerationTests.java" test which for some reason worked fine on Linux/Windows most? of the time.
>> 
>> I tried to run that test on Linux/Windows many times on a few systems and it always pass. Also, I got the same result for the tier1...tier4 tests.
>> 
>> I have found that the easiest way to reproduce the crash is to pass the result of the string.indexOf to the str.charAt when the heap is big enough. The test below[1] trigger the crash 1000 time in a row on win/lin on systems I have tested.
>> 
>> I am not sure what is the best way to contribute to the test, should I create a stand-alone test like[1], or update an existing test as I did for the first version of this PR?
>> 
>> [1]:
>> 
>> package compiler.intrinsics.string;
>> 
>> import static jdk.test.lib.Asserts.assertTrue;
>> 
>> public final class TestStringIndexOfLargeHeap {
>>     static final int[] data = new int[Integer.MAX_VALUE / 2];
>>     public static void main(String[] args) throws Exception {
>>         test('a');
>>         test('\ubeef');
>>     }
>>     private static void test(char ch) {
>>         String str = ("0123456789" + ch).repeat(100);
>>         for (int i = 0; i < 1_000_000; ++i) {
>>             assertTrue(ch == str.charAt(str.indexOf(ch)));
>>         }
>>     }
>> }
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add resourcehogs/compiler  to the hotspot_slow_compiler

Testing results are good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7883

From tschatzl at openjdk.java.net  Wed Mar 30 18:17:36 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 30 Mar 2022 18:17:36 GMT
Subject: RFR: 8283494: Factor out calculation of actual number of XMM
 registers [v2]
In-Reply-To: <KS-Tsmwa-5Zh15_095SVyRQWyq1NrYUx-qwnkPkp0sU=.997ed753-5674-4cf7-ac4d-75573e85b3db@github.com>
References: <VWzCeBhLgEcnxHs1YZ73N3w2i5G3JcJwIR_jx9HiKls=.0e645b29-1809-4f05-950b-eecabc46010f@github.com>
 <KS-Tsmwa-5Zh15_095SVyRQWyq1NrYUx-qwnkPkp0sU=.997ed753-5674-4cf7-ac4d-75573e85b3db@github.com>
Message-ID: <bcXcALrzkYOX_BAF-gEpON9q9Pb7Gq1PZXW2dTFXabk=.4f8107cb-d116-4e18-8f47-6daa0c2ba5ec@github.com>

On Tue, 29 Mar 2022 22:12:30 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Put method implementation in hpp file
>
> LGTM.

Thanks @dean-long @vnkozlov for your review

-------------

PR: https://git.openjdk.java.net/jdk/pull/7917

From tschatzl at openjdk.java.net  Wed Mar 30 18:17:37 2022
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Wed, 30 Mar 2022 18:17:37 GMT
Subject: Integrated: 8283494: Factor out calculation of actual number of XMM
 registers
In-Reply-To: <VWzCeBhLgEcnxHs1YZ73N3w2i5G3JcJwIR_jx9HiKls=.0e645b29-1809-4f05-950b-eecabc46010f@github.com>
References: <VWzCeBhLgEcnxHs1YZ73N3w2i5G3JcJwIR_jx9HiKls=.0e645b29-1809-4f05-950b-eecabc46010f@github.com>
Message-ID: <jMIe0tyWKbP2IV3MwZqPDJD1ZOEr0FrIpucLL0E617s=.8d35096d-570c-4a2d-981e-a0c608bc88f0@github.com>

On Wed, 23 Mar 2022 08:52:41 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this change that factors out calculation of the actually available number of XMM registers on a given processor/given command line options into a method and reuse that as much as possible?
> 
> This relates to this code snippet:
> 
>       int xmm_bypass_limit = FrameMap::nof_xmm_regs;
> #ifdef _LP64
>       if (UseAVX < 3) {
>         xmm_bypass_limit = xmm_bypass_limit / 2;
>       }
> #endif
> 
> 
> Also, there is already the method `FrameMap::get_num_caller_save_xmms()` that has been updated to use that new method `XMMRegisterImpl::available_xmm_registers()`; further I tried to appropriately use `FrameMap::get_num_caller_save_xmms` in the places where either would work. Please have a look in particular about that.
> 
> I did not change strange to me variable names like `xmm_bypass_limit` above as they probably make some sense to somebody as it's used quite often.
> 
> This also fixes a compilation error without configuring C1 introduced with [JDK-8283327](https://bugs.openjdk.java.net/browse/JDK-8283327).
> 
> Testing: tier1-5 (all but linux-aarch64 done), gha, local compilation with `configure --with-features=-compiler1`.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: ce27d9dd
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ce27d9dd5e1899c74ca2120e3e70420973eb241c
Stats:     67 lines in 8 files changed: 16 ins; 37 del; 14 mod

8283494: Factor out calculation of actual number of XMM registers

Reviewed-by: dlong, kvn

-------------

PR: https://git.openjdk.java.net/jdk/pull/7917

From kvn at openjdk.java.net  Wed Mar 30 18:28:39 2022
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 30 Mar 2022 18:28:39 GMT
Subject: RFR: 8281453: New optimization: convert "c-(~x)" into "x+(c+1)"
 and "~(c-x)" into "x+(-c-1)" [v6]
In-Reply-To: <yHuxfOsTW17PJOCaqnOMrpYetl4KB7KX8CpS7Fe-GYE=.d62fe529-a0ae-41ad-94ac-614bdcf381f5@github.com>
References: <4mTZu0_hVWb-ztMxMabFilyXAnAqOStCvU9wPmfqCKM=.fa8b7797-6e20-4c9e-80f1-b55ba3d5fe39@github.com>
 <yHuxfOsTW17PJOCaqnOMrpYetl4KB7KX8CpS7Fe-GYE=.d62fe529-a0ae-41ad-94ac-614bdcf381f5@github.com>
Message-ID: <8LJlW1iPfwUS_g6IZG1QJ36CLRyu4EvI7HJyFiWM4V4=.ecfb1d89-0d40-468f-ad22-e1c14f3438af@github.com>

On Sat, 26 Mar 2022 03:25:25 GMT, Zhiqiang Zang <duke at openjdk.java.net> wrote:

>> Similar to `(~x)+c` -> `(c-1)-x` and `~(x+c)` -> `(-c-1)-x` in #6858, we can also introduce similar optimizations for subtraction, `c-(~x)` -> `x+(c+1)` and `~(c-x)` -> `x+(-c-1)`.
>> 
>> The results of the microbenchmark are as follows:
>> 
>> Baseline:                                                                                                                                         
>> Benchmark                        Mode  Cnt  Score   Error  Units
>> SubIdealCMinusNotX.baselineInt   avgt   60  0.504 ? 0.011  ns/op
>> SubIdealCMinusNotX.baselineLong  avgt   60  0.484 ? 0.004  ns/op
>> SubIdealCMinusNotX.testInt1      avgt   60  0.779 ? 0.004  ns/op
>> SubIdealCMinusNotX.testInt2      avgt   60  0.896 ? 0.004  ns/op
>> SubIdealCMinusNotX.testLong1     avgt   60  0.722 ? 0.004  ns/op
>> SubIdealCMinusNotX.testLong2     avgt   60  0.720 ? 0.005  ns/op
>> 
>> Patch:
>> Benchmark                        Mode  Cnt  Score   Error  Units
>> SubIdealCMinusNotX.baselineInt   avgt   60  0.487 ? 0.009  ns/op
>> SubIdealCMinusNotX.baselineLong  avgt   60  0.486 ? 0.009  ns/op
>> SubIdealCMinusNotX.testInt1      avgt   60  0.372 ? 0.010  ns/op
>> SubIdealCMinusNotX.testInt2      avgt   60  0.365 ? 0.003  ns/op
>> SubIdealCMinusNotX.testLong1     avgt   60  0.369 ? 0.004  ns/op
>> SubIdealCMinusNotX.testLong2     avgt   60  0.399 ? 0.016  ns/op
>
> Zhiqiang Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean.

This change touches the same code as #7795
I suggest to update after that one is pushed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7376

From vladimir.kozlov at oracle.com  Wed Mar 30 21:28:32 2022
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 30 Mar 2022 14:28:32 -0700
Subject: [External] : Re: RFC : Approach to handle Allocation Merges in C2
 Scalar Replacement
In-Reply-To: <DM6PR21MB148490B67DC149401571356E9A1F9@DM6PR21MB1484.namprd21.prod.outlook.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
 <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
 <806f2baa-9b48-e57a-d153-0a19fc3e709d@oracle.com>
 <BY5PR21MB14735BCBF26C72B09051613E9A379@BY5PR21MB1473.namprd21.prod.outlook.com>
 <3cd5e4b1-5a0e-28ef-2445-1bf65fca4422@oracle.com>
 <BY5PR21MB147353D5267885877DFB47D79A3B9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <BY5PR21MB1473482D25CF302438F83A289A129@BY5PR21MB1473.namprd21.prod.outlook.com>
 <cbe335c5-7fb5-ce01-d113-c098f9b6a6b6@oracle.com>
 <DM6PR21MB148490B67DC149401571356E9A1F9@DM6PR21MB1484.namprd21.prod.outlook.com>
Message-ID: <323c6ace-6f6d-f2d0-a7e9-ed6879afeff4@oracle.com>

Hi Cesar,

Can you also send me your test file TestSimpleMerge.java. I need to reproduce your failure.

Currently I see wrong memeory edge in LoadI [231] node because it points to memory [122] on path which is not fully 
dominating (on code branch).

Thanks,
Vladimir K

[1]

  41  Initialize  ===  33  1  44  1  1  40  90  [[ 42  43 ]]  !jvms: TestSimpleMerge::test @ bci:0 (line 9)
  43  Proj  ===  41  [[ 133  132  131  123  179  180  181  182  53  53  53  53  233 ]] #2  Memory: @rawptr:BotPTR, 
idx=Raw; !jvms: TestSimpleMerge::test @ bci:0 (line 9)
  101  IfFalse  ===  99  [[ 105 ]] #0 !jvms: TestSimpleMerge::test @ bci:10 (line 11)

  120  Initialize  ===  112  1  123  1  1  119  171  [[ 121  122 ]]  !jvms: TestSimpleMerge::test @ bci:13 (line 12)
  122  Proj  ===  120  [[ 182  181  180  179  231 ]] #2  Memory: @rawptr:BotPTR, idx=Raw; !jvms: TestSimpleMerge::test @ 
bci:13 (line 12)
  121  Proj  ===  120  [[ 105  124 ]] #0 !jvms: TestSimpleMerge::test @ bci:13 (line 12)

  221  ConI  ===  0  [[ 220  225 ]]  #int:0
  222  ConI  ===  0  [[ 220 ]]  #int:1

  105  Region  ===  105  121  101  [[ 105  220  178  179  180  181  182  227 ]]  !jvms: TestSimpleMerge::test @ bci:22 
(line 14)

  220  Phi  ===  105  221  222  [[ 225 ]]  #int
  225  CmpI  === _  220  221  [[ 226 ]]
  226  Bool  === _  225  [[ 227 ]] [eq]
  227  If  ===  105  226  [[ 228  229 ]] P=0.000000, C=0.000000

  229  IfFalse  ===  227  [[ 233  223 ]] #0
  233  LoadI  ===  229  43  232  [[ 224 ]]  @TestSimpleMerge$Point+12 *, name=x, idx=6; #int !orig=[207] !jvms: 
TestSimpleMerge$Point::calc @ bci:1 (line 5) TestSimpleMerge::test @ bci:23 (line 14)

  228  IfTrue  ===  227  [[ 231  223 ]] #1
  231  LoadI  ===  228  122  230  [[ 224 ]]  @TestSimpleMerge$Point+12 *, name=x, idx=6; #int !orig=[207] !jvms: 
TestSimpleMerge$Point::calc @ bci:1 (line 5) TestSimpleMerge::test @ bci:23 (line 14)

  223  Region  ===  223  228  229  [[ 223  224  216 ]]
  224  Phi  ===  223  231  233  [[ 216 ]]  #int
  216  Return  ===  223  178  18  8  9 returns 224  [[ 0 ]]

On 3/29/22 5:34 PM, Cesar Soares Lucas wrote:
> Hi, Vladimir.
> 
> Thank you for getting back to me. What you describe is exactly what I understand and what I tried to implement. I also 
> noticed the issue with the nodes floating up and I even tried to prevent that.. but I think the root of the problem is 
> somewhere else.
> 
> Please take a look at this printout: https://www.dropbox.com/s/ao30zadovwqswlp/splitted.txt?dl=0 
> <https://urldefense.com/v3/__https://www.dropbox.com/s/ao30zadovwqswlp/splitted.txt?dl=0__;!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVTddI45Zg$> 
> . C2 tells me that this graph has bad dominance: ?Use 228 isn?t dominated by def 231?. This error message is result of 
> this verification: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L5361 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp*L5361__;Iw!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVSGiICGJw$> 
> 
> 
> I agree and disagree with the message. I?m not sure if it?s my limited knowledge of C2 IR or some wording problem in the 
> message: why would 228 need to be dominated by 231 - after all 228 doesn?t use 231? The opposite makes more sense to me: 
> 228 needs to dominate 231 ? and that is true AFAICT. Nonetheless, I agree with the message that there is something wrong 
> in the graph: this graph allows for execution to reach node 231 without node 124 being executed!
> 
> I created this DRAFT PR so that you can look at the code if you want: https://github.com/openjdk/jdk/pull/8023 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8023__;!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVQl2jEXlA$> 
> .
> 
> Please let me know what you think. TIA!
> 
> Cesar
> 
> *From: *Vladimir Kozlov <vladimir.kozlov at oracle.com>
> *Date: *Monday, March 28, 2022 at 10:48 AM
> *To: *Cesar Soares Lucas <Divino.Cesar at microsoft.com>, Vladimir Ivanov <vladimir.x.ivanov at oracle.com>, hotspot compiler 
> <hotspot-compiler-dev at openjdk.java.net>
> *Cc: *Brian Stafford <Brian.Stafford at microsoft.com>, Martijn Verburg <Martijn.Verburg at microsoft.com>
> *Subject: *Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
> 
> Hi Cesar
> 
> On 3/17/22 12:15 PM, Cesar Soares Lucas wrote:
>> Hi all,
>> 
>> I?ve been experimenting with the idea explained by Vladimir Ivanov and I was able to implement it and have a few
>> non-trivial merges untangled and scalar replaced. However, I found an obstacle on the road. I was able to overcome it,
>> but I?d very much appreciate your opinion about the matter. Assume we start off with the piece of code below.
>> 
>> if (?) ????p0 = ?
>> 
>> else ??????p1 = ?
>> 
>> p = phi(p0, p1)
>> 
>> return p.x
>> 
>> The idea proposed suggests, AFAIU, that we change the code to be something like the below **where we use the bases
>> directly**.
>> 
>> if (?)?? p0 = ?
>> 
>> else ????p1 = ?
>> 
>> s = # selector phi #
>> 
>> if (s == id_base0)??? ???????x0 = p0.x
>> 
>> elseif (s == id_base1) ???x1 = p1.x
>> 
>> else ?????????????????????????????????halt()
>> 
>> x = phi(x0, x1)
>> 
>> return x
>> 
>> The problem here is that the definition of ?p0? and/or ?p1? doesn?t dominate their use in the loads ?x0 = p0.x? / ?x1 =
>> p1.x?, therefore certain IR verification steps in C2 fail. I was able to work around the issue by adding Phi nodes where
>> all inputs are the same (excluding the ctrl), thus creating a ?fake? definition for the value. Please see code below.
> 
> You have original `p = phi(p0, p1)` which is attached to Region node which merges paths with p0 and p1. `Selector ID
> Phi(id_p0, id_p1)` should be attached to the same Region and guarantee that p0 and p1 are defined at that point. The
> only issue could be is that load nodes don't have control edges and depend on memory edges to schedule. So they could
> float up. I think they should be attached (control edge) to id checks (s == id_base*) to prevent them move up as new
> special case [1]. At least as first approach for experiment.
> 
> Thanks,
> Vladimir K
> 
> [1] 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2Fmaster%2Fsrc%2Fhotspot%2Fshare%2Fopto%2Fmemnode.cpp%23L1737&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd6152056b06744f7359e08da10e33a44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637840865379084345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HaPBCqckab%2BpOcIoYEccL04u1o1pqqaUjsYMCslfP7Y%3D&amp;reserved=0 
> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2Fmaster*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fmemnode.cpp*23L1737&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Cd6152056b06744f7359e08da10e33a44*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637840865379084345*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=HaPBCqckab*2BpOcIoYEccL04u1o1pqqaUjsYMCslfP7Y*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVTydJtLxg$>
> 
>> 
>> if (?)?? p0 = ?
>> 
>> else ????p1 = ?
>> 
>> phi0 = phi(p0, p0)
>> 
>> phi1 = Phi(p1, p1)
>> 
>> s = # selector phi #
>> 
>> if (s == id_base0)??? ???????x0 = phi0.x
>> 
>> elseif (s == id_base1) ???x1 = phi1.x
>> 
>> else ?????????????????????????????????halt()
>> 
>> x = phi(x0, x1)
>> 
>> return x
>> 
>> Transforming the code to look like the above silenced the verifications ( :-] ) and at the end EA+SR was able to remove
>> the allocations **and get rid of all the Phi?s**.
>> 
>> So, my question is: is this workaround acceptable? Do you have a suggestion of a better solution?
>> 
>> TIA, Cesar
>> 
>> *From: *hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.java.net> on behalf of Cesar Soares Lucas
>> <Divino.Cesar at microsoft.com>
>> *Date: *Tuesday, February 22, 2022 at 10:01 AM
>> *To: *Vladimir Ivanov <vladimir.x.ivanov at oracle.com>, Vladimir Kozlov <vladimir.kozlov at oracle.com>, hotspot compiler
>> <hotspot-compiler-dev at openjdk.java.net>
>> *Cc: *Brian Stafford <Brian.Stafford at microsoft.com>, Martijn Verburg <Martijn.Verburg at microsoft.com>
>> *Subject: *Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>> 
>> Hi Vladimir,
>> 
>> I think I've enough feedback to start working on a prototype and see how things play out. Thank you for sharing your
>> ideas/expertise!
>> 
>> 
>> Cheers,
>> Cesar
>> 
>> ________________________________________
>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>> Sent: February 21, 2022 10:26 AM
>> To: Cesar Soares Lucas; Vladimir Kozlov; hotspot compiler
>> Cc: Brian Stafford; Martijn Verburg
>> Subject: Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>> 
>> Hi Cesar,
>> 
>>> I with the selector-based base splitting idea using some examples and I think I understand the mechanics well. It's conceptually simple and quite effective, I like it! I've another question, though. From your previous message I had understood that we needed the clustering because split_unique_types can't handle multiple bases at once, which makes sense to me. _This time I
>> don't understand why we need to do the clustering before doing the selector-based transformation_. AFAIU this
>> transformation won't be creating any memory slices but rather just assigning IDs to different bases and then creating
>> specialized memory operations conditionally using the different bases.
>> 
>> Yes, that's a valid simplification. It does sound like introducing
>> selector ID doesn't require a separate memory graph (and can be
>> performed before split_unique_types()), but I don't have a good
>> understanding how complicated simplifying selector-based IR shapes would
>> be compared to original (memory op-based) ones. It's definitely worth
>> experimenting with.
>> 
>> Best regards,
>> Vladimir Ivanov
>> 
>>> ________________________________________
>>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>>> Sent: February 17, 2022 7:37 AM
>>> To: Vladimir Kozlov; Cesar Soares Lucas; hotspot compiler
>>> Cc: Brian Stafford; Martijn Verburg
>>> Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>
>>>
>>>> But depending on the actual shape of the base pointer (here it's
>>>> Phi(obj1,obj2)), it may become infeasible (from performance perspective)
>>>> or even impossible (e.g., for complex loop variant conditions) to
>>>> separate instance slices.
>>>
>>> I'd like to correct myself. After thinking more about the problem, I see
>>> a universal way to scalarize clusters of interfering non-escaping
>>> allocations even in presence of accesses with indeterminate base.
>>>
>>> The crucial property for such cluster of interacting non-escaping
>>> allocations is for any memory access its base is either part of the
>>> cluster or not (it's a static property for every access). Then, when it
>>> is part of the cluster, then the number of possible base values at
>>> runtime is finite and is a subset of the cluster.
>>>
>>> So, memory graph for the cluster can be scalarized as follows:
>>>
>>>???? (1) separate memory graph for the cluster
>>>
>>>???? (2) on the newly constructed graph:
>>>
>>>??????? (a) replace every base pointer with an ID ("selector id") and
>>> recreate data graph for selector IDs from base pointers graph;
>>>
>>>??????? (b) for accesses with indeterminate base pointer, replace them
>>> with a merge of states from relevant allocations selected by "selector id"
>>>
>>>??????? (c) after 2b, all memory accesses from the cluster memory graph
>>> should have fixed base pointing at a particular allocation
>>>
>>>???? (3) scalarize individual allocations from the cluster one by one
>>> (since they are independent now)
>>>
>>>??????? - additional transformation (like, split-through-phi) should
>>> simplify the graph by reducing the number of cases at merge points to
>>> care about (ideally, leaving only a single one);
>>>
>>>
>>>
>>> As an illustration:
>>>
>>>???? val = Load (AddP (Phi R base1 base2) offset) mem # load A.i
>>>
>>> ==(pseudo-code)==>
>>>
>>>???? selector = (Phi R #base1 #base2)
>>>
>>>???? if (selector == #base1) {
>>>?????? val1 = Load (base1 + offset) mem
>>>???? } else if (selector == #base2) {
>>>?????? val2 = Load (base2 + offset) mem
>>>???? } else {
>>>?????? halt(); // impossible
>>>???? }
>>>
>>>???? val = Phi(R1, val1, val2)
>>>
>>> ======
>>>
>>>???? Store (AddP (Phi R base1 base2) offset) mem v # store A.i v
>>>
>>> ==(pseudo-code)==>
>>>
>>>???? selector = (Phi R #base1 #base2)
>>>
>>>???? if (selector == #base1) {
>>>?????? Store base1 mem v ==> mem1
>>>???? } else if (selector == #base2) {
>>>?????? Store base2 mem v ==> mem2
>>>???? } else {
>>>?????? halt(); // impossible
>>>???? }
>>>
>>>???? mem = Phi(R1, mem1, mem2);
>>>
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>>
>>>> So, gradual approach seems the way to go:
>>>>???? (1) split memory graph for clusters of interacting non-escaping
>>>> allocations;
>>>>
>>>>???? (2) perform adhoc transformation targeted at untangling aliasing
>>>> accesses (e.g, split-through-phi);
>>>>
>>>>???? (3) extract unique instance types where possible, thus making the
>>>> corresponding allocation scalar replaceable
>>>>
>>>> =====================================================================
>>>>
>>>> Also, one observation: interacting allocations don't have to be of the
>>>> same class.
>>>>
>>>>?????? static int testPolluted(int r, boolean b) {
>>>>?????????? A obj1 = new B1(r);
>>>>?????????? A obj2 = new B2(r);
>>>>
>>>>?????????? A obj = (b ? obj1 : obj2);
>>>>?????????? for (int i = 1; i < r; i++) {
>>>>?????????????? obj.i++;
>>>>?????????? }
>>>>
>>>>?????????? return obj1.i + obj2.i;
>>>>?????? }
>>>>
>>>> Requiring unique instance types to perform SR (and not enhancing SR to
>>>> handle aliasing allocations case) helps avoid some challenges in
>>>> instance rematerialization logic at safepoints, because actual shape of
>>>> the scalarized object (its class and exact set of fields) becomes a
>>>> runtime property.
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>>>>>
>>>>>>> Otherwise, I believe wide memory states/merges would pose serious
>>>>>>> problems. E.g., when a load is split through a phi, you need to pick
>>>>>>> correct memory states for the new loads above the phi which quickly
>>>>>>> becomes quite a challenging task.
>>>>>>
>>>>>> Especially in loops. Actually I did tried such approach before and I
>>>>>> agree that it is hard.
>>>>>>
>>>>>> Thanks,
>>>>>> Vladimir K
>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Vladimir Ivanov
>>>>>>>
>>>>>>>>
>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>?????? p0 = Allocate(...);
>>>>>>>>?????? ...
>>>>>>>>?????? p0.x = first;
>>>>>>>>?????? p0.y = second;
>>>>>>>>
>>>>>>>>?????? if (cond) {
>>>>>>>>?????????? p1 = Allocate(...);
>>>>>>>>?????????? ...
>>>>>>>>?????????? p1.x = second;
>>>>>>>>?????????? p1.y = first;
>>>>>>>>?????? }
>>>>>>>>
>>>>>>>>?????? p = phi(p0, p1) // unused and will be removed
>>>>>>>>
>>>>>>>>
>>>>>>>>?????? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>>>>>> }
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Vladimir K
>>>>>>>>
>>>>>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>>>>>> (BCCing hotspot-dev and moving the discussion to
>>>>>>>>> hotspot-compiler-dev.)
>>>>>>>>>
>>>>>>>>> Hi Cesar,
>>>>>>>>>
>>>>>>>>> Thanks for looking into enhancing EA.
>>>>>>>>>
>>>>>>>>> Overall, the proposal looks reasonable.
>>>>>>>>>
>>>>>>>>> I suggest to look more closely at split_unique_types().
>>>>>>>>> It introduces a dedicated class of alias categories for fields of
>>>>>>>>> the allocation being eliminated and clones memory graph. I don't
>>>>>>>>> see why it shouldn't work for multiple allocations.
>>>>>>>>>
>>>>>>>>> Moreover, split_unique_types() will break if you start optimizing
>>>>>>>>> multiple allocations at once. The notion of unique alias should be
>>>>>>>>> adjusted and cover the union of unique aliases for all interacting
>>>>>>>>> allocations.
>>>>>>>>>
>>>>>>>>> Seems like you need to enhance SR to work on non-intersecting
>>>>>>>>> clusters of allocations.
>>>>>>>>>
>>>>>>>>> One thing to take care of: scalar replacement relies on
>>>>>>>>> TypeOopPtr::instance_id().
>>>>>>>>>
>>>>>>>>>???? // If not InstanceTop or InstanceBot, indicates that this is
>>>>>>>>>???? // a particular instance of this type which is distinct.
>>>>>>>>>???? // This is the node index of the allocation node creating this
>>>>>>>>> instance.
>>>>>>>>>???? int?????????? _instance_id;
>>>>>>>>>
>>>>>>>>> It'll break when multiple allocations are in play.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Vladimir Ivanov
>>>>>>>>>
>>>>>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>>>>>> Hi there again!
>>>>>>>>>>
>>>>>>>>>> Can you please give me feedback on the following approach to at
>>>>>>>>>> least partially
>>>>>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>>>>>
>>>>>>>>>> The problem that I am trying to solve arises when allocations are
>>>>>>>>>> merged after a
>>>>>>>>>> control flow split. The code below shows _one example_ of such a
>>>>>>>>>> situation.
>>>>>>>>>>
>>>>>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>>>>>>?????? Point p = new Point(x, y);
>>>>>>>>>>?????? if (cond)
>>>>>>>>>>?????????? p = new Point(y, x);
>>>>>>>>>>?????? // Allocations for p are merged here.
>>>>>>>>>>?????? return p.calc();
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Assuming the method calls on "p" are inlined then the allocations
>>>>>>>>>> will not
>>>>>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>>>>>
>>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>>?????? p0 = Allocate(...);
>>>>>>>>>>?????? ...
>>>>>>>>>>?????? p0.x = first;
>>>>>>>>>>?????? p0.y = second;
>>>>>>>>>>
>>>>>>>>>>?????? if (cond) {
>>>>>>>>>>?????????? p1 = Allocate(...);
>>>>>>>>>>?????????? ...
>>>>>>>>>>?????????? p1.x = second;
>>>>>>>>>>?????????? p1.y = first;
>>>>>>>>>>?????? }
>>>>>>>>>>
>>>>>>>>>>?????? p = phi(p0, p1)
>>>>>>>>>>
>>>>>>>>>>?????? return p.x - p.y;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> However, one of the constraints implemented here [2],
>>>>>>>>>> specifically the third
>>>>>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>>>>>
>>>>>>>>>> The approach that I'm considering for solving the problem is to
>>>>>>>>>> replace the Phi
>>>>>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields
>>>>>>>>>> of the objects
>>>>>>>>>> in the original Phi. The IR for `ex1` would look something like
>>>>>>>>>> this after the
>>>>>>>>>> transformation:
>>>>>>>>>>
>>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>>?????? p0 = Allocate(...);
>>>>>>>>>>?????? ...
>>>>>>>>>>?????? p0.x = first;
>>>>>>>>>>?????? p0.y = second;
>>>>>>>>>>
>>>>>>>>>>?????? if (cond) {
>>>>>>>>>>?????????? p1 = Allocate(...);
>>>>>>>>>>?????????? ...
>>>>>>>>>>?????????? p1.x = second;
>>>>>>>>>>?????????? p1.y = first;
>>>>>>>>>>?????? }
>>>>>>>>>>
>>>>>>>>>>?????? pX = phi(first, second)
>>>>>>>>>>?????? pY = phi(second, first)
>>>>>>>>>>
>>>>>>>>>>?????? return pX - pY;
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> I understand that this transformation might not be applicable for
>>>>>>>>>> all cases and
>>>>>>>>>> that it's not as simple as illustrated above. Also, it seems to
>>>>>>>>>> me that much of
>>>>>>>>>> what I'd have to implement is already implemented in other steps
>>>>>>>>>> of the Scalar
>>>>>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>>>>>> implementation details I plan to use as much of the existing code
>>>>>>>>>> as possible.
>>>>>>>>>> The algorithm for the transformation would be like this:
>>>>>>>>>>
>>>>>>>>>> split_phis(phi)
>>>>>>>>>>?????? # If output of phi escapes, or something uses its identity, etc
>>>>>>>>>>?????? # then we can't remove it. The conditions here might
>>>>>>>>>> possible be the
>>>>>>>>>>?????? # same as the ones implemented in
>>>>>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>>>>>>?????? if cant_remove_phi_output(phi)
>>>>>>>>>>?????????? return ;
>>>>>>>>>>
>>>>>>>>>>?????? # Collect a set of tuples(F,U) containing nodes U that uses
>>>>>>>>>> field F
>>>>>>>>>>?????? # member of the object resulting from `phi`.
>>>>>>>>>>?????? fields_used = collect_fields_used_after_phi(phi)
>>>>>>>>>>
>>>>>>>>>>?????? foreach field in fields_used
>>>>>>>>>>?????????? producers = {}
>>>>>>>>>>
>>>>>>>>>>?????????? # Create a list with the last Store for each field
>>>>>>>>>> "field" on the
>>>>>>>>>>?????????? # scope of each of the Phi input objects.
>>>>>>>>>>?????????? foreach o in phi.inputs
>>>>>>>>>>?????????????? # The function called below might re-use a lot of
>>>>>>>>>> the code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>>>>>>?????????????? producers += last_store_to_o_field(0, field)
>>>>>>>>>>?????????? # Create a new phi node whose inputs are the Store's to
>>>>>>>>>> 'field'
>>>>>>>>>>?????????? field_phi = create_new_phi(producers)
>>>>>>>>>>
>>>>>>>>>>?????????? update_consumers(field, field_phi)
>>>>>>>>>>
>>>>>>>>>> The implementation that I envisioned would be as a "pre-process"
>>>>>>>>>> [3] step just
>>>>>>>>>> after EA but before the constraint checks in
>>>>>>>>>> `adjust_scalar_replaceable_state`
>>>>>>>>>> [2]. If we agree that the overall Scalar Replacement
>>>>>>>>>> implementation goes through
>>>>>>>>>> the following major phases:
>>>>>>>>>>
>>>>>>>>>>?????? 1. Identify the Escape Status of objects.
>>>>>>>>>>?????? 2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>>>> based on a set of constraints.
>>>>>>>>>>?????? 3. Make call to Split_unique_types [4].
>>>>>>>>>>?????? 4 Iterate over object and array allocations.
>>>>>>>>>>?????????? 4.1 Check if allocation can be eliminated.
>>>>>>>>>>?????????? 4.2 Perform scalar replacement. Replace uses of object
>>>>>>>>>> in Safepoints.
>>>>>>>>>>?????????? 4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>>>
>>>>>>>>>> The transformation that I am proposing would change the overall
>>>>>>>>>> flow to look
>>>>>>>>>> like this:
>>>>>>>>>>
>>>>>>>>>>?????? 1. Identify the Escape Status of objects.
>>>>>>>>>>?????? 2. ----> New: "Split phi functions" <----
>>>>>>>>>>?????? 2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>>>> based on a set of constraints.
>>>>>>>>>>?????? 3. Make call to Split_unique_types [14].
>>>>>>>>>>?????? 4 Iterate over object and array allocations.
>>>>>>>>>>?????????? 4.1 ----> Moved to split_phi: "Check if allocation can
>>>>>>>>>> be eliminated" <----
>>>>>>>>>>?????????? 4.2 Perform scalar replacement. Replace uses of object
>>>>>>>>>> in Safepoints.
>>>>>>>>>>?????????? 4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>>>
>>>>>>>>>> Please let me know what you think and thank you for taking the
>>>>>>>>>> time to review
>>>>>>>>>> this!
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Cesar
>>>>>>>>>>
>>>>>>>>>> Notes:
>>>>>>>>>>
>>>>>>>>>>?????? [1] I am not sure yet how this approach will play with the
>>>>>>>>>> case of a merge
>>>>>>>>>>?????????? with NULL.
>>>>>>>>>>?????? [2]
>>>>>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809%26amp%3Bdata%3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd6152056b06744f7359e08da10e33a44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637840865379134331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2uggNczR4bPxDv15gREOFA65mta6qrilwlZxblgQcYc%3D&amp;reserved=0 
> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Cd6152056b06744f7359e08da10e33a44*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637840865379134331*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=2uggNczR4bPxDv15gREOFA65mta6qrilwlZxblgQcYc*3D&amp;reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVSj83WW6w$> 
> 
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24%26amp%3Bdata%3D04*7C01*7Cdivino.cesar*40microsoft.com*7C8c1737b992e847651e8d08d9f62d649b*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637811497098895122*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3D8hLm9BcYVRF810gFqf2*2B*2Fd28jzqU2k7htD*2FDLqR9vAM*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!c3mFGaPH2PWpbeiHR44WrjfJKF0Ymg6aPQ8EOEMK0t5iYjdL4XwgsEvifrlDVrer2pCrdQ%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd6152056b06744f7359e08da10e33a44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637840865379134331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=MX%2BMB2A%2FyA1sLbSbXPp0uIsckxM5OOc%2Fg%2BqPAMwSgAw%3D&amp;reserved=0 
> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24*26amp*3Bdata*3D04*7C01*7Cdivino.cesar*40microsoft.com*7C8c1737b992e847651e8d08d9f62d649b*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637811497098895122*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3D8hLm9BcYVRF810gFqf2*2B*2Fd28jzqU2k7htD*2FDLqR9vAM*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!c3mFGaPH2PWpbeiHR44WrjfJKF0Ymg6aPQ8EOEMK0t5iYjdL4XwgsEvifrlDVrer2pCrdQ*24&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Cd6152056b06744f7359e08da10e33a44*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637840865379134331*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=MX*2BMB2A*2FyA1sLbSbXPp0uIsckxM5OOc*2Fg*2BqPAMwSgAw*3D&amp;reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKioqKiUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVQOQ4zHVg$>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>?????? [3] Another option would be to "patch" the current
>>>>>>>>>> implementation to be able
>>>>>>>>>>?????????? to handle the merges. I am not certain that the "patch"
>>>>>>>>>> approach would be
>>>>>>>>>>?????????? better, however, the "pre-process" approach is certainly
>>>>>>>>>> much easier to test
>>>>>>>>>>?????????? and more readable.
>>>>>>>>>>
>>>>>>>>>>?????? [4] I cannot say I understand 100% the effects of executing
>>>>>>>>>>?????????? split_unique_types(). Would the transformation that I am
>>>>>>>>>> proposing need to
>>>>>>>>>>?????????? be after the call to split_unique_types?
>> 
> 

From vladimir.kozlov at oracle.com  Wed Mar 30 21:32:28 2022
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 30 Mar 2022 14:32:28 -0700
Subject: [External] : Re: RFC : Approach to handle Allocation Merges in C2
 Scalar Replacement
In-Reply-To: <323c6ace-6f6d-f2d0-a7e9-ed6879afeff4@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
 <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
 <806f2baa-9b48-e57a-d153-0a19fc3e709d@oracle.com>
 <BY5PR21MB14735BCBF26C72B09051613E9A379@BY5PR21MB1473.namprd21.prod.outlook.com>
 <3cd5e4b1-5a0e-28ef-2445-1bf65fca4422@oracle.com>
 <BY5PR21MB147353D5267885877DFB47D79A3B9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <BY5PR21MB1473482D25CF302438F83A289A129@BY5PR21MB1473.namprd21.prod.outlook.com>
 <cbe335c5-7fb5-ce01-d113-c098f9b6a6b6@oracle.com>
 <DM6PR21MB148490B67DC149401571356E9A1F9@DM6PR21MB1484.namprd21.prod.outlook.com>
 <323c6ace-6f6d-f2d0-a7e9-ed6879afeff4@oracle.com>
Message-ID: <305685c0-f250-34c1-e1b0-1da92f3c7ddf@oracle.com>

On 3/30/22 2:28 PM, Vladimir Kozlov wrote:
> Hi Cesar,
> 
> Can you also send me your test file TestSimpleMerge.java. I need to reproduce your failure.
> 
> Currently I see wrong memeory edge in LoadI [231] node because it points to memory [122] on path which is not fully 
> dominating (on code branch).

The memory should be this Phi:

  182  Phi  ===  105  122  43  [[ 18 ]]  #memory  Memory: @TestSimpleMerge$Point+12 *, name=x, idx=6; !jvms: 
TestSimpleMerge::test @ bci:22 (line 14)

May be we got some partial split through Phi transformation which is causing the issue.

> 
> Thanks,
> Vladimir K
> 
> [1]
> 
>  ?41? Initialize? ===? 33? 1? 44? 1? 1? 40? 90? [[ 42? 43 ]]? !jvms: TestSimpleMerge::test @ bci:0 (line 9)
>  ?43? Proj? ===? 41? [[ 133? 132? 131? 123? 179? 180? 181? 182? 53? 53? 53? 53? 233 ]] #2? Memory: @rawptr:BotPTR, 
> idx=Raw; !jvms: TestSimpleMerge::test @ bci:0 (line 9)
>  ?101? IfFalse? ===? 99? [[ 105 ]] #0 !jvms: TestSimpleMerge::test @ bci:10 (line 11)
> 
>  ?120? Initialize? ===? 112? 1? 123? 1? 1? 119? 171? [[ 121? 122 ]]? !jvms: TestSimpleMerge::test @ bci:13 (line 12)
>  ?122? Proj? ===? 120? [[ 182? 181? 180? 179? 231 ]] #2? Memory: @rawptr:BotPTR, idx=Raw; !jvms: TestSimpleMerge::test @ 
> bci:13 (line 12)
>  ?121? Proj? ===? 120? [[ 105? 124 ]] #0 !jvms: TestSimpleMerge::test @ bci:13 (line 12)
> 
>  ?221? ConI? ===? 0? [[ 220? 225 ]]? #int:0
>  ?222? ConI? ===? 0? [[ 220 ]]? #int:1
> 
>  ?105? Region? ===? 105? 121? 101? [[ 105? 220? 178? 179? 180? 181? 182? 227 ]]? !jvms: TestSimpleMerge::test @ bci:22 
> (line 14)
> 
>  ?220? Phi? ===? 105? 221? 222? [[ 225 ]]? #int
>  ?225? CmpI? === _? 220? 221? [[ 226 ]]
>  ?226? Bool? === _? 225? [[ 227 ]] [eq]
>  ?227? If? ===? 105? 226? [[ 228? 229 ]] P=0.000000, C=0.000000
> 
>  ?229? IfFalse? ===? 227? [[ 233? 223 ]] #0
>  ?233? LoadI? ===? 229? 43? 232? [[ 224 ]]? @TestSimpleMerge$Point+12 *, name=x, idx=6; #int !orig=[207] !jvms: 
> TestSimpleMerge$Point::calc @ bci:1 (line 5) TestSimpleMerge::test @ bci:23 (line 14)
> 
>  ?228? IfTrue? ===? 227? [[ 231? 223 ]] #1
>  ?231? LoadI? ===? 228? 122? 230? [[ 224 ]]? @TestSimpleMerge$Point+12 *, name=x, idx=6; #int !orig=[207] !jvms: 
> TestSimpleMerge$Point::calc @ bci:1 (line 5) TestSimpleMerge::test @ bci:23 (line 14)
> 
>  ?223? Region? ===? 223? 228? 229? [[ 223? 224? 216 ]]
>  ?224? Phi? ===? 223? 231? 233? [[ 216 ]]? #int
>  ?216? Return? ===? 223? 178? 18? 8? 9 returns 224? [[ 0 ]]
> 
> On 3/29/22 5:34 PM, Cesar Soares Lucas wrote:
>> Hi, Vladimir.
>>
>> Thank you for getting back to me. What you describe is exactly what I understand and what I tried to implement. I also 
>> noticed the issue with the nodes floating up and I even tried to prevent that.. but I think the root of the problem is 
>> somewhere else.
>>
>> Please take a look at this printout: https://www.dropbox.com/s/ao30zadovwqswlp/splitted.txt?dl=0 
>> <https://urldefense.com/v3/__https://www.dropbox.com/s/ao30zadovwqswlp/splitted.txt?dl=0__;!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVTddI45Zg$> 
>> . C2 tells me that this graph has bad dominance: ?Use 228 isn?t dominated by def 231?. This error message is result of 
>> this verification: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L5361 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp*L5361__;Iw!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVSGiICGJw$> 
>>
>>
>> I agree and disagree with the message. I?m not sure if it?s my limited knowledge of C2 IR or some wording problem in 
>> the message: why would 228 need to be dominated by 231 - after all 228 doesn?t use 231? The opposite makes more sense 
>> to me: 228 needs to dominate 231 ? and that is true AFAICT. Nonetheless, I agree with the message that there is 
>> something wrong in the graph: this graph allows for execution to reach node 231 without node 124 being executed!
>>
>> I created this DRAFT PR so that you can look at the code if you want: https://github.com/openjdk/jdk/pull/8023 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8023__;!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVQl2jEXlA$> 
>> .
>>
>> Please let me know what you think. TIA!
>>
>> Cesar
>>
>> *From: *Vladimir Kozlov <vladimir.kozlov at oracle.com>
>> *Date: *Monday, March 28, 2022 at 10:48 AM
>> *To: *Cesar Soares Lucas <Divino.Cesar at microsoft.com>, Vladimir Ivanov <vladimir.x.ivanov at oracle.com>, hotspot 
>> compiler <hotspot-compiler-dev at openjdk.java.net>
>> *Cc: *Brian Stafford <Brian.Stafford at microsoft.com>, Martijn Verburg <Martijn.Verburg at microsoft.com>
>> *Subject: *Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>
>> Hi Cesar
>>
>> On 3/17/22 12:15 PM, Cesar Soares Lucas wrote:
>>> Hi all,
>>>
>>> I?ve been experimenting with the idea explained by Vladimir Ivanov and I was able to implement it and have a few
>>> non-trivial merges untangled and scalar replaced. However, I found an obstacle on the road. I was able to overcome it,
>>> but I?d very much appreciate your opinion about the matter. Assume we start off with the piece of code below.
>>>
>>> if (?) ????p0 = ?
>>>
>>> else ??????p1 = ?
>>>
>>> p = phi(p0, p1)
>>>
>>> return p.x
>>>
>>> The idea proposed suggests, AFAIU, that we change the code to be something like the below **where we use the bases
>>> directly**.
>>>
>>> if (?)?? p0 = ?
>>>
>>> else ????p1 = ?
>>>
>>> s = # selector phi #
>>>
>>> if (s == id_base0)??? ???????x0 = p0.x
>>>
>>> elseif (s == id_base1) ???x1 = p1.x
>>>
>>> else ?????????????????????????????????halt()
>>>
>>> x = phi(x0, x1)
>>>
>>> return x
>>>
>>> The problem here is that the definition of ?p0? and/or ?p1? doesn?t dominate their use in the loads ?x0 = p0.x? / ?x1 =
>>> p1.x?, therefore certain IR verification steps in C2 fail. I was able to work around the issue by adding Phi nodes where
>>> all inputs are the same (excluding the ctrl), thus creating a ?fake? definition for the value. Please see code below.
>>
>> You have original `p = phi(p0, p1)` which is attached to Region node which merges paths with p0 and p1. `Selector ID
>> Phi(id_p0, id_p1)` should be attached to the same Region and guarantee that p0 and p1 are defined at that point. The
>> only issue could be is that load nodes don't have control edges and depend on memory edges to schedule. So they could
>> float up. I think they should be attached (control edge) to id checks (s == id_base*) to prevent them move up as new
>> special case [1]. At least as first approach for experiment.
>>
>> Thanks,
>> Vladimir K
>>
>> [1] 
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2Fmaster%2Fsrc%2Fhotspot%2Fshare%2Fopto%2Fmemnode.cpp%23L1737&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd6152056b06744f7359e08da10e33a44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637840865379084345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HaPBCqckab%2BpOcIoYEccL04u1o1pqqaUjsYMCslfP7Y%3D&amp;reserved=0 
>> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2Fmaster*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fmemnode.cpp*23L1737&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Cd6152056b06744f7359e08da10e33a44*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637840865379084345*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=HaPBCqckab*2BpOcIoYEccL04u1o1pqqaUjsYMCslfP7Y*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVTydJtLxg$> 
>>
>>
>>>
>>> if (?)?? p0 = ?
>>>
>>> else ????p1 = ?
>>>
>>> phi0 = phi(p0, p0)
>>>
>>> phi1 = Phi(p1, p1)
>>>
>>> s = # selector phi #
>>>
>>> if (s == id_base0)??? ???????x0 = phi0.x
>>>
>>> elseif (s == id_base1) ???x1 = phi1.x
>>>
>>> else ?????????????????????????????????halt()
>>>
>>> x = phi(x0, x1)
>>>
>>> return x
>>>
>>> Transforming the code to look like the above silenced the verifications ( :-] ) and at the end EA+SR was able to remove
>>> the allocations **and get rid of all the Phi?s**.
>>>
>>> So, my question is: is this workaround acceptable? Do you have a suggestion of a better solution?
>>>
>>> TIA, Cesar
>>>
>>> *From: *hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.java.net> on behalf of Cesar Soares Lucas
>>> <Divino.Cesar at microsoft.com>
>>> *Date: *Tuesday, February 22, 2022 at 10:01 AM
>>> *To: *Vladimir Ivanov <vladimir.x.ivanov at oracle.com>, Vladimir Kozlov <vladimir.kozlov at oracle.com>, hotspot compiler
>>> <hotspot-compiler-dev at openjdk.java.net>
>>> *Cc: *Brian Stafford <Brian.Stafford at microsoft.com>, Martijn Verburg <Martijn.Verburg at microsoft.com>
>>> *Subject: *Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>
>>> Hi Vladimir,
>>>
>>> I think I've enough feedback to start working on a prototype and see how things play out. Thank you for sharing your
>>> ideas/expertise!
>>>
>>>
>>> Cheers,
>>> Cesar
>>>
>>> ________________________________________
>>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>>> Sent: February 21, 2022 10:26 AM
>>> To: Cesar Soares Lucas; Vladimir Kozlov; hotspot compiler
>>> Cc: Brian Stafford; Martijn Verburg
>>> Subject: Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>
>>> Hi Cesar,
>>>
>>>> I with the selector-based base splitting idea using some examples and I think I understand the mechanics well. It's 
>>>> conceptually simple and quite effective, I like it! I've another question, though. From your previous message I had 
>>>> understood that we needed the clustering because split_unique_types can't handle multiple bases at once, which makes 
>>>> sense to me. _This time I
>>> don't understand why we need to do the clustering before doing the selector-based transformation_. AFAIU this
>>> transformation won't be creating any memory slices but rather just assigning IDs to different bases and then creating
>>> specialized memory operations conditionally using the different bases.
>>>
>>> Yes, that's a valid simplification. It does sound like introducing
>>> selector ID doesn't require a separate memory graph (and can be
>>> performed before split_unique_types()), but I don't have a good
>>> understanding how complicated simplifying selector-based IR shapes would
>>> be compared to original (memory op-based) ones. It's definitely worth
>>> experimenting with.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>> ________________________________________
>>>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>>>> Sent: February 17, 2022 7:37 AM
>>>> To: Vladimir Kozlov; Cesar Soares Lucas; hotspot compiler
>>>> Cc: Brian Stafford; Martijn Verburg
>>>> Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>>
>>>>
>>>>> But depending on the actual shape of the base pointer (here it's
>>>>> Phi(obj1,obj2)), it may become infeasible (from performance perspective)
>>>>> or even impossible (e.g., for complex loop variant conditions) to
>>>>> separate instance slices.
>>>>
>>>> I'd like to correct myself. After thinking more about the problem, I see
>>>> a universal way to scalarize clusters of interfering non-escaping
>>>> allocations even in presence of accesses with indeterminate base.
>>>>
>>>> The crucial property for such cluster of interacting non-escaping
>>>> allocations is for any memory access its base is either part of the
>>>> cluster or not (it's a static property for every access). Then, when it
>>>> is part of the cluster, then the number of possible base values at
>>>> runtime is finite and is a subset of the cluster.
>>>>
>>>> So, memory graph for the cluster can be scalarized as follows:
>>>>
>>>> ???? (1) separate memory graph for the cluster
>>>>
>>>> ???? (2) on the newly constructed graph:
>>>>
>>>> ??????? (a) replace every base pointer with an ID ("selector id") and
>>>> recreate data graph for selector IDs from base pointers graph;
>>>>
>>>> ??????? (b) for accesses with indeterminate base pointer, replace them
>>>> with a merge of states from relevant allocations selected by "selector id"
>>>>
>>>> ??????? (c) after 2b, all memory accesses from the cluster memory graph
>>>> should have fixed base pointing at a particular allocation
>>>>
>>>> ???? (3) scalarize individual allocations from the cluster one by one
>>>> (since they are independent now)
>>>>
>>>> ??????? - additional transformation (like, split-through-phi) should
>>>> simplify the graph by reducing the number of cases at merge points to
>>>> care about (ideally, leaving only a single one);
>>>>
>>>>
>>>>
>>>> As an illustration:
>>>>
>>>> ???? val = Load (AddP (Phi R base1 base2) offset) mem # load A.i
>>>>
>>>> ==(pseudo-code)==>
>>>>
>>>> ???? selector = (Phi R #base1 #base2)
>>>>
>>>> ???? if (selector == #base1) {
>>>> ?????? val1 = Load (base1 + offset) mem
>>>> ???? } else if (selector == #base2) {
>>>> ?????? val2 = Load (base2 + offset) mem
>>>> ???? } else {
>>>> ?????? halt(); // impossible
>>>> ???? }
>>>>
>>>> ???? val = Phi(R1, val1, val2)
>>>>
>>>> ======
>>>>
>>>> ???? Store (AddP (Phi R base1 base2) offset) mem v # store A.i v
>>>>
>>>> ==(pseudo-code)==>
>>>>
>>>> ???? selector = (Phi R #base1 #base2)
>>>>
>>>> ???? if (selector == #base1) {
>>>> ?????? Store base1 mem v ==> mem1
>>>> ???? } else if (selector == #base2) {
>>>> ?????? Store base2 mem v ==> mem2
>>>> ???? } else {
>>>> ?????? halt(); // impossible
>>>> ???? }
>>>>
>>>> ???? mem = Phi(R1, mem1, mem2);
>>>>
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>>>
>>>>> So, gradual approach seems the way to go:
>>>>> ???? (1) split memory graph for clusters of interacting non-escaping
>>>>> allocations;
>>>>>
>>>>> ???? (2) perform adhoc transformation targeted at untangling aliasing
>>>>> accesses (e.g, split-through-phi);
>>>>>
>>>>> ???? (3) extract unique instance types where possible, thus making the
>>>>> corresponding allocation scalar replaceable
>>>>>
>>>>> =====================================================================
>>>>>
>>>>> Also, one observation: interacting allocations don't have to be of the
>>>>> same class.
>>>>>
>>>>> ?????? static int testPolluted(int r, boolean b) {
>>>>> ?????????? A obj1 = new B1(r);
>>>>> ?????????? A obj2 = new B2(r);
>>>>>
>>>>> ?????????? A obj = (b ? obj1 : obj2);
>>>>> ?????????? for (int i = 1; i < r; i++) {
>>>>> ?????????????? obj.i++;
>>>>> ?????????? }
>>>>>
>>>>> ?????????? return obj1.i + obj2.i;
>>>>> ?????? }
>>>>>
>>>>> Requiring unique instance types to perform SR (and not enhancing SR to
>>>>> handle aliasing allocations case) helps avoid some challenges in
>>>>> instance rematerialization logic at safepoints, because actual shape of
>>>>> the scalarized object (its class and exact set of fields) becomes a
>>>>> runtime property.
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>>>>>
>>>>>>>> Otherwise, I believe wide memory states/merges would pose serious
>>>>>>>> problems. E.g., when a load is split through a phi, you need to pick
>>>>>>>> correct memory states for the new loads above the phi which quickly
>>>>>>>> becomes quite a challenging task.
>>>>>>>
>>>>>>> Especially in loops. Actually I did tried such approach before and I
>>>>>>> agree that it is hard.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Vladimir K
>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Vladimir Ivanov
>>>>>>>>
>>>>>>>>>
>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>> ?????? p0 = Allocate(...);
>>>>>>>>> ?????? ...
>>>>>>>>> ?????? p0.x = first;
>>>>>>>>> ?????? p0.y = second;
>>>>>>>>>
>>>>>>>>> ?????? if (cond) {
>>>>>>>>> ?????????? p1 = Allocate(...);
>>>>>>>>> ?????????? ...
>>>>>>>>> ?????????? p1.x = second;
>>>>>>>>> ?????????? p1.y = first;
>>>>>>>>> ?????? }
>>>>>>>>>
>>>>>>>>> ?????? p = phi(p0, p1) // unused and will be removed
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ?????? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Vladimir K
>>>>>>>>>
>>>>>>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>>>>>>> (BCCing hotspot-dev and moving the discussion to
>>>>>>>>>> hotspot-compiler-dev.)
>>>>>>>>>>
>>>>>>>>>> Hi Cesar,
>>>>>>>>>>
>>>>>>>>>> Thanks for looking into enhancing EA.
>>>>>>>>>>
>>>>>>>>>> Overall, the proposal looks reasonable.
>>>>>>>>>>
>>>>>>>>>> I suggest to look more closely at split_unique_types().
>>>>>>>>>> It introduces a dedicated class of alias categories for fields of
>>>>>>>>>> the allocation being eliminated and clones memory graph. I don't
>>>>>>>>>> see why it shouldn't work for multiple allocations.
>>>>>>>>>>
>>>>>>>>>> Moreover, split_unique_types() will break if you start optimizing
>>>>>>>>>> multiple allocations at once. The notion of unique alias should be
>>>>>>>>>> adjusted and cover the union of unique aliases for all interacting
>>>>>>>>>> allocations.
>>>>>>>>>>
>>>>>>>>>> Seems like you need to enhance SR to work on non-intersecting
>>>>>>>>>> clusters of allocations.
>>>>>>>>>>
>>>>>>>>>> One thing to take care of: scalar replacement relies on
>>>>>>>>>> TypeOopPtr::instance_id().
>>>>>>>>>>
>>>>>>>>>> ???? // If not InstanceTop or InstanceBot, indicates that this is
>>>>>>>>>> ???? // a particular instance of this type which is distinct.
>>>>>>>>>> ???? // This is the node index of the allocation node creating this
>>>>>>>>>> instance.
>>>>>>>>>> ???? int?????????? _instance_id;
>>>>>>>>>>
>>>>>>>>>> It'll break when multiple allocations are in play.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Vladimir Ivanov
>>>>>>>>>>
>>>>>>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>>>>>>> Hi there again!
>>>>>>>>>>>
>>>>>>>>>>> Can you please give me feedback on the following approach to at
>>>>>>>>>>> least partially
>>>>>>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>>>>>>
>>>>>>>>>>> The problem that I am trying to solve arises when allocations are
>>>>>>>>>>> merged after a
>>>>>>>>>>> control flow split. The code below shows _one example_ of such a
>>>>>>>>>>> situation.
>>>>>>>>>>>
>>>>>>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>>>>>>> ?????? Point p = new Point(x, y);
>>>>>>>>>>> ?????? if (cond)
>>>>>>>>>>> ?????????? p = new Point(y, x);
>>>>>>>>>>> ?????? // Allocations for p are merged here.
>>>>>>>>>>> ?????? return p.calc();
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Assuming the method calls on "p" are inlined then the allocations
>>>>>>>>>>> will not
>>>>>>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>>>>>>
>>>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>>> ?????? p0 = Allocate(...);
>>>>>>>>>>> ?????? ...
>>>>>>>>>>> ?????? p0.x = first;
>>>>>>>>>>> ?????? p0.y = second;
>>>>>>>>>>>
>>>>>>>>>>> ?????? if (cond) {
>>>>>>>>>>> ?????????? p1 = Allocate(...);
>>>>>>>>>>> ?????????? ...
>>>>>>>>>>> ?????????? p1.x = second;
>>>>>>>>>>> ?????????? p1.y = first;
>>>>>>>>>>> ?????? }
>>>>>>>>>>>
>>>>>>>>>>> ?????? p = phi(p0, p1)
>>>>>>>>>>>
>>>>>>>>>>> ?????? return p.x - p.y;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> However, one of the constraints implemented here [2],
>>>>>>>>>>> specifically the third
>>>>>>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>>>>>>
>>>>>>>>>>> The approach that I'm considering for solving the problem is to
>>>>>>>>>>> replace the Phi
>>>>>>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields
>>>>>>>>>>> of the objects
>>>>>>>>>>> in the original Phi. The IR for `ex1` would look something like
>>>>>>>>>>> this after the
>>>>>>>>>>> transformation:
>>>>>>>>>>>
>>>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>>> ?????? p0 = Allocate(...);
>>>>>>>>>>> ?????? ...
>>>>>>>>>>> ?????? p0.x = first;
>>>>>>>>>>> ?????? p0.y = second;
>>>>>>>>>>>
>>>>>>>>>>> ?????? if (cond) {
>>>>>>>>>>> ?????????? p1 = Allocate(...);
>>>>>>>>>>> ?????????? ...
>>>>>>>>>>> ?????????? p1.x = second;
>>>>>>>>>>> ?????????? p1.y = first;
>>>>>>>>>>> ?????? }
>>>>>>>>>>>
>>>>>>>>>>> ?????? pX = phi(first, second)
>>>>>>>>>>> ?????? pY = phi(second, first)
>>>>>>>>>>>
>>>>>>>>>>> ?????? return pX - pY;
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> I understand that this transformation might not be applicable for
>>>>>>>>>>> all cases and
>>>>>>>>>>> that it's not as simple as illustrated above. Also, it seems to
>>>>>>>>>>> me that much of
>>>>>>>>>>> what I'd have to implement is already implemented in other steps
>>>>>>>>>>> of the Scalar
>>>>>>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>>>>>>> implementation details I plan to use as much of the existing code
>>>>>>>>>>> as possible.
>>>>>>>>>>> The algorithm for the transformation would be like this:
>>>>>>>>>>>
>>>>>>>>>>> split_phis(phi)
>>>>>>>>>>> ?????? # If output of phi escapes, or something uses its identity, etc
>>>>>>>>>>> ?????? # then we can't remove it. The conditions here might
>>>>>>>>>>> possible be the
>>>>>>>>>>> ?????? # same as the ones implemented in
>>>>>>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>>>>>>> ?????? if cant_remove_phi_output(phi)
>>>>>>>>>>> ?????????? return ;
>>>>>>>>>>>
>>>>>>>>>>> ?????? # Collect a set of tuples(F,U) containing nodes U that uses
>>>>>>>>>>> field F
>>>>>>>>>>> ?????? # member of the object resulting from `phi`.
>>>>>>>>>>> ?????? fields_used = collect_fields_used_after_phi(phi)
>>>>>>>>>>>
>>>>>>>>>>> ?????? foreach field in fields_used
>>>>>>>>>>> ?????????? producers = {}
>>>>>>>>>>>
>>>>>>>>>>> ?????????? # Create a list with the last Store for each field
>>>>>>>>>>> "field" on the
>>>>>>>>>>> ?????????? # scope of each of the Phi input objects.
>>>>>>>>>>> ?????????? foreach o in phi.inputs
>>>>>>>>>>> ?????????????? # The function called below might re-use a lot of
>>>>>>>>>>> the code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>>>>>>> ?????????????? producers += last_store_to_o_field(0, field)
>>>>>>>>>>> ?????????? # Create a new phi node whose inputs are the Store's to
>>>>>>>>>>> 'field'
>>>>>>>>>>> ?????????? field_phi = create_new_phi(producers)
>>>>>>>>>>>
>>>>>>>>>>> ?????????? update_consumers(field, field_phi)
>>>>>>>>>>>
>>>>>>>>>>> The implementation that I envisioned would be as a "pre-process"
>>>>>>>>>>> [3] step just
>>>>>>>>>>> after EA but before the constraint checks in
>>>>>>>>>>> `adjust_scalar_replaceable_state`
>>>>>>>>>>> [2]. If we agree that the overall Scalar Replacement
>>>>>>>>>>> implementation goes through
>>>>>>>>>>> the following major phases:
>>>>>>>>>>>
>>>>>>>>>>> ?????? 1. Identify the Escape Status of objects.
>>>>>>>>>>> ?????? 2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>>>>> based on a set of constraints.
>>>>>>>>>>> ?????? 3. Make call to Split_unique_types [4].
>>>>>>>>>>> ?????? 4 Iterate over object and array allocations.
>>>>>>>>>>> ?????????? 4.1 Check if allocation can be eliminated.
>>>>>>>>>>> ?????????? 4.2 Perform scalar replacement. Replace uses of object
>>>>>>>>>>> in Safepoints.
>>>>>>>>>>> ?????????? 4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>>>>
>>>>>>>>>>> The transformation that I am proposing would change the overall
>>>>>>>>>>> flow to look
>>>>>>>>>>> like this:
>>>>>>>>>>>
>>>>>>>>>>> ?????? 1. Identify the Escape Status of objects.
>>>>>>>>>>> ?????? 2. ----> New: "Split phi functions" <----
>>>>>>>>>>> ?????? 2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>>>>> based on a set of constraints.
>>>>>>>>>>> ?????? 3. Make call to Split_unique_types [14].
>>>>>>>>>>> ?????? 4 Iterate over object and array allocations.
>>>>>>>>>>> ?????????? 4.1 ----> Moved to split_phi: "Check if allocation can
>>>>>>>>>>> be eliminated" <----
>>>>>>>>>>> ?????????? 4.2 Perform scalar replacement. Replace uses of object
>>>>>>>>>>> in Safepoints.
>>>>>>>>>>> ?????????? 4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>>>>
>>>>>>>>>>> Please let me know what you think and thank you for taking the
>>>>>>>>>>> time to review
>>>>>>>>>>> this!
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Cesar
>>>>>>>>>>>
>>>>>>>>>>> Notes:
>>>>>>>>>>>
>>>>>>>>>>> ?????? [1] I am not sure yet how this approach will play with the
>>>>>>>>>>> case of a merge
>>>>>>>>>>> ?????????? with NULL.
>>>>>>>>>>> ?????? [2]
>>>>>>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809%26amp%3Bdata%3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd6152056b06744f7359e08da10e33a44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637840865379134331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2uggNczR4bPxDv15gREOFA65mta6qrilwlZxblgQcYc%3D&amp;reserved=0 
>>
>> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Cd6152056b06744f7359e08da10e33a44*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637840865379134331*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=2uggNczR4bPxDv15gREOFA65mta6qrilwlZxblgQcYc*3D&amp;reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVSj83WW6w$> 
>>
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24%26amp%3Bdata%3D04*7C01*7Cdivino.cesar*40microsoft.com*7C8c1737b992e847651e8d08d9f62d649b*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637811497098895122*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3D8hLm9BcYVRF810gFqf2*2B*2Fd28jzqU2k7htD*2FDLqR9vAM*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!c3mFGaPH2PWpbeiHR44WrjfJKF0Ymg6aPQ8EOEMK0t5iYjdL4XwgsEvifrlDVrer2pCrdQ%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd6152056b06744f7359e08da10e33a44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637840865379134331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=MX%2BMB2A%2FyA1sLbSbXPp0uIsckxM5OOc%2Fg%2BqPAMwSgAw%3D&amp;reserved=0 
>>
>> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24*26amp*3Bdata*3D04*7C01*7Cdivino.cesar*40microsoft.com*7C8c1737b992e847651e8d08d9f62d649b*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637811497098895122*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3D8hLm9BcYVRF810gFqf2*2B*2Fd28jzqU2k7htD*2FDLqR9vAM*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!c3mFGaPH2PWpbeiHR44WrjfJKF0Ymg6aPQ8EOEMK0t5iYjdL4XwgsEvifrlDVrer2pCrdQ*24&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Cd6152056b06744f7359e08da10e33a44*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637840865379134331*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=MX*2BMB2A*2FyA1sLbSbXPp0uIsckxM5OOc*2Fg*2BqPAMwSgAw*3D&amp;reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKioqKiUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVQOQ4zHVg$>> 
>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ?????? [3] Another option would be to "patch" the current
>>>>>>>>>>> implementation to be able
>>>>>>>>>>> ?????????? to handle the merges. I am not certain that the "patch"
>>>>>>>>>>> approach would be
>>>>>>>>>>> ?????????? better, however, the "pre-process" approach is certainly
>>>>>>>>>>> much easier to test
>>>>>>>>>>> ?????????? and more readable.
>>>>>>>>>>>
>>>>>>>>>>> ?????? [4] I cannot say I understand 100% the effects of executing
>>>>>>>>>>> ?????????? split_unique_types(). Would the transformation that I am
>>>>>>>>>>> proposing need to
>>>>>>>>>>> ?????????? be after the call to split_unique_types?
>>>
>>

From vladimir.kozlov at oracle.com  Wed Mar 30 23:54:23 2022
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 30 Mar 2022 16:54:23 -0700
Subject: [External] : Re: RFC : Approach to handle Allocation Merges in C2
 Scalar Replacement
In-Reply-To: <305685c0-f250-34c1-e1b0-1da92f3c7ddf@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <919984fa-fae7-944a-ca5d-eebd3b516f52@oracle.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
 <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
 <806f2baa-9b48-e57a-d153-0a19fc3e709d@oracle.com>
 <BY5PR21MB14735BCBF26C72B09051613E9A379@BY5PR21MB1473.namprd21.prod.outlook.com>
 <3cd5e4b1-5a0e-28ef-2445-1bf65fca4422@oracle.com>
 <BY5PR21MB147353D5267885877DFB47D79A3B9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <BY5PR21MB1473482D25CF302438F83A289A129@BY5PR21MB1473.namprd21.prod.outlook.com>
 <cbe335c5-7fb5-ce01-d113-c098f9b6a6b6@oracle.com>
 <DM6PR21MB148490B67DC149401571356E9A1F9@DM6PR21MB1484.namprd21.prod.outlook.com>
 <323c6ace-6f6d-f2d0-a7e9-ed6879afeff4@oracle.com>
 <305685c0-f250-34c1-e1b0-1da92f3c7ddf@oracle.com>
Message-ID: <b8f51fab-f18f-d108-a934-169e3cb663a6@oracle.com>

I was not able to reproduce the issue with my test and your patch.

Also try to comment out/remove next your new lines to keep orig_load_mem:

+  // Create unique input for "memory" of Load
+  Node* orig_load_mem   = original_load->in(LoadNode::Memory);
+  new_load->replace_edge(orig_load_mem, orig_load_mem->is_Phi() ? orig_load_mem->in(idx) : orig_load_mem);


Thanks,
Vladimir K

On 3/30/22 2:32 PM, Vladimir Kozlov wrote:
> On 3/30/22 2:28 PM, Vladimir Kozlov wrote:
>> Hi Cesar,
>>
>> Can you also send me your test file TestSimpleMerge.java. I need to reproduce your failure.
>>
>> Currently I see wrong memeory edge in LoadI [231] node because it points to memory [122] on path which is not fully 
>> dominating (on code branch).
> 
> The memory should be this Phi:
> 
>  ?182? Phi? ===? 105? 122? 43? [[ 18 ]]? #memory? Memory: @TestSimpleMerge$Point+12 *, name=x, idx=6; !jvms: 
> TestSimpleMerge::test @ bci:22 (line 14)
> 
> May be we got some partial split through Phi transformation which is causing the issue.
> 
>>
>> Thanks,
>> Vladimir K
>>
>> [1]
>>
>> ??41? Initialize? ===? 33? 1? 44? 1? 1? 40? 90? [[ 42? 43 ]]? !jvms: TestSimpleMerge::test @ bci:0 (line 9)
>> ??43? Proj? ===? 41? [[ 133? 132? 131? 123? 179? 180? 181? 182? 53? 53? 53? 53? 233 ]] #2? Memory: @rawptr:BotPTR, 
>> idx=Raw; !jvms: TestSimpleMerge::test @ bci:0 (line 9)
>> ??101? IfFalse? ===? 99? [[ 105 ]] #0 !jvms: TestSimpleMerge::test @ bci:10 (line 11)
>>
>> ??120? Initialize? ===? 112? 1? 123? 1? 1? 119? 171? [[ 121? 122 ]]? !jvms: TestSimpleMerge::test @ bci:13 (line 12)
>> ??122? Proj? ===? 120? [[ 182? 181? 180? 179? 231 ]] #2? Memory: @rawptr:BotPTR, idx=Raw; !jvms: TestSimpleMerge::test 
>> @ bci:13 (line 12)
>> ??121? Proj? ===? 120? [[ 105? 124 ]] #0 !jvms: TestSimpleMerge::test @ bci:13 (line 12)
>>
>> ??221? ConI? ===? 0? [[ 220? 225 ]]? #int:0
>> ??222? ConI? ===? 0? [[ 220 ]]? #int:1
>>
>> ??105? Region? ===? 105? 121? 101? [[ 105? 220? 178? 179? 180? 181? 182? 227 ]]? !jvms: TestSimpleMerge::test @ bci:22 
>> (line 14)
>>
>> ??220? Phi? ===? 105? 221? 222? [[ 225 ]]? #int
>> ??225? CmpI? === _? 220? 221? [[ 226 ]]
>> ??226? Bool? === _? 225? [[ 227 ]] [eq]
>> ??227? If? ===? 105? 226? [[ 228? 229 ]] P=0.000000, C=0.000000
>>
>> ??229? IfFalse? ===? 227? [[ 233? 223 ]] #0
>> ??233? LoadI? ===? 229? 43? 232? [[ 224 ]]? @TestSimpleMerge$Point+12 *, name=x, idx=6; #int !orig=[207] !jvms: 
>> TestSimpleMerge$Point::calc @ bci:1 (line 5) TestSimpleMerge::test @ bci:23 (line 14)
>>
>> ??228? IfTrue? ===? 227? [[ 231? 223 ]] #1
>> ??231? LoadI? ===? 228? 122? 230? [[ 224 ]]? @TestSimpleMerge$Point+12 *, name=x, idx=6; #int !orig=[207] !jvms: 
>> TestSimpleMerge$Point::calc @ bci:1 (line 5) TestSimpleMerge::test @ bci:23 (line 14)
>>
>> ??223? Region? ===? 223? 228? 229? [[ 223? 224? 216 ]]
>> ??224? Phi? ===? 223? 231? 233? [[ 216 ]]? #int
>> ??216? Return? ===? 223? 178? 18? 8? 9 returns 224? [[ 0 ]]
>>
>> On 3/29/22 5:34 PM, Cesar Soares Lucas wrote:
>>> Hi, Vladimir.
>>>
>>> Thank you for getting back to me. What you describe is exactly what I understand and what I tried to implement. I 
>>> also noticed the issue with the nodes floating up and I even tried to prevent that.. but I think the root of the 
>>> problem is somewhere else.
>>>
>>> Please take a look at this printout: https://www.dropbox.com/s/ao30zadovwqswlp/splitted.txt?dl=0 
>>> <https://urldefense.com/v3/__https://www.dropbox.com/s/ao30zadovwqswlp/splitted.txt?dl=0__;!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVTddI45Zg$> 
>>> . C2 tells me that this graph has bad dominance: ?Use 228 isn?t dominated by def 231?. This error message is result 
>>> of this verification: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L5361 
>>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp*L5361__;Iw!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVSGiICGJw$> 
>>>
>>>
>>> I agree and disagree with the message. I?m not sure if it?s my limited knowledge of C2 IR or some wording problem in 
>>> the message: why would 228 need to be dominated by 231 - after all 228 doesn?t use 231? The opposite makes more sense 
>>> to me: 228 needs to dominate 231 ? and that is true AFAICT. Nonetheless, I agree with the message that there is 
>>> something wrong in the graph: this graph allows for execution to reach node 231 without node 124 being executed!
>>>
>>> I created this DRAFT PR so that you can look at the code if you want: https://github.com/openjdk/jdk/pull/8023 
>>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8023__;!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVQl2jEXlA$> 
>>> .
>>>
>>> Please let me know what you think. TIA!
>>>
>>> Cesar
>>>
>>> *From: *Vladimir Kozlov <vladimir.kozlov at oracle.com>
>>> *Date: *Monday, March 28, 2022 at 10:48 AM
>>> *To: *Cesar Soares Lucas <Divino.Cesar at microsoft.com>, Vladimir Ivanov <vladimir.x.ivanov at oracle.com>, hotspot 
>>> compiler <hotspot-compiler-dev at openjdk.java.net>
>>> *Cc: *Brian Stafford <Brian.Stafford at microsoft.com>, Martijn Verburg <Martijn.Verburg at microsoft.com>
>>> *Subject: *Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>
>>> Hi Cesar
>>>
>>> On 3/17/22 12:15 PM, Cesar Soares Lucas wrote:
>>>> Hi all,
>>>>
>>>> I?ve been experimenting with the idea explained by Vladimir Ivanov and I was able to implement it and have a few
>>>> non-trivial merges untangled and scalar replaced. However, I found an obstacle on the road. I was able to overcome it,
>>>> but I?d very much appreciate your opinion about the matter. Assume we start off with the piece of code below.
>>>>
>>>> if (?) ????p0 = ?
>>>>
>>>> else ??????p1 = ?
>>>>
>>>> p = phi(p0, p1)
>>>>
>>>> return p.x
>>>>
>>>> The idea proposed suggests, AFAIU, that we change the code to be something like the below **where we use the bases
>>>> directly**.
>>>>
>>>> if (?)?? p0 = ?
>>>>
>>>> else ????p1 = ?
>>>>
>>>> s = # selector phi #
>>>>
>>>> if (s == id_base0)??? ???????x0 = p0.x
>>>>
>>>> elseif (s == id_base1) ???x1 = p1.x
>>>>
>>>> else ?????????????????????????????????halt()
>>>>
>>>> x = phi(x0, x1)
>>>>
>>>> return x
>>>>
>>>> The problem here is that the definition of ?p0? and/or ?p1? doesn?t dominate their use in the loads ?x0 = p0.x? / ?x1 =
>>>> p1.x?, therefore certain IR verification steps in C2 fail. I was able to work around the issue by adding Phi nodes 
>>>> where
>>>> all inputs are the same (excluding the ctrl), thus creating a ?fake? definition for the value. Please see code below.
>>>
>>> You have original `p = phi(p0, p1)` which is attached to Region node which merges paths with p0 and p1. `Selector ID
>>> Phi(id_p0, id_p1)` should be attached to the same Region and guarantee that p0 and p1 are defined at that point. The
>>> only issue could be is that load nodes don't have control edges and depend on memory edges to schedule. So they could
>>> float up. I think they should be attached (control edge) to id checks (s == id_base*) to prevent them move up as new
>>> special case [1]. At least as first approach for experiment.
>>>
>>> Thanks,
>>> Vladimir K
>>>
>>> [1] 
>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2Fmaster%2Fsrc%2Fhotspot%2Fshare%2Fopto%2Fmemnode.cpp%23L1737&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd6152056b06744f7359e08da10e33a44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637840865379084345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HaPBCqckab%2BpOcIoYEccL04u1o1pqqaUjsYMCslfP7Y%3D&amp;reserved=0 
>>> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2Fmaster*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fmemnode.cpp*23L1737&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Cd6152056b06744f7359e08da10e33a44*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637840865379084345*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=HaPBCqckab*2BpOcIoYEccL04u1o1pqqaUjsYMCslfP7Y*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVTydJtLxg$> 
>>>
>>>
>>>>
>>>> if (?)?? p0 = ?
>>>>
>>>> else ????p1 = ?
>>>>
>>>> phi0 = phi(p0, p0)
>>>>
>>>> phi1 = Phi(p1, p1)
>>>>
>>>> s = # selector phi #
>>>>
>>>> if (s == id_base0)??? ???????x0 = phi0.x
>>>>
>>>> elseif (s == id_base1) ???x1 = phi1.x
>>>>
>>>> else ?????????????????????????????????halt()
>>>>
>>>> x = phi(x0, x1)
>>>>
>>>> return x
>>>>
>>>> Transforming the code to look like the above silenced the verifications ( :-] ) and at the end EA+SR was able to remove
>>>> the allocations **and get rid of all the Phi?s**.
>>>>
>>>> So, my question is: is this workaround acceptable? Do you have a suggestion of a better solution?
>>>>
>>>> TIA, Cesar
>>>>
>>>> *From: *hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.java.net> on behalf of Cesar Soares Lucas
>>>> <Divino.Cesar at microsoft.com>
>>>> *Date: *Tuesday, February 22, 2022 at 10:01 AM
>>>> *To: *Vladimir Ivanov <vladimir.x.ivanov at oracle.com>, Vladimir Kozlov <vladimir.kozlov at oracle.com>, hotspot compiler
>>>> <hotspot-compiler-dev at openjdk.java.net>
>>>> *Cc: *Brian Stafford <Brian.Stafford at microsoft.com>, Martijn Verburg <Martijn.Verburg at microsoft.com>
>>>> *Subject: *Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>>
>>>> Hi Vladimir,
>>>>
>>>> I think I've enough feedback to start working on a prototype and see how things play out. Thank you for sharing your
>>>> ideas/expertise!
>>>>
>>>>
>>>> Cheers,
>>>> Cesar
>>>>
>>>> ________________________________________
>>>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>>>> Sent: February 21, 2022 10:26 AM
>>>> To: Cesar Soares Lucas; Vladimir Kozlov; hotspot compiler
>>>> Cc: Brian Stafford; Martijn Verburg
>>>> Subject: Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>>
>>>> Hi Cesar,
>>>>
>>>>> I with the selector-based base splitting idea using some examples and I think I understand the mechanics well. It's 
>>>>> conceptually simple and quite effective, I like it! I've another question, though. From your previous message I had 
>>>>> understood that we needed the clustering because split_unique_types can't handle multiple bases at once, which 
>>>>> makes sense to me. _This time I
>>>> don't understand why we need to do the clustering before doing the selector-based transformation_. AFAIU this
>>>> transformation won't be creating any memory slices but rather just assigning IDs to different bases and then creating
>>>> specialized memory operations conditionally using the different bases.
>>>>
>>>> Yes, that's a valid simplification. It does sound like introducing
>>>> selector ID doesn't require a separate memory graph (and can be
>>>> performed before split_unique_types()), but I don't have a good
>>>> understanding how complicated simplifying selector-based IR shapes would
>>>> be compared to original (memory op-based) ones. It's definitely worth
>>>> experimenting with.
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>>> ________________________________________
>>>>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>>>>> Sent: February 17, 2022 7:37 AM
>>>>> To: Vladimir Kozlov; Cesar Soares Lucas; hotspot compiler
>>>>> Cc: Brian Stafford; Martijn Verburg
>>>>> Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>>>
>>>>>
>>>>>> But depending on the actual shape of the base pointer (here it's
>>>>>> Phi(obj1,obj2)), it may become infeasible (from performance perspective)
>>>>>> or even impossible (e.g., for complex loop variant conditions) to
>>>>>> separate instance slices.
>>>>>
>>>>> I'd like to correct myself. After thinking more about the problem, I see
>>>>> a universal way to scalarize clusters of interfering non-escaping
>>>>> allocations even in presence of accesses with indeterminate base.
>>>>>
>>>>> The crucial property for such cluster of interacting non-escaping
>>>>> allocations is for any memory access its base is either part of the
>>>>> cluster or not (it's a static property for every access). Then, when it
>>>>> is part of the cluster, then the number of possible base values at
>>>>> runtime is finite and is a subset of the cluster.
>>>>>
>>>>> So, memory graph for the cluster can be scalarized as follows:
>>>>>
>>>>> ???? (1) separate memory graph for the cluster
>>>>>
>>>>> ???? (2) on the newly constructed graph:
>>>>>
>>>>> ??????? (a) replace every base pointer with an ID ("selector id") and
>>>>> recreate data graph for selector IDs from base pointers graph;
>>>>>
>>>>> ??????? (b) for accesses with indeterminate base pointer, replace them
>>>>> with a merge of states from relevant allocations selected by "selector id"
>>>>>
>>>>> ??????? (c) after 2b, all memory accesses from the cluster memory graph
>>>>> should have fixed base pointing at a particular allocation
>>>>>
>>>>> ???? (3) scalarize individual allocations from the cluster one by one
>>>>> (since they are independent now)
>>>>>
>>>>> ??????? - additional transformation (like, split-through-phi) should
>>>>> simplify the graph by reducing the number of cases at merge points to
>>>>> care about (ideally, leaving only a single one);
>>>>>
>>>>>
>>>>>
>>>>> As an illustration:
>>>>>
>>>>> ???? val = Load (AddP (Phi R base1 base2) offset) mem # load A.i
>>>>>
>>>>> ==(pseudo-code)==>
>>>>>
>>>>> ???? selector = (Phi R #base1 #base2)
>>>>>
>>>>> ???? if (selector == #base1) {
>>>>> ?????? val1 = Load (base1 + offset) mem
>>>>> ???? } else if (selector == #base2) {
>>>>> ?????? val2 = Load (base2 + offset) mem
>>>>> ???? } else {
>>>>> ?????? halt(); // impossible
>>>>> ???? }
>>>>>
>>>>> ???? val = Phi(R1, val1, val2)
>>>>>
>>>>> ======
>>>>>
>>>>> ???? Store (AddP (Phi R base1 base2) offset) mem v # store A.i v
>>>>>
>>>>> ==(pseudo-code)==>
>>>>>
>>>>> ???? selector = (Phi R #base1 #base2)
>>>>>
>>>>> ???? if (selector == #base1) {
>>>>> ?????? Store base1 mem v ==> mem1
>>>>> ???? } else if (selector == #base2) {
>>>>> ?????? Store base2 mem v ==> mem2
>>>>> ???? } else {
>>>>> ?????? halt(); // impossible
>>>>> ???? }
>>>>>
>>>>> ???? mem = Phi(R1, mem1, mem2);
>>>>>
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>>>
>>>>>> So, gradual approach seems the way to go:
>>>>>> ???? (1) split memory graph for clusters of interacting non-escaping
>>>>>> allocations;
>>>>>>
>>>>>> ???? (2) perform adhoc transformation targeted at untangling aliasing
>>>>>> accesses (e.g, split-through-phi);
>>>>>>
>>>>>> ???? (3) extract unique instance types where possible, thus making the
>>>>>> corresponding allocation scalar replaceable
>>>>>>
>>>>>> =====================================================================
>>>>>>
>>>>>> Also, one observation: interacting allocations don't have to be of the
>>>>>> same class.
>>>>>>
>>>>>> ?????? static int testPolluted(int r, boolean b) {
>>>>>> ?????????? A obj1 = new B1(r);
>>>>>> ?????????? A obj2 = new B2(r);
>>>>>>
>>>>>> ?????????? A obj = (b ? obj1 : obj2);
>>>>>> ?????????? for (int i = 1; i < r; i++) {
>>>>>> ?????????????? obj.i++;
>>>>>> ?????????? }
>>>>>>
>>>>>> ?????????? return obj1.i + obj2.i;
>>>>>> ?????? }
>>>>>>
>>>>>> Requiring unique instance types to perform SR (and not enhancing SR to
>>>>>> handle aliasing allocations case) helps avoid some challenges in
>>>>>> instance rematerialization logic at safepoints, because actual shape of
>>>>>> the scalarized object (its class and exact set of fields) becomes a
>>>>>> runtime property.
>>>>>>
>>>>>> Best regards,
>>>>>> Vladimir Ivanov
>>>>>>
>>>>>>>>>
>>>>>>>>> Otherwise, I believe wide memory states/merges would pose serious
>>>>>>>>> problems. E.g., when a load is split through a phi, you need to pick
>>>>>>>>> correct memory states for the new loads above the phi which quickly
>>>>>>>>> becomes quite a challenging task.
>>>>>>>>
>>>>>>>> Especially in loops. Actually I did tried such approach before and I
>>>>>>>> agree that it is hard.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Vladimir K
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Vladimir Ivanov
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>> ?????? p0 = Allocate(...);
>>>>>>>>>> ?????? ...
>>>>>>>>>> ?????? p0.x = first;
>>>>>>>>>> ?????? p0.y = second;
>>>>>>>>>>
>>>>>>>>>> ?????? if (cond) {
>>>>>>>>>> ?????????? p1 = Allocate(...);
>>>>>>>>>> ?????????? ...
>>>>>>>>>> ?????????? p1.x = second;
>>>>>>>>>> ?????????? p1.y = first;
>>>>>>>>>> ?????? }
>>>>>>>>>>
>>>>>>>>>> ?????? p = phi(p0, p1) // unused and will be removed
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ?????? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Vladimir K
>>>>>>>>>>
>>>>>>>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>>>>>>>> (BCCing hotspot-dev and moving the discussion to
>>>>>>>>>>> hotspot-compiler-dev.)
>>>>>>>>>>>
>>>>>>>>>>> Hi Cesar,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for looking into enhancing EA.
>>>>>>>>>>>
>>>>>>>>>>> Overall, the proposal looks reasonable.
>>>>>>>>>>>
>>>>>>>>>>> I suggest to look more closely at split_unique_types().
>>>>>>>>>>> It introduces a dedicated class of alias categories for fields of
>>>>>>>>>>> the allocation being eliminated and clones memory graph. I don't
>>>>>>>>>>> see why it shouldn't work for multiple allocations.
>>>>>>>>>>>
>>>>>>>>>>> Moreover, split_unique_types() will break if you start optimizing
>>>>>>>>>>> multiple allocations at once. The notion of unique alias should be
>>>>>>>>>>> adjusted and cover the union of unique aliases for all interacting
>>>>>>>>>>> allocations.
>>>>>>>>>>>
>>>>>>>>>>> Seems like you need to enhance SR to work on non-intersecting
>>>>>>>>>>> clusters of allocations.
>>>>>>>>>>>
>>>>>>>>>>> One thing to take care of: scalar replacement relies on
>>>>>>>>>>> TypeOopPtr::instance_id().
>>>>>>>>>>>
>>>>>>>>>>> ???? // If not InstanceTop or InstanceBot, indicates that this is
>>>>>>>>>>> ???? // a particular instance of this type which is distinct.
>>>>>>>>>>> ???? // This is the node index of the allocation node creating this
>>>>>>>>>>> instance.
>>>>>>>>>>> ???? int?????????? _instance_id;
>>>>>>>>>>>
>>>>>>>>>>> It'll break when multiple allocations are in play.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Vladimir Ivanov
>>>>>>>>>>>
>>>>>>>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>>>>>>>> Hi there again!
>>>>>>>>>>>>
>>>>>>>>>>>> Can you please give me feedback on the following approach to at
>>>>>>>>>>>> least partially
>>>>>>>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>>>>>>>
>>>>>>>>>>>> The problem that I am trying to solve arises when allocations are
>>>>>>>>>>>> merged after a
>>>>>>>>>>>> control flow split. The code below shows _one example_ of such a
>>>>>>>>>>>> situation.
>>>>>>>>>>>>
>>>>>>>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>>>>>>>> ?????? Point p = new Point(x, y);
>>>>>>>>>>>> ?????? if (cond)
>>>>>>>>>>>> ?????????? p = new Point(y, x);
>>>>>>>>>>>> ?????? // Allocations for p are merged here.
>>>>>>>>>>>> ?????? return p.calc();
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> Assuming the method calls on "p" are inlined then the allocations
>>>>>>>>>>>> will not
>>>>>>>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>>>>>>>
>>>>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>>>> ?????? p0 = Allocate(...);
>>>>>>>>>>>> ?????? ...
>>>>>>>>>>>> ?????? p0.x = first;
>>>>>>>>>>>> ?????? p0.y = second;
>>>>>>>>>>>>
>>>>>>>>>>>> ?????? if (cond) {
>>>>>>>>>>>> ?????????? p1 = Allocate(...);
>>>>>>>>>>>> ?????????? ...
>>>>>>>>>>>> ?????????? p1.x = second;
>>>>>>>>>>>> ?????????? p1.y = first;
>>>>>>>>>>>> ?????? }
>>>>>>>>>>>>
>>>>>>>>>>>> ?????? p = phi(p0, p1)
>>>>>>>>>>>>
>>>>>>>>>>>> ?????? return p.x - p.y;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> However, one of the constraints implemented here [2],
>>>>>>>>>>>> specifically the third
>>>>>>>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>>>>>>>
>>>>>>>>>>>> The approach that I'm considering for solving the problem is to
>>>>>>>>>>>> replace the Phi
>>>>>>>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields
>>>>>>>>>>>> of the objects
>>>>>>>>>>>> in the original Phi. The IR for `ex1` would look something like
>>>>>>>>>>>> this after the
>>>>>>>>>>>> transformation:
>>>>>>>>>>>>
>>>>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>>>> ?????? p0 = Allocate(...);
>>>>>>>>>>>> ?????? ...
>>>>>>>>>>>> ?????? p0.x = first;
>>>>>>>>>>>> ?????? p0.y = second;
>>>>>>>>>>>>
>>>>>>>>>>>> ?????? if (cond) {
>>>>>>>>>>>> ?????????? p1 = Allocate(...);
>>>>>>>>>>>> ?????????? ...
>>>>>>>>>>>> ?????????? p1.x = second;
>>>>>>>>>>>> ?????????? p1.y = first;
>>>>>>>>>>>> ?????? }
>>>>>>>>>>>>
>>>>>>>>>>>> ?????? pX = phi(first, second)
>>>>>>>>>>>> ?????? pY = phi(second, first)
>>>>>>>>>>>>
>>>>>>>>>>>> ?????? return pX - pY;
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> I understand that this transformation might not be applicable for
>>>>>>>>>>>> all cases and
>>>>>>>>>>>> that it's not as simple as illustrated above. Also, it seems to
>>>>>>>>>>>> me that much of
>>>>>>>>>>>> what I'd have to implement is already implemented in other steps
>>>>>>>>>>>> of the Scalar
>>>>>>>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>>>>>>>> implementation details I plan to use as much of the existing code
>>>>>>>>>>>> as possible.
>>>>>>>>>>>> The algorithm for the transformation would be like this:
>>>>>>>>>>>>
>>>>>>>>>>>> split_phis(phi)
>>>>>>>>>>>> ?????? # If output of phi escapes, or something uses its identity, etc
>>>>>>>>>>>> ?????? # then we can't remove it. The conditions here might
>>>>>>>>>>>> possible be the
>>>>>>>>>>>> ?????? # same as the ones implemented in
>>>>>>>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>>>>>>>> ?????? if cant_remove_phi_output(phi)
>>>>>>>>>>>> ?????????? return ;
>>>>>>>>>>>>
>>>>>>>>>>>> ?????? # Collect a set of tuples(F,U) containing nodes U that uses
>>>>>>>>>>>> field F
>>>>>>>>>>>> ?????? # member of the object resulting from `phi`.
>>>>>>>>>>>> ?????? fields_used = collect_fields_used_after_phi(phi)
>>>>>>>>>>>>
>>>>>>>>>>>> ?????? foreach field in fields_used
>>>>>>>>>>>> ?????????? producers = {}
>>>>>>>>>>>>
>>>>>>>>>>>> ?????????? # Create a list with the last Store for each field
>>>>>>>>>>>> "field" on the
>>>>>>>>>>>> ?????????? # scope of each of the Phi input objects.
>>>>>>>>>>>> ?????????? foreach o in phi.inputs
>>>>>>>>>>>> ?????????????? # The function called below might re-use a lot of
>>>>>>>>>>>> the code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>>>>>>>> ?????????????? producers += last_store_to_o_field(0, field)
>>>>>>>>>>>> ?????????? # Create a new phi node whose inputs are the Store's to
>>>>>>>>>>>> 'field'
>>>>>>>>>>>> ?????????? field_phi = create_new_phi(producers)
>>>>>>>>>>>>
>>>>>>>>>>>> ?????????? update_consumers(field, field_phi)
>>>>>>>>>>>>
>>>>>>>>>>>> The implementation that I envisioned would be as a "pre-process"
>>>>>>>>>>>> [3] step just
>>>>>>>>>>>> after EA but before the constraint checks in
>>>>>>>>>>>> `adjust_scalar_replaceable_state`
>>>>>>>>>>>> [2]. If we agree that the overall Scalar Replacement
>>>>>>>>>>>> implementation goes through
>>>>>>>>>>>> the following major phases:
>>>>>>>>>>>>
>>>>>>>>>>>> ?????? 1. Identify the Escape Status of objects.
>>>>>>>>>>>> ?????? 2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>>>>>> based on a set of constraints.
>>>>>>>>>>>> ?????? 3. Make call to Split_unique_types [4].
>>>>>>>>>>>> ?????? 4 Iterate over object and array allocations.
>>>>>>>>>>>> ?????????? 4.1 Check if allocation can be eliminated.
>>>>>>>>>>>> ?????????? 4.2 Perform scalar replacement. Replace uses of object
>>>>>>>>>>>> in Safepoints.
>>>>>>>>>>>> ?????????? 4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>>>>>
>>>>>>>>>>>> The transformation that I am proposing would change the overall
>>>>>>>>>>>> flow to look
>>>>>>>>>>>> like this:
>>>>>>>>>>>>
>>>>>>>>>>>> ?????? 1. Identify the Escape Status of objects.
>>>>>>>>>>>> ?????? 2. ----> New: "Split phi functions" <----
>>>>>>>>>>>> ?????? 2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>>>>>> based on a set of constraints.
>>>>>>>>>>>> ?????? 3. Make call to Split_unique_types [14].
>>>>>>>>>>>> ?????? 4 Iterate over object and array allocations.
>>>>>>>>>>>> ?????????? 4.1 ----> Moved to split_phi: "Check if allocation can
>>>>>>>>>>>> be eliminated" <----
>>>>>>>>>>>> ?????????? 4.2 Perform scalar replacement. Replace uses of object
>>>>>>>>>>>> in Safepoints.
>>>>>>>>>>>> ?????????? 4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>>>>>
>>>>>>>>>>>> Please let me know what you think and thank you for taking the
>>>>>>>>>>>> time to review
>>>>>>>>>>>> this!
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Cesar
>>>>>>>>>>>>
>>>>>>>>>>>> Notes:
>>>>>>>>>>>>
>>>>>>>>>>>> ?????? [1] I am not sure yet how this approach will play with the
>>>>>>>>>>>> case of a merge
>>>>>>>>>>>> ?????????? with NULL.
>>>>>>>>>>>> ?????? [2]
>>>>>>>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809%26amp%3Bdata%3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd6152056b06744f7359e08da10e33a44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637840865379134331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2uggNczR4bPxDv15gREOFA65mta6qrilwlZxblgQcYc%3D&amp;reserved=0 
>>>
>>>
>>> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Cd6152056b06744f7359e08da10e33a44*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637840865379134331*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=2uggNczR4bPxDv15gREOFA65mta6qrilwlZxblgQcYc*3D&amp;reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVSj83WW6w$> 
>>>
>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24%26amp%3Bdata%3D04*7C01*7Cdivino.cesar*40microsoft.com*7C8c1737b992e847651e8d08d9f62d649b*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637811497098895122*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3D8hLm9BcYVRF810gFqf2*2B*2Fd28jzqU2k7htD*2FDLqR9vAM*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!c3mFGaPH2PWpbeiHR44WrjfJKF0Ymg6aPQ8EOEMK0t5iYjdL4XwgsEvifrlDVrer2pCrdQ%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd6152056b06744f7359e08da10e33a44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637840865379134331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=MX%2BMB2A%2FyA1sLbSbXPp0uIsckxM5OOc%2Fg%2BqPAMwSgAw%3D&amp;reserved=0 
>>>
>>>
>>> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24*26amp*3Bdata*3D04*7C01*7Cdivino.cesar*40microsoft.com*7C8c1737b992e847651e8d08d9f62d649b*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637811497098895122*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3D8hLm9BcYVRF810gFqf2*2B*2Fd28jzqU2k7htD*2FDLqR9vAM*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!c3mFGaPH2PWpbeiHR44WrjfJKF0Ymg6aPQ8EOEMK0t5iYjdL4XwgsEvifrlDVrer2pCrdQ*24&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Cd6152056b06744f7359e08da10e33a44*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637840865379134331*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=MX*2BMB2A*2FyA1sLbSbXPp0uIsckxM5OOc*2Fg*2BqPAMwSgAw*3D&amp;reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKioqKiUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVQOQ4zHVg$>> 
>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ?????? [3] Another option would be to "patch" the current
>>>>>>>>>>>> implementation to be able
>>>>>>>>>>>> ?????????? to handle the merges. I am not certain that the "patch"
>>>>>>>>>>>> approach would be
>>>>>>>>>>>> ?????????? better, however, the "pre-process" approach is certainly
>>>>>>>>>>>> much easier to test
>>>>>>>>>>>> ?????????? and more readable.
>>>>>>>>>>>>
>>>>>>>>>>>> ?????? [4] I cannot say I understand 100% the effects of executing
>>>>>>>>>>>> ?????????? split_unique_types(). Would the transformation that I am
>>>>>>>>>>>> proposing need to
>>>>>>>>>>>> ?????????? be after the call to split_unique_types?
>>>>
>>>

From vladimir.kozlov at oracle.com  Thu Mar 31 00:26:14 2022
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 30 Mar 2022 17:26:14 -0700
Subject: [External] : Re: RFC : Approach to handle Allocation Merges in C2
 Scalar Replacement
In-Reply-To: <b8f51fab-f18f-d108-a934-169e3cb663a6@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
 <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
 <806f2baa-9b48-e57a-d153-0a19fc3e709d@oracle.com>
 <BY5PR21MB14735BCBF26C72B09051613E9A379@BY5PR21MB1473.namprd21.prod.outlook.com>
 <3cd5e4b1-5a0e-28ef-2445-1bf65fca4422@oracle.com>
 <BY5PR21MB147353D5267885877DFB47D79A3B9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <BY5PR21MB1473482D25CF302438F83A289A129@BY5PR21MB1473.namprd21.prod.outlook.com>
 <cbe335c5-7fb5-ce01-d113-c098f9b6a6b6@oracle.com>
 <DM6PR21MB148490B67DC149401571356E9A1F9@DM6PR21MB1484.namprd21.prod.outlook.com>
 <323c6ace-6f6d-f2d0-a7e9-ed6879afeff4@oracle.com>
 <305685c0-f250-34c1-e1b0-1da92f3c7ddf@oracle.com>
 <b8f51fab-f18f-d108-a934-169e3cb663a6@oracle.com>
Message-ID: <bf522b46-f4ad-213a-f530-dc0949bf54aa@oracle.com>

Actually it is more complicated. May be this approach is incorrect.

Originally it was assumed that we can access directly to p0 and p1 after merge. C2 does not allow it - such access is 
not dominated by its definition. p0.x is illegal in C2 after merge point because we don't know which path is taken 
before merge and p0 could be not defined. Yes, we guard such access with (s == id_base0) check but it does not help 
domination checks in C2.

if (?)   p0 = ?
else     p1 = ?

s = # selector phi #

if (s == id_base0)      x0 = p0.x
elseif (s == id_base1)  x1 = p1.x

x = phi(x0, x1)

May be instead of placing p0|1.x loads after merge with check you can do split "through phi" transformation.
You do exactly what you do today but placing load clones on corresponding input control edges of merge.
You should know (I think) which path correspond to which id_base so you don't need id_base check.
And replace old phi and load with new phi which merges these new loads.

if (?)   { p0 = ?; x0 = p0.x; }
else     { p1 = ?; x1 = p1.x; }

x = phi(x0, x1)

Thanks,
Vladimir K

On 3/30/22 4:54 PM, Vladimir Kozlov wrote:
> I was not able to reproduce the issue with my test and your patch.
> 
> Also try to comment out/remove next your new lines to keep orig_load_mem:
> 
> +? // Create unique input for "memory" of Load
> +? Node* orig_load_mem?? = original_load->in(LoadNode::Memory);
> +? new_load->replace_edge(orig_load_mem, orig_load_mem->is_Phi() ? orig_load_mem->in(idx) : orig_load_mem);
> 
> 
> Thanks,
> Vladimir K
> 
> On 3/30/22 2:32 PM, Vladimir Kozlov wrote:
>> On 3/30/22 2:28 PM, Vladimir Kozlov wrote:
>>> Hi Cesar,
>>>
>>> Can you also send me your test file TestSimpleMerge.java. I need to reproduce your failure.
>>>
>>> Currently I see wrong memeory edge in LoadI [231] node because it points to memory [122] on path which is not fully 
>>> dominating (on code branch).
>>
>> The memory should be this Phi:
>>
>> ??182? Phi? ===? 105? 122? 43? [[ 18 ]]? #memory? Memory: @TestSimpleMerge$Point+12 *, name=x, idx=6; !jvms: 
>> TestSimpleMerge::test @ bci:22 (line 14)
>>
>> May be we got some partial split through Phi transformation which is causing the issue.
>>
>>>
>>> Thanks,
>>> Vladimir K
>>>
>>> [1]
>>>
>>> ??41? Initialize? ===? 33? 1? 44? 1? 1? 40? 90? [[ 42? 43 ]]? !jvms: TestSimpleMerge::test @ bci:0 (line 9)
>>> ??43? Proj? ===? 41? [[ 133? 132? 131? 123? 179? 180? 181? 182? 53? 53? 53? 53? 233 ]] #2? Memory: @rawptr:BotPTR, 
>>> idx=Raw; !jvms: TestSimpleMerge::test @ bci:0 (line 9)
>>> ??101? IfFalse? ===? 99? [[ 105 ]] #0 !jvms: TestSimpleMerge::test @ bci:10 (line 11)
>>>
>>> ??120? Initialize? ===? 112? 1? 123? 1? 1? 119? 171? [[ 121? 122 ]]? !jvms: TestSimpleMerge::test @ bci:13 (line 12)
>>> ??122? Proj? ===? 120? [[ 182? 181? 180? 179? 231 ]] #2? Memory: @rawptr:BotPTR, idx=Raw; !jvms: 
>>> TestSimpleMerge::test @ bci:13 (line 12)
>>> ??121? Proj? ===? 120? [[ 105? 124 ]] #0 !jvms: TestSimpleMerge::test @ bci:13 (line 12)
>>>
>>> ??221? ConI? ===? 0? [[ 220? 225 ]]? #int:0
>>> ??222? ConI? ===? 0? [[ 220 ]]? #int:1
>>>
>>> ??105? Region? ===? 105? 121? 101? [[ 105? 220? 178? 179? 180? 181? 182? 227 ]]? !jvms: TestSimpleMerge::test @ 
>>> bci:22 (line 14)
>>>
>>> ??220? Phi? ===? 105? 221? 222? [[ 225 ]]? #int
>>> ??225? CmpI? === _? 220? 221? [[ 226 ]]
>>> ??226? Bool? === _? 225? [[ 227 ]] [eq]
>>> ??227? If? ===? 105? 226? [[ 228? 229 ]] P=0.000000, C=0.000000
>>>
>>> ??229? IfFalse? ===? 227? [[ 233? 223 ]] #0
>>> ??233? LoadI? ===? 229? 43? 232? [[ 224 ]]? @TestSimpleMerge$Point+12 *, name=x, idx=6; #int !orig=[207] !jvms: 
>>> TestSimpleMerge$Point::calc @ bci:1 (line 5) TestSimpleMerge::test @ bci:23 (line 14)
>>>
>>> ??228? IfTrue? ===? 227? [[ 231? 223 ]] #1
>>> ??231? LoadI? ===? 228? 122? 230? [[ 224 ]]? @TestSimpleMerge$Point+12 *, name=x, idx=6; #int !orig=[207] !jvms: 
>>> TestSimpleMerge$Point::calc @ bci:1 (line 5) TestSimpleMerge::test @ bci:23 (line 14)
>>>
>>> ??223? Region? ===? 223? 228? 229? [[ 223? 224? 216 ]]
>>> ??224? Phi? ===? 223? 231? 233? [[ 216 ]]? #int
>>> ??216? Return? ===? 223? 178? 18? 8? 9 returns 224? [[ 0 ]]
>>>
>>> On 3/29/22 5:34 PM, Cesar Soares Lucas wrote:
>>>> Hi, Vladimir.
>>>>
>>>> Thank you for getting back to me. What you describe is exactly what I understand and what I tried to implement. I 
>>>> also noticed the issue with the nodes floating up and I even tried to prevent that.. but I think the root of the 
>>>> problem is somewhere else.
>>>>
>>>> Please take a look at this printout: https://www.dropbox.com/s/ao30zadovwqswlp/splitted.txt?dl=0 
>>>> <https://urldefense.com/v3/__https://www.dropbox.com/s/ao30zadovwqswlp/splitted.txt?dl=0__;!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVTddI45Zg$> 
>>>> . C2 tells me that this graph has bad dominance: ?Use 228 isn?t dominated by def 231?. This error message is result 
>>>> of this verification: https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp#L5361 
>>>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/loopnode.cpp*L5361__;Iw!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVSGiICGJw$> 
>>>>
>>>>
>>>> I agree and disagree with the message. I?m not sure if it?s my limited knowledge of C2 IR or some wording problem in 
>>>> the message: why would 228 need to be dominated by 231 - after all 228 doesn?t use 231? The opposite makes more 
>>>> sense to me: 228 needs to dominate 231 ? and that is true AFAICT. Nonetheless, I agree with the message that there 
>>>> is something wrong in the graph: this graph allows for execution to reach node 231 without node 124 being executed!
>>>>
>>>> I created this DRAFT PR so that you can look at the code if you want: https://github.com/openjdk/jdk/pull/8023 
>>>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/8023__;!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVQl2jEXlA$> 
>>>> .
>>>>
>>>> Please let me know what you think. TIA!
>>>>
>>>> Cesar
>>>>
>>>> *From: *Vladimir Kozlov <vladimir.kozlov at oracle.com>
>>>> *Date: *Monday, March 28, 2022 at 10:48 AM
>>>> *To: *Cesar Soares Lucas <Divino.Cesar at microsoft.com>, Vladimir Ivanov <vladimir.x.ivanov at oracle.com>, hotspot 
>>>> compiler <hotspot-compiler-dev at openjdk.java.net>
>>>> *Cc: *Brian Stafford <Brian.Stafford at microsoft.com>, Martijn Verburg <Martijn.Verburg at microsoft.com>
>>>> *Subject: *Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>>
>>>> Hi Cesar
>>>>
>>>> On 3/17/22 12:15 PM, Cesar Soares Lucas wrote:
>>>>> Hi all,
>>>>>
>>>>> I?ve been experimenting with the idea explained by Vladimir Ivanov and I was able to implement it and have a few
>>>>> non-trivial merges untangled and scalar replaced. However, I found an obstacle on the road. I was able to overcome it,
>>>>> but I?d very much appreciate your opinion about the matter. Assume we start off with the piece of code below.
>>>>>
>>>>> if (?) ????p0 = ?
>>>>>
>>>>> else ??????p1 = ?
>>>>>
>>>>> p = phi(p0, p1)
>>>>>
>>>>> return p.x
>>>>>
>>>>> The idea proposed suggests, AFAIU, that we change the code to be something like the below **where we use the bases
>>>>> directly**.
>>>>>
>>>>> if (?)?? p0 = ?
>>>>>
>>>>> else ????p1 = ?
>>>>>
>>>>> s = # selector phi #
>>>>>
>>>>> if (s == id_base0)??? ???????x0 = p0.x
>>>>>
>>>>> elseif (s == id_base1) ???x1 = p1.x
>>>>>
>>>>> else ?????????????????????????????????halt()
>>>>>
>>>>> x = phi(x0, x1)
>>>>>
>>>>> return x
>>>>>
>>>>> The problem here is that the definition of ?p0? and/or ?p1? doesn?t dominate their use in the loads ?x0 = p0.x? / 
>>>>> ?x1 =
>>>>> p1.x?, therefore certain IR verification steps in C2 fail. I was able to work around the issue by adding Phi nodes 
>>>>> where
>>>>> all inputs are the same (excluding the ctrl), thus creating a ?fake? definition for the value. Please see code below.
>>>>
>>>> You have original `p = phi(p0, p1)` which is attached to Region node which merges paths with p0 and p1. `Selector ID
>>>> Phi(id_p0, id_p1)` should be attached to the same Region and guarantee that p0 and p1 are defined at that point. The
>>>> only issue could be is that load nodes don't have control edges and depend on memory edges to schedule. So they could
>>>> float up. I think they should be attached (control edge) to id checks (s == id_base*) to prevent them move up as new
>>>> special case [1]. At least as first approach for experiment.
>>>>
>>>> Thanks,
>>>> Vladimir K
>>>>
>>>> [1] 
>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2Fmaster%2Fsrc%2Fhotspot%2Fshare%2Fopto%2Fmemnode.cpp%23L1737&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd6152056b06744f7359e08da10e33a44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637840865379084345%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=HaPBCqckab%2BpOcIoYEccL04u1o1pqqaUjsYMCslfP7Y%3D&amp;reserved=0 
>>>> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2Fmaster*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fmemnode.cpp*23L1737&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Cd6152056b06744f7359e08da10e33a44*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637840865379084345*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=HaPBCqckab*2BpOcIoYEccL04u1o1pqqaUjsYMCslfP7Y*3D&amp;reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVTydJtLxg$> 
>>>>
>>>>
>>>>>
>>>>> if (?)?? p0 = ?
>>>>>
>>>>> else ????p1 = ?
>>>>>
>>>>> phi0 = phi(p0, p0)
>>>>>
>>>>> phi1 = Phi(p1, p1)
>>>>>
>>>>> s = # selector phi #
>>>>>
>>>>> if (s == id_base0)??? ???????x0 = phi0.x
>>>>>
>>>>> elseif (s == id_base1) ???x1 = phi1.x
>>>>>
>>>>> else ?????????????????????????????????halt()
>>>>>
>>>>> x = phi(x0, x1)
>>>>>
>>>>> return x
>>>>>
>>>>> Transforming the code to look like the above silenced the verifications ( :-] ) and at the end EA+SR was able to 
>>>>> remove
>>>>> the allocations **and get rid of all the Phi?s**.
>>>>>
>>>>> So, my question is: is this workaround acceptable? Do you have a suggestion of a better solution?
>>>>>
>>>>> TIA, Cesar
>>>>>
>>>>> *From: *hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.java.net> on behalf of Cesar Soares Lucas
>>>>> <Divino.Cesar at microsoft.com>
>>>>> *Date: *Tuesday, February 22, 2022 at 10:01 AM
>>>>> *To: *Vladimir Ivanov <vladimir.x.ivanov at oracle.com>, Vladimir Kozlov <vladimir.kozlov at oracle.com>, hotspot compiler
>>>>> <hotspot-compiler-dev at openjdk.java.net>
>>>>> *Cc: *Brian Stafford <Brian.Stafford at microsoft.com>, Martijn Verburg <Martijn.Verburg at microsoft.com>
>>>>> *Subject: *Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>>>
>>>>> Hi Vladimir,
>>>>>
>>>>> I think I've enough feedback to start working on a prototype and see how things play out. Thank you for sharing your
>>>>> ideas/expertise!
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Cesar
>>>>>
>>>>> ________________________________________
>>>>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>>>>> Sent: February 21, 2022 10:26 AM
>>>>> To: Cesar Soares Lucas; Vladimir Kozlov; hotspot compiler
>>>>> Cc: Brian Stafford; Martijn Verburg
>>>>> Subject: Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>>>
>>>>> Hi Cesar,
>>>>>
>>>>>> I with the selector-based base splitting idea using some examples and I think I understand the mechanics well. 
>>>>>> It's conceptually simple and quite effective, I like it! I've another question, though. From your previous message 
>>>>>> I had understood that we needed the clustering because split_unique_types can't handle multiple bases at once, 
>>>>>> which makes sense to me. _This time I
>>>>> don't understand why we need to do the clustering before doing the selector-based transformation_. AFAIU this
>>>>> transformation won't be creating any memory slices but rather just assigning IDs to different bases and then creating
>>>>> specialized memory operations conditionally using the different bases.
>>>>>
>>>>> Yes, that's a valid simplification. It does sound like introducing
>>>>> selector ID doesn't require a separate memory graph (and can be
>>>>> performed before split_unique_types()), but I don't have a good
>>>>> understanding how complicated simplifying selector-based IR shapes would
>>>>> be compared to original (memory op-based) ones. It's definitely worth
>>>>> experimenting with.
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>>> ________________________________________
>>>>>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>>>>>> Sent: February 17, 2022 7:37 AM
>>>>>> To: Vladimir Kozlov; Cesar Soares Lucas; hotspot compiler
>>>>>> Cc: Brian Stafford; Martijn Verburg
>>>>>> Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>>>>
>>>>>>
>>>>>>> But depending on the actual shape of the base pointer (here it's
>>>>>>> Phi(obj1,obj2)), it may become infeasible (from performance perspective)
>>>>>>> or even impossible (e.g., for complex loop variant conditions) to
>>>>>>> separate instance slices.
>>>>>>
>>>>>> I'd like to correct myself. After thinking more about the problem, I see
>>>>>> a universal way to scalarize clusters of interfering non-escaping
>>>>>> allocations even in presence of accesses with indeterminate base.
>>>>>>
>>>>>> The crucial property for such cluster of interacting non-escaping
>>>>>> allocations is for any memory access its base is either part of the
>>>>>> cluster or not (it's a static property for every access). Then, when it
>>>>>> is part of the cluster, then the number of possible base values at
>>>>>> runtime is finite and is a subset of the cluster.
>>>>>>
>>>>>> So, memory graph for the cluster can be scalarized as follows:
>>>>>>
>>>>>> ???? (1) separate memory graph for the cluster
>>>>>>
>>>>>> ???? (2) on the newly constructed graph:
>>>>>>
>>>>>> ??????? (a) replace every base pointer with an ID ("selector id") and
>>>>>> recreate data graph for selector IDs from base pointers graph;
>>>>>>
>>>>>> ??????? (b) for accesses with indeterminate base pointer, replace them
>>>>>> with a merge of states from relevant allocations selected by "selector id"
>>>>>>
>>>>>> ??????? (c) after 2b, all memory accesses from the cluster memory graph
>>>>>> should have fixed base pointing at a particular allocation
>>>>>>
>>>>>> ???? (3) scalarize individual allocations from the cluster one by one
>>>>>> (since they are independent now)
>>>>>>
>>>>>> ??????? - additional transformation (like, split-through-phi) should
>>>>>> simplify the graph by reducing the number of cases at merge points to
>>>>>> care about (ideally, leaving only a single one);
>>>>>>
>>>>>>
>>>>>>
>>>>>> As an illustration:
>>>>>>
>>>>>> ???? val = Load (AddP (Phi R base1 base2) offset) mem # load A.i
>>>>>>
>>>>>> ==(pseudo-code)==>
>>>>>>
>>>>>> ???? selector = (Phi R #base1 #base2)
>>>>>>
>>>>>> ???? if (selector == #base1) {
>>>>>> ?????? val1 = Load (base1 + offset) mem
>>>>>> ???? } else if (selector == #base2) {
>>>>>> ?????? val2 = Load (base2 + offset) mem
>>>>>> ???? } else {
>>>>>> ?????? halt(); // impossible
>>>>>> ???? }
>>>>>>
>>>>>> ???? val = Phi(R1, val1, val2)
>>>>>>
>>>>>> ======
>>>>>>
>>>>>> ???? Store (AddP (Phi R base1 base2) offset) mem v # store A.i v
>>>>>>
>>>>>> ==(pseudo-code)==>
>>>>>>
>>>>>> ???? selector = (Phi R #base1 #base2)
>>>>>>
>>>>>> ???? if (selector == #base1) {
>>>>>> ?????? Store base1 mem v ==> mem1
>>>>>> ???? } else if (selector == #base2) {
>>>>>> ?????? Store base2 mem v ==> mem2
>>>>>> ???? } else {
>>>>>> ?????? halt(); // impossible
>>>>>> ???? }
>>>>>>
>>>>>> ???? mem = Phi(R1, mem1, mem2);
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Vladimir Ivanov
>>>>>>
>>>>>>>
>>>>>>> So, gradual approach seems the way to go:
>>>>>>> ???? (1) split memory graph for clusters of interacting non-escaping
>>>>>>> allocations;
>>>>>>>
>>>>>>> ???? (2) perform adhoc transformation targeted at untangling aliasing
>>>>>>> accesses (e.g, split-through-phi);
>>>>>>>
>>>>>>> ???? (3) extract unique instance types where possible, thus making the
>>>>>>> corresponding allocation scalar replaceable
>>>>>>>
>>>>>>> =====================================================================
>>>>>>>
>>>>>>> Also, one observation: interacting allocations don't have to be of the
>>>>>>> same class.
>>>>>>>
>>>>>>> ?????? static int testPolluted(int r, boolean b) {
>>>>>>> ?????????? A obj1 = new B1(r);
>>>>>>> ?????????? A obj2 = new B2(r);
>>>>>>>
>>>>>>> ?????????? A obj = (b ? obj1 : obj2);
>>>>>>> ?????????? for (int i = 1; i < r; i++) {
>>>>>>> ?????????????? obj.i++;
>>>>>>> ?????????? }
>>>>>>>
>>>>>>> ?????????? return obj1.i + obj2.i;
>>>>>>> ?????? }
>>>>>>>
>>>>>>> Requiring unique instance types to perform SR (and not enhancing SR to
>>>>>>> handle aliasing allocations case) helps avoid some challenges in
>>>>>>> instance rematerialization logic at safepoints, because actual shape of
>>>>>>> the scalarized object (its class and exact set of fields) becomes a
>>>>>>> runtime property.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Vladimir Ivanov
>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Otherwise, I believe wide memory states/merges would pose serious
>>>>>>>>>> problems. E.g., when a load is split through a phi, you need to pick
>>>>>>>>>> correct memory states for the new loads above the phi which quickly
>>>>>>>>>> becomes quite a challenging task.
>>>>>>>>>
>>>>>>>>> Especially in loops. Actually I did tried such approach before and I
>>>>>>>>> agree that it is hard.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Vladimir K
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Vladimir Ivanov
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>>> ?????? p0 = Allocate(...);
>>>>>>>>>>> ?????? ...
>>>>>>>>>>> ?????? p0.x = first;
>>>>>>>>>>> ?????? p0.y = second;
>>>>>>>>>>>
>>>>>>>>>>> ?????? if (cond) {
>>>>>>>>>>> ?????????? p1 = Allocate(...);
>>>>>>>>>>> ?????????? ...
>>>>>>>>>>> ?????????? p1.x = second;
>>>>>>>>>>> ?????????? p1.y = first;
>>>>>>>>>>> ?????? }
>>>>>>>>>>>
>>>>>>>>>>> ?????? p = phi(p0, p1) // unused and will be removed
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ?????? return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Vladimir K
>>>>>>>>>>>
>>>>>>>>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>>>>>>>>> (BCCing hotspot-dev and moving the discussion to
>>>>>>>>>>>> hotspot-compiler-dev.)
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Cesar,
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for looking into enhancing EA.
>>>>>>>>>>>>
>>>>>>>>>>>> Overall, the proposal looks reasonable.
>>>>>>>>>>>>
>>>>>>>>>>>> I suggest to look more closely at split_unique_types().
>>>>>>>>>>>> It introduces a dedicated class of alias categories for fields of
>>>>>>>>>>>> the allocation being eliminated and clones memory graph. I don't
>>>>>>>>>>>> see why it shouldn't work for multiple allocations.
>>>>>>>>>>>>
>>>>>>>>>>>> Moreover, split_unique_types() will break if you start optimizing
>>>>>>>>>>>> multiple allocations at once. The notion of unique alias should be
>>>>>>>>>>>> adjusted and cover the union of unique aliases for all interacting
>>>>>>>>>>>> allocations.
>>>>>>>>>>>>
>>>>>>>>>>>> Seems like you need to enhance SR to work on non-intersecting
>>>>>>>>>>>> clusters of allocations.
>>>>>>>>>>>>
>>>>>>>>>>>> One thing to take care of: scalar replacement relies on
>>>>>>>>>>>> TypeOopPtr::instance_id().
>>>>>>>>>>>>
>>>>>>>>>>>> ???? // If not InstanceTop or InstanceBot, indicates that this is
>>>>>>>>>>>> ???? // a particular instance of this type which is distinct.
>>>>>>>>>>>> ???? // This is the node index of the allocation node creating this
>>>>>>>>>>>> instance.
>>>>>>>>>>>> ???? int?????????? _instance_id;
>>>>>>>>>>>>
>>>>>>>>>>>> It'll break when multiple allocations are in play.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Vladimir Ivanov
>>>>>>>>>>>>
>>>>>>>>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>>>>>>>>> Hi there again!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Can you please give me feedback on the following approach to at
>>>>>>>>>>>>> least partially
>>>>>>>>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The problem that I am trying to solve arises when allocations are
>>>>>>>>>>>>> merged after a
>>>>>>>>>>>>> control flow split. The code below shows _one example_ of such a
>>>>>>>>>>>>> situation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>>>>>>>>> ?????? Point p = new Point(x, y);
>>>>>>>>>>>>> ?????? if (cond)
>>>>>>>>>>>>> ?????????? p = new Point(y, x);
>>>>>>>>>>>>> ?????? // Allocations for p are merged here.
>>>>>>>>>>>>> ?????? return p.calc();
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Assuming the method calls on "p" are inlined then the allocations
>>>>>>>>>>>>> will not
>>>>>>>>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>>>>> ?????? p0 = Allocate(...);
>>>>>>>>>>>>> ?????? ...
>>>>>>>>>>>>> ?????? p0.x = first;
>>>>>>>>>>>>> ?????? p0.y = second;
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????? if (cond) {
>>>>>>>>>>>>> ?????????? p1 = Allocate(...);
>>>>>>>>>>>>> ?????????? ...
>>>>>>>>>>>>> ?????????? p1.x = second;
>>>>>>>>>>>>> ?????????? p1.y = first;
>>>>>>>>>>>>> ?????? }
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????? p = phi(p0, p1)
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????? return p.x - p.y;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, one of the constraints implemented here [2],
>>>>>>>>>>>>> specifically the third
>>>>>>>>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The approach that I'm considering for solving the problem is to
>>>>>>>>>>>>> replace the Phi
>>>>>>>>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields
>>>>>>>>>>>>> of the objects
>>>>>>>>>>>>> in the original Phi. The IR for `ex1` would look something like
>>>>>>>>>>>>> this after the
>>>>>>>>>>>>> transformation:
>>>>>>>>>>>>>
>>>>>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>>>>> ?????? p0 = Allocate(...);
>>>>>>>>>>>>> ?????? ...
>>>>>>>>>>>>> ?????? p0.x = first;
>>>>>>>>>>>>> ?????? p0.y = second;
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????? if (cond) {
>>>>>>>>>>>>> ?????????? p1 = Allocate(...);
>>>>>>>>>>>>> ?????????? ...
>>>>>>>>>>>>> ?????????? p1.x = second;
>>>>>>>>>>>>> ?????????? p1.y = first;
>>>>>>>>>>>>> ?????? }
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????? pX = phi(first, second)
>>>>>>>>>>>>> ?????? pY = phi(second, first)
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????? return pX - pY;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> I understand that this transformation might not be applicable for
>>>>>>>>>>>>> all cases and
>>>>>>>>>>>>> that it's not as simple as illustrated above. Also, it seems to
>>>>>>>>>>>>> me that much of
>>>>>>>>>>>>> what I'd have to implement is already implemented in other steps
>>>>>>>>>>>>> of the Scalar
>>>>>>>>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>>>>>>>>> implementation details I plan to use as much of the existing code
>>>>>>>>>>>>> as possible.
>>>>>>>>>>>>> The algorithm for the transformation would be like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>> split_phis(phi)
>>>>>>>>>>>>> ?????? # If output of phi escapes, or something uses its identity, etc
>>>>>>>>>>>>> ?????? # then we can't remove it. The conditions here might
>>>>>>>>>>>>> possible be the
>>>>>>>>>>>>> ?????? # same as the ones implemented in
>>>>>>>>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>>>>>>>>> ?????? if cant_remove_phi_output(phi)
>>>>>>>>>>>>> ?????????? return ;
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????? # Collect a set of tuples(F,U) containing nodes U that uses
>>>>>>>>>>>>> field F
>>>>>>>>>>>>> ?????? # member of the object resulting from `phi`.
>>>>>>>>>>>>> ?????? fields_used = collect_fields_used_after_phi(phi)
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????? foreach field in fields_used
>>>>>>>>>>>>> ?????????? producers = {}
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????????? # Create a list with the last Store for each field
>>>>>>>>>>>>> "field" on the
>>>>>>>>>>>>> ?????????? # scope of each of the Phi input objects.
>>>>>>>>>>>>> ?????????? foreach o in phi.inputs
>>>>>>>>>>>>> ?????????????? # The function called below might re-use a lot of
>>>>>>>>>>>>> the code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>>>>>>>>> ?????????????? producers += last_store_to_o_field(0, field)
>>>>>>>>>>>>> ?????????? # Create a new phi node whose inputs are the Store's to
>>>>>>>>>>>>> 'field'
>>>>>>>>>>>>> ?????????? field_phi = create_new_phi(producers)
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????????? update_consumers(field, field_phi)
>>>>>>>>>>>>>
>>>>>>>>>>>>> The implementation that I envisioned would be as a "pre-process"
>>>>>>>>>>>>> [3] step just
>>>>>>>>>>>>> after EA but before the constraint checks in
>>>>>>>>>>>>> `adjust_scalar_replaceable_state`
>>>>>>>>>>>>> [2]. If we agree that the overall Scalar Replacement
>>>>>>>>>>>>> implementation goes through
>>>>>>>>>>>>> the following major phases:
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????? 1. Identify the Escape Status of objects.
>>>>>>>>>>>>> ?????? 2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>>>>>>> based on a set of constraints.
>>>>>>>>>>>>> ?????? 3. Make call to Split_unique_types [4].
>>>>>>>>>>>>> ?????? 4 Iterate over object and array allocations.
>>>>>>>>>>>>> ?????????? 4.1 Check if allocation can be eliminated.
>>>>>>>>>>>>> ?????????? 4.2 Perform scalar replacement. Replace uses of object
>>>>>>>>>>>>> in Safepoints.
>>>>>>>>>>>>> ?????????? 4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The transformation that I am proposing would change the overall
>>>>>>>>>>>>> flow to look
>>>>>>>>>>>>> like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????? 1. Identify the Escape Status of objects.
>>>>>>>>>>>>> ?????? 2. ----> New: "Split phi functions" <----
>>>>>>>>>>>>> ?????? 2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>>>>>>> based on a set of constraints.
>>>>>>>>>>>>> ?????? 3. Make call to Split_unique_types [14].
>>>>>>>>>>>>> ?????? 4 Iterate over object and array allocations.
>>>>>>>>>>>>> ?????????? 4.1 ----> Moved to split_phi: "Check if allocation can
>>>>>>>>>>>>> be eliminated" <----
>>>>>>>>>>>>> ?????????? 4.2 Perform scalar replacement. Replace uses of object
>>>>>>>>>>>>> in Safepoints.
>>>>>>>>>>>>> ?????????? 4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please let me know what you think and thank you for taking the
>>>>>>>>>>>>> time to review
>>>>>>>>>>>>> this!
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Cesar
>>>>>>>>>>>>>
>>>>>>>>>>>>> Notes:
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????? [1] I am not sure yet how this approach will play with the
>>>>>>>>>>>>> case of a merge
>>>>>>>>>>>>> ?????????? with NULL.
>>>>>>>>>>>>> ?????? [2]
>>>>>>>>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809%26amp%3Bdata%3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd6152056b06744f7359e08da10e33a44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637840865379134331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=2uggNczR4bPxDv15gREOFA65mta6qrilwlZxblgQcYc%3D&amp;reserved=0 
>>>>
>>>>
>>>>
>>>> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Cd6152056b06744f7359e08da10e33a44*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637840865379134331*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=2uggNczR4bPxDv15gREOFA65mta6qrilwlZxblgQcYc*3D&amp;reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVSj83WW6w$> 
>>>>
>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24%26amp%3Bdata%3D04*7C01*7Cdivino.cesar*40microsoft.com*7C8c1737b992e847651e8d08d9f62d649b*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637811497098895122*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3D8hLm9BcYVRF810gFqf2*2B*2Fd28jzqU2k7htD*2FDLqR9vAM*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!c3mFGaPH2PWpbeiHR44WrjfJKF0Ymg6aPQ8EOEMK0t5iYjdL4XwgsEvifrlDVrer2pCrdQ%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd6152056b06744f7359e08da10e33a44%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637840865379134331%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=MX%2BMB2A%2FyA1sLbSbXPp0uIsckxM5OOc%2Fg%2BqPAMwSgAw%3D&amp;reserved=0 
>>>>
>>>>
>>>>
>>>> <https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24*26amp*3Bdata*3D04*7C01*7Cdivino.cesar*40microsoft.com*7C8c1737b992e847651e8d08d9f62d649b*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637811497098895122*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3D8hLm9BcYVRF810gFqf2*2B*2Fd28jzqU2k7htD*2FDLqR9vAM*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!c3mFGaPH2PWpbeiHR44WrjfJKF0Ymg6aPQ8EOEMK0t5iYjdL4XwgsEvifrlDVrer2pCrdQ*24&amp;data=04*7C01*7CDivino.Cesar*40microsoft.com*7Cd6152056b06744f7359e08da10e33a44*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637840865379134331*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000&amp;sdata=MX*2BMB2A*2FyA1sLbSbXPp0uIsckxM5OOc*2Fg*2BqPAMwSgAw*3D&amp;reserved=0__;JSUlJSUlJSUlJSUqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKioqKiUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVQOQ4zHVg$>> 
>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????? [3] Another option would be to "patch" the current
>>>>>>>>>>>>> implementation to be able
>>>>>>>>>>>>> ?????????? to handle the merges. I am not certain that the "patch"
>>>>>>>>>>>>> approach would be
>>>>>>>>>>>>> ?????????? better, however, the "pre-process" approach is certainly
>>>>>>>>>>>>> much easier to test
>>>>>>>>>>>>> ?????????? and more readable.
>>>>>>>>>>>>>
>>>>>>>>>>>>> ?????? [4] I cannot say I understand 100% the effects of executing
>>>>>>>>>>>>> ?????????? split_unique_types(). Would the transformation that I am
>>>>>>>>>>>>> proposing need to
>>>>>>>>>>>>> ?????????? be after the call to split_unique_types?
>>>>>
>>>>

From Divino.Cesar at microsoft.com  Thu Mar 31 18:37:43 2022
From: Divino.Cesar at microsoft.com (Cesar Soares Lucas)
Date: Thu, 31 Mar 2022 18:37:43 +0000
Subject: [External] : Re: RFC : Approach to handle Allocation Merges in C2
 Scalar Replacement
In-Reply-To: <bf522b46-f4ad-213a-f530-dc0949bf54aa@oracle.com>
References: <BY5PR21MB1473BE17FE1EDBD3EF223DF99A2E9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <1d934134-5990-fd90-ede4-4f874d8b5b2e@oracle.com>
 <0b4c520b-cdc6-b820-2f49-85406792ff1d@oracle.com>
 <ab6dae94-9364-97b2-4861-c4f12039bde1@oracle.com>
 <1e5556e9-deb8-483a-a297-27c410c281d3@oracle.com>
 <fa9d50de-3a93-099d-6aa7-973b5eed9acf@oracle.com>
 <806f2baa-9b48-e57a-d153-0a19fc3e709d@oracle.com>
 <BY5PR21MB14735BCBF26C72B09051613E9A379@BY5PR21MB1473.namprd21.prod.outlook.com>
 <3cd5e4b1-5a0e-28ef-2445-1bf65fca4422@oracle.com>
 <BY5PR21MB147353D5267885877DFB47D79A3B9@BY5PR21MB1473.namprd21.prod.outlook.com>
 <BY5PR21MB1473482D25CF302438F83A289A129@BY5PR21MB1473.namprd21.prod.outlook.com>
 <cbe335c5-7fb5-ce01-d113-c098f9b6a6b6@oracle.com>
 <DM6PR21MB148490B67DC149401571356E9A1F9@DM6PR21MB1484.namprd21.prod.outlook.com>
 <323c6ace-6f6d-f2d0-a7e9-ed6879afeff4@oracle.com>
 <305685c0-f250-34c1-e1b0-1da92f3c7ddf@oracle.com>
 <b8f51fab-f18f-d108-a934-169e3cb663a6@oracle.com>
 <bf522b46-f4ad-213a-f530-dc0949bf54aa@oracle.com>
Message-ID: <BY5PR21MB14733E710CBE7A9EA0B478659AE19@BY5PR21MB1473.namprd21.prod.outlook.com>

Hi, Vladimir.

Thank you again for looking at this. I absolutely agree with you: we can?t directly access p0/p1 after the merge. That was the point I was trying to make on my first message in this thread!

> May be instead of placing p0|1.x loads after merge with check you can do split "through phi" transformation.

Actually, since yesterday morning I?ve been playing with this idea and so far, it?s working fine ? no dominance problems. However, I think this will only work for the uses of the merge Phi that don?t have a control input because then they can float up above the merge region. Nevertheless, looks like ?a lot? that in a lot of the merge cases the users of the merge Phi are nodes without a control input + uncommon trap calls. So, we might be able to apply the transformation in ?a good number of cases?.

I?ll keep experimenting with this approach and I?ll keep you posted.

Thanks again and please let me know any thoughts you have about all this.
Cesar


From: Vladimir Kozlov <vladimir.kozlov at oracle.com>
Date: Wednesday, March 30, 2022 at 5:26 PM
To: Cesar Soares Lucas <Divino.Cesar at microsoft.com>, Vladimir Ivanov <vladimir.x.ivanov at oracle.com>, hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
Cc: Brian Stafford <Brian.Stafford at microsoft.com>, Martijn Verburg <Martijn.Verburg at microsoft.com>
Subject: Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
Actually it is more complicated. May be this approach is incorrect.

Originally it was assumed that we can access directly to p0 and p1 after merge. C2 does not allow it - such access is
not dominated by its definition. p0.x is illegal in C2 after merge point because we don't know which path is taken
before merge and p0 could be not defined. Yes, we guard such access with (s == id_base0) check but it does not help
domination checks in C2.

if (?)   p0 = ?
else     p1 = ?

s = # selector phi #

if (s == id_base0)      x0 = p0.x
elseif (s == id_base1)  x1 = p1.x

x = phi(x0, x1)

May be instead of placing p0|1.x loads after merge with check you can do split "through phi" transformation.
You do exactly what you do today but placing load clones on corresponding input control edges of merge.
You should know (I think) which path correspond to which id_base so you don't need id_base check.
And replace old phi and load with new phi which merges these new loads.

if (?)   { p0 = ?; x0 = p0.x; }
else     { p1 = ?; x1 = p1.x; }

x = phi(x0, x1)

Thanks,
Vladimir K

On 3/30/22 4:54 PM, Vladimir Kozlov wrote:
> I was not able to reproduce the issue with my test and your patch.
>
> Also try to comment out/remove next your new lines to keep orig_load_mem:
>
> +  // Create unique input for "memory" of Load
> +  Node* orig_load_mem   = original_load->in(LoadNode::Memory);
> +  new_load->replace_edge(orig_load_mem, orig_load_mem->is_Phi() ? orig_load_mem->in(idx) : orig_load_mem);
>
>
> Thanks,
> Vladimir K
>
> On 3/30/22 2:32 PM, Vladimir Kozlov wrote:
>> On 3/30/22 2:28 PM, Vladimir Kozlov wrote:
>>> Hi Cesar,
>>>
>>> Can you also send me your test file TestSimpleMerge.java. I need to reproduce your failure.
>>>
>>> Currently I see wrong memeory edge in LoadI [231] node because it points to memory [122] on path which is not fully
>>> dominating (on code branch).
>>
>> The memory should be this Phi:
>>
>>   182  Phi  ===  105  122  43  [[ 18 ]]  #memory  Memory: @TestSimpleMerge$Point+12 *, name=x, idx=6; !jvms:
>> TestSimpleMerge::test @ bci:22 (line 14)
>>
>> May be we got some partial split through Phi transformation which is causing the issue.
>>
>>>
>>> Thanks,
>>> Vladimir K
>>>
>>> [1]
>>>
>>>   41  Initialize  ===  33  1  44  1  1  40  90  [[ 42  43 ]]  !jvms: TestSimpleMerge::test @ bci:0 (line 9)
>>>   43  Proj  ===  41  [[ 133  132  131  123  179  180  181  182  53  53  53  53  233 ]] #2  Memory: @rawptr:BotPTR,
>>> idx=Raw; !jvms: TestSimpleMerge::test @ bci:0 (line 9)
>>>   101  IfFalse  ===  99  [[ 105 ]] #0 !jvms: TestSimpleMerge::test @ bci:10 (line 11)
>>>
>>>   120  Initialize  ===  112  1  123  1  1  119  171  [[ 121  122 ]]  !jvms: TestSimpleMerge::test @ bci:13 (line 12)
>>>   122  Proj  ===  120  [[ 182  181  180  179  231 ]] #2  Memory: @rawptr:BotPTR, idx=Raw; !jvms:
>>> TestSimpleMerge::test @ bci:13 (line 12)
>>>   121  Proj  ===  120  [[ 105  124 ]] #0 !jvms: TestSimpleMerge::test @ bci:13 (line 12)
>>>
>>>   221  ConI  ===  0  [[ 220  225 ]]  #int:0
>>>   222  ConI  ===  0  [[ 220 ]]  #int:1
>>>
>>>   105  Region  ===  105  121  101  [[ 105  220  178  179  180  181  182  227 ]]  !jvms: TestSimpleMerge::test @
>>> bci:22 (line 14)
>>>
>>>   220  Phi  ===  105  221  222  [[ 225 ]]  #int
>>>   225  CmpI  === _  220  221  [[ 226 ]]
>>>   226  Bool  === _  225  [[ 227 ]] [eq]
>>>   227  If  ===  105  226  [[ 228  229 ]] P=0.000000, C=0.000000
>>>
>>>   229  IfFalse  ===  227  [[ 233  223 ]] #0
>>>   233  LoadI  ===  229  43  232  [[ 224 ]]  @TestSimpleMerge$Point+12 *, name=x, idx=6; #int !orig=[207] !jvms:
>>> TestSimpleMerge$Point::calc @ bci:1 (line 5) TestSimpleMerge::test @ bci:23 (line 14)
>>>
>>>   228  IfTrue  ===  227  [[ 231  223 ]] #1
>>>   231  LoadI  ===  228  122  230  [[ 224 ]]  @TestSimpleMerge$Point+12 *, name=x, idx=6; #int !orig=[207] !jvms:
>>> TestSimpleMerge$Point::calc @ bci:1 (line 5) TestSimpleMerge::test @ bci:23 (line 14)
>>>
>>>   223  Region  ===  223  228  229  [[ 223  224  216 ]]
>>>   224  Phi  ===  223  231  233  [[ 216 ]]  #int
>>>   216  Return  ===  223  178  18  8  9 returns 224  [[ 0 ]]
>>>
>>> On 3/29/22 5:34 PM, Cesar Soares Lucas wrote:
>>>> Hi, Vladimir.
>>>>
>>>> Thank you for getting back to me. What you describe is exactly what I understand and what I tried to implement. I
>>>> also noticed the issue with the nodes floating up and I even tried to prevent that.. but I think the root of the
>>>> problem is somewhere else.
>>>>
>>>> Please take a look at this printout: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.dropbox.com%2Fs%2Fao30zadovwqswlp%2Fsplitted.txt%3Fdl%3D0&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd319a172369b4a8c76b108da12ad1806%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842831906999763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=IXmQtlUVXzepDjsCeqAIfRFhM5%2BspkcJJEhIY5AajtA%3D&amp;reserved=0
>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.dropbox.com%2Fs%2Fao30zadovwqswlp%2Fsplitted.txt%3Fdl%3D0__%3B!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVTddI45Zg%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd319a172369b4a8c76b108da12ad1806%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842831906999763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=jLVaYpQDjTGdXVGIkA7202ZUICPv0y9jyZ4fJexv1eA%3D&amp;reserved=0>
>>>> . C2 tells me that this graph has bad dominance: ?Use 228 isn?t dominated by def 231?. This error message is result
>>>> of this verification: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2Fmaster%2Fsrc%2Fhotspot%2Fshare%2Fopto%2Floopnode.cpp%23L5361&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd319a172369b4a8c76b108da12ad1806%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842831906999763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3lLLr0kXs9ISVKz184TRXO9V2XNT8xCN97EwSKWG9ec%3D&amp;reserved=0
>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2Fmaster%2Fsrc%2Fhotspot%2Fshare%2Fopto%2Floopnode.cpp*L5361__%3BIw!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVSGiICGJw%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd319a172369b4a8c76b108da12ad1806%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842831906999763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=R7gvTmi%2BrKAtHu3cYg0u%2FQ0uUIn1aGaVsOXjDwHz5V8%3D&amp;reserved=0>
>>>>
>>>>
>>>> I agree and disagree with the message. I?m not sure if it?s my limited knowledge of C2 IR or some wording problem in
>>>> the message: why would 228 need to be dominated by 231 - after all 228 doesn?t use 231? The opposite makes more
>>>> sense to me: 228 needs to dominate 231 ? and that is true AFAICT. Nonetheless, I agree with the message that there
>>>> is something wrong in the graph: this graph allows for execution to reach node 231 without node 124 being executed!
>>>>
>>>> I created this DRAFT PR so that you can look at the code if you want: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fpull%2F8023&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd319a172369b4a8c76b108da12ad1806%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842831906999763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=zL%2FDd0elrCRpi0Kl9jPfhUp72VgwYStHSbpJCNHR%2Fug%3D&amp;reserved=0
>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fpull%2F8023__%3B!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVQl2jEXlA%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd319a172369b4a8c76b108da12ad1806%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842831906999763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=0SMHu2WbEUhYvuc918TQo4NELZ7GSY9047Bo9qiCwuk%3D&amp;reserved=0>
>>>> .
>>>>
>>>> Please let me know what you think. TIA!
>>>>
>>>> Cesar
>>>>
>>>> *From: *Vladimir Kozlov <vladimir.kozlov at oracle.com>
>>>> *Date: *Monday, March 28, 2022 at 10:48 AM
>>>> *To: *Cesar Soares Lucas <Divino.Cesar at microsoft.com>, Vladimir Ivanov <vladimir.x.ivanov at oracle.com>, hotspot
>>>> compiler <hotspot-compiler-dev at openjdk.java.net>
>>>> *Cc: *Brian Stafford <Brian.Stafford at microsoft.com>, Martijn Verburg <Martijn.Verburg at microsoft.com>
>>>> *Subject: *Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>>
>>>> Hi Cesar
>>>>
>>>> On 3/17/22 12:15 PM, Cesar Soares Lucas wrote:
>>>>> Hi all,
>>>>>
>>>>> I?ve been experimenting with the idea explained by Vladimir Ivanov and I was able to implement it and have a few
>>>>> non-trivial merges untangled and scalar replaced. However, I found an obstacle on the road. I was able to overcome it,
>>>>> but I?d very much appreciate your opinion about the matter. Assume we start off with the piece of code below.
>>>>>
>>>>> if (?)     p0 = ?
>>>>>
>>>>> else       p1 = ?
>>>>>
>>>>> p = phi(p0, p1)
>>>>>
>>>>> return p.x
>>>>>
>>>>> The idea proposed suggests, AFAIU, that we change the code to be something like the below **where we use the bases
>>>>> directly**.
>>>>>
>>>>> if (?)   p0 = ?
>>>>>
>>>>> else     p1 = ?
>>>>>
>>>>> s = # selector phi #
>>>>>
>>>>> if (s == id_base0)           x0 = p0.x
>>>>>
>>>>> elseif (s == id_base1)    x1 = p1.x
>>>>>
>>>>> else                                  halt()
>>>>>
>>>>> x = phi(x0, x1)
>>>>>
>>>>> return x
>>>>>
>>>>> The problem here is that the definition of ?p0? and/or ?p1? doesn?t dominate their use in the loads ?x0 = p0.x? /
>>>>> ?x1 =
>>>>> p1.x?, therefore certain IR verification steps in C2 fail. I was able to work around the issue by adding Phi nodes
>>>>> where
>>>>> all inputs are the same (excluding the ctrl), thus creating a ?fake? definition for the value. Please see code below.
>>>>
>>>> You have original `p = phi(p0, p1)` which is attached to Region node which merges paths with p0 and p1. `Selector ID
>>>> Phi(id_p0, id_p1)` should be attached to the same Region and guarantee that p0 and p1 are defined at that point. The
>>>> only issue could be is that load nodes don't have control edges and depend on memory edges to schedule. So they could
>>>> float up. I think they should be attached (control edge) to id checks (s == id_base*) to prevent them move up as new
>>>> special case [1]. At least as first approach for experiment.
>>>>
>>>> Thanks,
>>>> Vladimir K
>>>>
>>>> [1]
>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2Fmaster%2Fsrc%2Fhotspot%2Fshare%2Fopto%2Fmemnode.cpp%23L1737&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd319a172369b4a8c76b108da12ad1806%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842831906999763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=5t39KHr3fRvXMCAjO%2ByJIFsC2dlQAQOznjYRXFxLUvI%3D&amp;reserved=0
>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2Fmaster*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fmemnode.cpp*23L1737%26amp%3Bdata%3D04*7C01*7CDivino.Cesar*40microsoft.com*7Cd6152056b06744f7359e08da10e33a44*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637840865379084345*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3DHaPBCqckab*2BpOcIoYEccL04u1o1pqqaUjsYMCslfP7Y*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVTydJtLxg%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd319a172369b4a8c76b108da12ad1806%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842831906999763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=FJ0ThZu2FbfEaaYFawceKVp5p1wu0bg9F4a3dNaHCDg%3D&amp;reserved=0>
>>>>
>>>>
>>>>>
>>>>> if (?)   p0 = ?
>>>>>
>>>>> else     p1 = ?
>>>>>
>>>>> phi0 = phi(p0, p0)
>>>>>
>>>>> phi1 = Phi(p1, p1)
>>>>>
>>>>> s = # selector phi #
>>>>>
>>>>> if (s == id_base0)           x0 = phi0.x
>>>>>
>>>>> elseif (s == id_base1)    x1 = phi1.x
>>>>>
>>>>> else                                  halt()
>>>>>
>>>>> x = phi(x0, x1)
>>>>>
>>>>> return x
>>>>>
>>>>> Transforming the code to look like the above silenced the verifications ( :-] ) and at the end EA+SR was able to
>>>>> remove
>>>>> the allocations **and get rid of all the Phi?s**.
>>>>>
>>>>> So, my question is: is this workaround acceptable? Do you have a suggestion of a better solution?
>>>>>
>>>>> TIA, Cesar
>>>>>
>>>>> *From: *hotspot-compiler-dev <hotspot-compiler-dev-retn at openjdk.java.net> on behalf of Cesar Soares Lucas
>>>>> <Divino.Cesar at microsoft.com>
>>>>> *Date: *Tuesday, February 22, 2022 at 10:01 AM
>>>>> *To: *Vladimir Ivanov <vladimir.x.ivanov at oracle.com>, Vladimir Kozlov <vladimir.kozlov at oracle.com>, hotspot compiler
>>>>> <hotspot-compiler-dev at openjdk.java.net>
>>>>> *Cc: *Brian Stafford <Brian.Stafford at microsoft.com>, Martijn Verburg <Martijn.Verburg at microsoft.com>
>>>>> *Subject: *Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>>>
>>>>> Hi Vladimir,
>>>>>
>>>>> I think I've enough feedback to start working on a prototype and see how things play out. Thank you for sharing your
>>>>> ideas/expertise!
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Cesar
>>>>>
>>>>> ________________________________________
>>>>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>>>>> Sent: February 21, 2022 10:26 AM
>>>>> To: Cesar Soares Lucas; Vladimir Kozlov; hotspot compiler
>>>>> Cc: Brian Stafford; Martijn Verburg
>>>>> Subject: Re: [External] : Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>>>
>>>>> Hi Cesar,
>>>>>
>>>>>> I with the selector-based base splitting idea using some examples and I think I understand the mechanics well.
>>>>>> It's conceptually simple and quite effective, I like it! I've another question, though. From your previous message
>>>>>> I had understood that we needed the clustering because split_unique_types can't handle multiple bases at once,
>>>>>> which makes sense to me. _This time I
>>>>> don't understand why we need to do the clustering before doing the selector-based transformation_. AFAIU this
>>>>> transformation won't be creating any memory slices but rather just assigning IDs to different bases and then creating
>>>>> specialized memory operations conditionally using the different bases.
>>>>>
>>>>> Yes, that's a valid simplification. It does sound like introducing
>>>>> selector ID doesn't require a separate memory graph (and can be
>>>>> performed before split_unique_types()), but I don't have a good
>>>>> understanding how complicated simplifying selector-based IR shapes would
>>>>> be compared to original (memory op-based) ones. It's definitely worth
>>>>> experimenting with.
>>>>>
>>>>> Best regards,
>>>>> Vladimir Ivanov
>>>>>
>>>>>> ________________________________________
>>>>>> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
>>>>>> Sent: February 17, 2022 7:37 AM
>>>>>> To: Vladimir Kozlov; Cesar Soares Lucas; hotspot compiler
>>>>>> Cc: Brian Stafford; Martijn Verburg
>>>>>> Subject: Re: RFC : Approach to handle Allocation Merges in C2 Scalar Replacement
>>>>>>
>>>>>>
>>>>>>> But depending on the actual shape of the base pointer (here it's
>>>>>>> Phi(obj1,obj2)), it may become infeasible (from performance perspective)
>>>>>>> or even impossible (e.g., for complex loop variant conditions) to
>>>>>>> separate instance slices.
>>>>>>
>>>>>> I'd like to correct myself. After thinking more about the problem, I see
>>>>>> a universal way to scalarize clusters of interfering non-escaping
>>>>>> allocations even in presence of accesses with indeterminate base.
>>>>>>
>>>>>> The crucial property for such cluster of interacting non-escaping
>>>>>> allocations is for any memory access its base is either part of the
>>>>>> cluster or not (it's a static property for every access). Then, when it
>>>>>> is part of the cluster, then the number of possible base values at
>>>>>> runtime is finite and is a subset of the cluster.
>>>>>>
>>>>>> So, memory graph for the cluster can be scalarized as follows:
>>>>>>
>>>>>>      (1) separate memory graph for the cluster
>>>>>>
>>>>>>      (2) on the newly constructed graph:
>>>>>>
>>>>>>         (a) replace every base pointer with an ID ("selector id") and
>>>>>> recreate data graph for selector IDs from base pointers graph;
>>>>>>
>>>>>>         (b) for accesses with indeterminate base pointer, replace them
>>>>>> with a merge of states from relevant allocations selected by "selector id"
>>>>>>
>>>>>>         (c) after 2b, all memory accesses from the cluster memory graph
>>>>>> should have fixed base pointing at a particular allocation
>>>>>>
>>>>>>      (3) scalarize individual allocations from the cluster one by one
>>>>>> (since they are independent now)
>>>>>>
>>>>>>         - additional transformation (like, split-through-phi) should
>>>>>> simplify the graph by reducing the number of cases at merge points to
>>>>>> care about (ideally, leaving only a single one);
>>>>>>
>>>>>>
>>>>>>
>>>>>> As an illustration:
>>>>>>
>>>>>>      val = Load (AddP (Phi R base1 base2) offset) mem # load A.i
>>>>>>
>>>>>> ==(pseudo-code)==>
>>>>>>
>>>>>>      selector = (Phi R #base1 #base2)
>>>>>>
>>>>>>      if (selector == #base1) {
>>>>>>        val1 = Load (base1 + offset) mem
>>>>>>      } else if (selector == #base2) {
>>>>>>        val2 = Load (base2 + offset) mem
>>>>>>      } else {
>>>>>>        halt(); // impossible
>>>>>>      }
>>>>>>
>>>>>>      val = Phi(R1, val1, val2)
>>>>>>
>>>>>> ======
>>>>>>
>>>>>>      Store (AddP (Phi R base1 base2) offset) mem v # store A.i v
>>>>>>
>>>>>> ==(pseudo-code)==>
>>>>>>
>>>>>>      selector = (Phi R #base1 #base2)
>>>>>>
>>>>>>      if (selector == #base1) {
>>>>>>        Store base1 mem v ==> mem1
>>>>>>      } else if (selector == #base2) {
>>>>>>        Store base2 mem v ==> mem2
>>>>>>      } else {
>>>>>>        halt(); // impossible
>>>>>>      }
>>>>>>
>>>>>>      mem = Phi(R1, mem1, mem2);
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> Vladimir Ivanov
>>>>>>
>>>>>>>
>>>>>>> So, gradual approach seems the way to go:
>>>>>>>      (1) split memory graph for clusters of interacting non-escaping
>>>>>>> allocations;
>>>>>>>
>>>>>>>      (2) perform adhoc transformation targeted at untangling aliasing
>>>>>>> accesses (e.g, split-through-phi);
>>>>>>>
>>>>>>>      (3) extract unique instance types where possible, thus making the
>>>>>>> corresponding allocation scalar replaceable
>>>>>>>
>>>>>>> =====================================================================
>>>>>>>
>>>>>>> Also, one observation: interacting allocations don't have to be of the
>>>>>>> same class.
>>>>>>>
>>>>>>>        static int testPolluted(int r, boolean b) {
>>>>>>>            A obj1 = new B1(r);
>>>>>>>            A obj2 = new B2(r);
>>>>>>>
>>>>>>>            A obj = (b ? obj1 : obj2);
>>>>>>>            for (int i = 1; i < r; i++) {
>>>>>>>                obj.i++;
>>>>>>>            }
>>>>>>>
>>>>>>>            return obj1.i + obj2.i;
>>>>>>>        }
>>>>>>>
>>>>>>> Requiring unique instance types to perform SR (and not enhancing SR to
>>>>>>> handle aliasing allocations case) helps avoid some challenges in
>>>>>>> instance rematerialization logic at safepoints, because actual shape of
>>>>>>> the scalarized object (its class and exact set of fields) becomes a
>>>>>>> runtime property.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Vladimir Ivanov
>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Otherwise, I believe wide memory states/merges would pose serious
>>>>>>>>>> problems. E.g., when a load is split through a phi, you need to pick
>>>>>>>>>> correct memory states for the new loads above the phi which quickly
>>>>>>>>>> becomes quite a challenging task.
>>>>>>>>>
>>>>>>>>> Especially in loops. Actually I did tried such approach before and I
>>>>>>>>> agree that it is hard.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Vladimir K
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Vladimir Ivanov
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>>>        p0 = Allocate(...);
>>>>>>>>>>>        ...
>>>>>>>>>>>        p0.x = first;
>>>>>>>>>>>        p0.y = second;
>>>>>>>>>>>
>>>>>>>>>>>        if (cond) {
>>>>>>>>>>>            p1 = Allocate(...);
>>>>>>>>>>>            ...
>>>>>>>>>>>            p1.x = second;
>>>>>>>>>>>            p1.y = first;
>>>>>>>>>>>        }
>>>>>>>>>>>
>>>>>>>>>>>        p = phi(p0, p1) // unused and will be removed
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>        return phi(p0.x,p1.x) - phi(p0.y, p1.y);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Vladimir K
>>>>>>>>>>>
>>>>>>>>>>> On 2/10/22 11:29 AM, Vladimir Ivanov wrote:
>>>>>>>>>>>> (BCCing hotspot-dev and moving the discussion to
>>>>>>>>>>>> hotspot-compiler-dev.)
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Cesar,
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for looking into enhancing EA.
>>>>>>>>>>>>
>>>>>>>>>>>> Overall, the proposal looks reasonable.
>>>>>>>>>>>>
>>>>>>>>>>>> I suggest to look more closely at split_unique_types().
>>>>>>>>>>>> It introduces a dedicated class of alias categories for fields of
>>>>>>>>>>>> the allocation being eliminated and clones memory graph. I don't
>>>>>>>>>>>> see why it shouldn't work for multiple allocations.
>>>>>>>>>>>>
>>>>>>>>>>>> Moreover, split_unique_types() will break if you start optimizing
>>>>>>>>>>>> multiple allocations at once. The notion of unique alias should be
>>>>>>>>>>>> adjusted and cover the union of unique aliases for all interacting
>>>>>>>>>>>> allocations.
>>>>>>>>>>>>
>>>>>>>>>>>> Seems like you need to enhance SR to work on non-intersecting
>>>>>>>>>>>> clusters of allocations.
>>>>>>>>>>>>
>>>>>>>>>>>> One thing to take care of: scalar replacement relies on
>>>>>>>>>>>> TypeOopPtr::instance_id().
>>>>>>>>>>>>
>>>>>>>>>>>>      // If not InstanceTop or InstanceBot, indicates that this is
>>>>>>>>>>>>      // a particular instance of this type which is distinct.
>>>>>>>>>>>>      // This is the node index of the allocation node creating this
>>>>>>>>>>>> instance.
>>>>>>>>>>>>      int           _instance_id;
>>>>>>>>>>>>
>>>>>>>>>>>> It'll break when multiple allocations are in play.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Vladimir Ivanov
>>>>>>>>>>>>
>>>>>>>>>>>> On 09.02.2022 04:45, Cesar Soares Lucas wrote:
>>>>>>>>>>>>> Hi there again!
>>>>>>>>>>>>>
>>>>>>>>>>>>> Can you please give me feedback on the following approach to at
>>>>>>>>>>>>> least partially
>>>>>>>>>>>>> address [1], the scalar replacement allocation merge issue?
>>>>>>>>>>>>>
>>>>>>>>>>>>> The problem that I am trying to solve arises when allocations are
>>>>>>>>>>>>> merged after a
>>>>>>>>>>>>> control flow split. The code below shows _one example_ of such a
>>>>>>>>>>>>> situation.
>>>>>>>>>>>>>
>>>>>>>>>>>>> public int ex1(boolean cond, int x, int y) {
>>>>>>>>>>>>>        Point p = new Point(x, y);
>>>>>>>>>>>>>        if (cond)
>>>>>>>>>>>>>            p = new Point(y, x);
>>>>>>>>>>>>>        // Allocations for p are merged here.
>>>>>>>>>>>>>        return p.calc();
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Assuming the method calls on "p" are inlined then the allocations
>>>>>>>>>>>>> will not
>>>>>>>>>>>>> escape the method. The C2 IR for this method will look like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>>>>>        p0 = Allocate(...);
>>>>>>>>>>>>>        ...
>>>>>>>>>>>>>        p0.x = first;
>>>>>>>>>>>>>        p0.y = second;
>>>>>>>>>>>>>
>>>>>>>>>>>>>        if (cond) {
>>>>>>>>>>>>>            p1 = Allocate(...);
>>>>>>>>>>>>>            ...
>>>>>>>>>>>>>            p1.x = second;
>>>>>>>>>>>>>            p1.y = first;
>>>>>>>>>>>>>        }
>>>>>>>>>>>>>
>>>>>>>>>>>>>        p = phi(p0, p1)
>>>>>>>>>>>>>
>>>>>>>>>>>>>        return p.x - p.y;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, one of the constraints implemented here [2],
>>>>>>>>>>>>> specifically the third
>>>>>>>>>>>>> one, will prevent the objects from being scalar replaced.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The approach that I'm considering for solving the problem is to
>>>>>>>>>>>>> replace the Phi
>>>>>>>>>>>>> node `p = phi(p0, p1)` with new Phi nodes for each of the fields
>>>>>>>>>>>>> of the objects
>>>>>>>>>>>>> in the original Phi. The IR for `ex1` would look something like
>>>>>>>>>>>>> this after the
>>>>>>>>>>>>> transformation:
>>>>>>>>>>>>>
>>>>>>>>>>>>> public int ex1(boolean cond, int first, int second) {
>>>>>>>>>>>>>        p0 = Allocate(...);
>>>>>>>>>>>>>        ...
>>>>>>>>>>>>>        p0.x = first;
>>>>>>>>>>>>>        p0.y = second;
>>>>>>>>>>>>>
>>>>>>>>>>>>>        if (cond) {
>>>>>>>>>>>>>            p1 = Allocate(...);
>>>>>>>>>>>>>            ...
>>>>>>>>>>>>>            p1.x = second;
>>>>>>>>>>>>>            p1.y = first;
>>>>>>>>>>>>>        }
>>>>>>>>>>>>>
>>>>>>>>>>>>>        pX = phi(first, second)
>>>>>>>>>>>>>        pY = phi(second, first)
>>>>>>>>>>>>>
>>>>>>>>>>>>>        return pX - pY;
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> I understand that this transformation might not be applicable for
>>>>>>>>>>>>> all cases and
>>>>>>>>>>>>> that it's not as simple as illustrated above. Also, it seems to
>>>>>>>>>>>>> me that much of
>>>>>>>>>>>>> what I'd have to implement is already implemented in other steps
>>>>>>>>>>>>> of the Scalar
>>>>>>>>>>>>> Replacement pipeline (which is a good thing). To work around these
>>>>>>>>>>>>> implementation details I plan to use as much of the existing code
>>>>>>>>>>>>> as possible.
>>>>>>>>>>>>> The algorithm for the transformation would be like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>> split_phis(phi)
>>>>>>>>>>>>>        # If output of phi escapes, or something uses its identity, etc
>>>>>>>>>>>>>        # then we can't remove it. The conditions here might
>>>>>>>>>>>>> possible be the
>>>>>>>>>>>>>        # same as the ones implemented in
>>>>>>>>>>>>> `PhaseMacroExpand::can_eliminate_allocation`
>>>>>>>>>>>>>        if cant_remove_phi_output(phi)
>>>>>>>>>>>>>            return ;
>>>>>>>>>>>>>
>>>>>>>>>>>>>        # Collect a set of tuples(F,U) containing nodes U that uses
>>>>>>>>>>>>> field F
>>>>>>>>>>>>>        # member of the object resulting from `phi`.
>>>>>>>>>>>>>        fields_used = collect_fields_used_after_phi(phi)
>>>>>>>>>>>>>
>>>>>>>>>>>>>        foreach field in fields_used
>>>>>>>>>>>>>            producers = {}
>>>>>>>>>>>>>
>>>>>>>>>>>>>            # Create a list with the last Store for each field
>>>>>>>>>>>>> "field" on the
>>>>>>>>>>>>>            # scope of each of the Phi input objects.
>>>>>>>>>>>>>            foreach o in phi.inputs
>>>>>>>>>>>>>                # The function called below might re-use a lot of
>>>>>>>>>>>>> the code/logic in `PhaseMacroExpand::scalar_replacement`
>>>>>>>>>>>>>                producers += last_store_to_o_field(0, field)
>>>>>>>>>>>>>            # Create a new phi node whose inputs are the Store's to
>>>>>>>>>>>>> 'field'
>>>>>>>>>>>>>            field_phi = create_new_phi(producers)
>>>>>>>>>>>>>
>>>>>>>>>>>>>            update_consumers(field, field_phi)
>>>>>>>>>>>>>
>>>>>>>>>>>>> The implementation that I envisioned would be as a "pre-process"
>>>>>>>>>>>>> [3] step just
>>>>>>>>>>>>> after EA but before the constraint checks in
>>>>>>>>>>>>> `adjust_scalar_replaceable_state`
>>>>>>>>>>>>> [2]. If we agree that the overall Scalar Replacement
>>>>>>>>>>>>> implementation goes through
>>>>>>>>>>>>> the following major phases:
>>>>>>>>>>>>>
>>>>>>>>>>>>>        1. Identify the Escape Status of objects.
>>>>>>>>>>>>>        2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>>>>>>> based on a set of constraints.
>>>>>>>>>>>>>        3. Make call to Split_unique_types [4].
>>>>>>>>>>>>>        4 Iterate over object and array allocations.
>>>>>>>>>>>>>            4.1 Check if allocation can be eliminated.
>>>>>>>>>>>>>            4.2 Perform scalar replacement. Replace uses of object
>>>>>>>>>>>>> in Safepoints.
>>>>>>>>>>>>>            4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The transformation that I am proposing would change the overall
>>>>>>>>>>>>> flow to look
>>>>>>>>>>>>> like this:
>>>>>>>>>>>>>
>>>>>>>>>>>>>        1. Identify the Escape Status of objects.
>>>>>>>>>>>>>        2. ----> New: "Split phi functions" <----
>>>>>>>>>>>>>        2. Adjust object Escape and/or Scalar Replacement status
>>>>>>>>>>>>> based on a set of constraints.
>>>>>>>>>>>>>        3. Make call to Split_unique_types [14].
>>>>>>>>>>>>>        4 Iterate over object and array allocations.
>>>>>>>>>>>>>            4.1 ----> Moved to split_phi: "Check if allocation can
>>>>>>>>>>>>> be eliminated" <----
>>>>>>>>>>>>>            4.2 Perform scalar replacement. Replace uses of object
>>>>>>>>>>>>> in Safepoints.
>>>>>>>>>>>>>            4.3 Process users of CheckCastPP other than Safepoint:
>>>>>>>>>>>>> AddP, ArrayCopy and CastP2X.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please let me know what you think and thank you for taking the
>>>>>>>>>>>>> time to review
>>>>>>>>>>>>> this!
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Cesar
>>>>>>>>>>>>>
>>>>>>>>>>>>> Notes:
>>>>>>>>>>>>>
>>>>>>>>>>>>>        [1] I am not sure yet how this approach will play with the
>>>>>>>>>>>>> case of a merge
>>>>>>>>>>>>>            with NULL.
>>>>>>>>>>>>>        [2]
>>>>>>>>>>>>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809%26amp%3Bdata%3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd319a172369b4a8c76b108da12ad1806%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842831906999763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=IJDEpZbSiQK1B91xiyZK9wsVAf2zCf3j6fDQUnBV57o%3D&amp;reserved=0
>>>>
>>>>
>>>>
>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24%26amp%3Bdata%3D04*7C01*7CDivino.Cesar*40microsoft.com*7Cd6152056b06744f7359e08da10e33a44*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637840865379134331*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3D2uggNczR4bPxDv15gREOFA65mta6qrilwlZxblgQcYc*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVSj83WW6w%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd319a172369b4a8c76b108da12ad1806%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842831906999763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QggjW9mCum5UO6WrYWAl9Y89Hzml%2BaCrJPQn0ij%2Bdaw%3D&amp;reserved=0>
>>>>
>>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24%26amp%3Bdata%3D04*7C01*7Cdivino.cesar*40microsoft.com*7C8c1737b992e847651e8d08d9f62d649b*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637811497098895122*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3D8hLm9BcYVRF810gFqf2*2B*2Fd28jzqU2k7htD*2FDLqR9vAM*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!c3mFGaPH2PWpbeiHR44WrjfJKF0Ymg6aPQ8EOEMK0t5iYjdL4XwgsEvifrlDVrer2pCrdQ%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd319a172369b4a8c76b108da12ad1806%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842831906999763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=CiPEee%2Fe7y068B%2FsaXRT11llSxkyB7ODxAQHDYtG3Pc%3D&amp;reserved=0
>>>>
>>>>
>>>>
>>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24*26amp*3Bdata*3D04*7C01*7Cdivino.cesar*40microsoft.com*7C8c1737b992e847651e8d08d9f62d649b*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637811497098895122*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3D8hLm9BcYVRF810gFqf2*2B*2Fd28jzqU2k7htD*2FDLqR9vAM*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!c3mFGaPH2PWpbeiHR44WrjfJKF0Ymg6aPQ8EOEMK0t5iYjdL4XwgsEvifrlDVrer2pCrdQ*24%26amp%3Bdata%3D04*7C01*7CDivino.Cesar*40microsoft.com*7Cd6152056b06744f7359e08da10e33a44*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637840865379134331*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3DMX*2BMB2A*2FyA1sLbSbXPp0uIsckxM5OOc*2Fg*2BqPAMwSgAw*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKioqKiUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVQOQ4zHVg%24&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7Cd319a172369b4a8c76b108da12ad1806%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637842831907049666%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=VAt5KvfavglmGy8ei6n3SZh%2B909koba1it2Zr7dIMDI%3D&amp;reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fnam06.safelinks.protection.outlook.com*2F*3Furl*3Dhttps*3A*2F*2Fgithub.com*2Fopenjdk*2Fjdk*2Fblob*2F2f71a6b39ed6bb869b4eb3e81bc1d87f4b3328ff*2Fsrc*2Fhotspot*2Fshare*2Fopto*2Fescape.cpp*23L1809*26amp*3Bdata*3D04*7C01*7CDivino.Cesar*40microsoft.com*7Ce13b0a3de30e43d7ac4408d9f22b75c5*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637807090747649306*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3DWruWqIgGVIzIFIG0gD0*2FEIQm40euLx6FZMexotJVrlE*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!ACWV5N9M2RV99hQ!aWncAwAPjDG2SCD4yFD_Rj6ecIB4iHjD2gepnv2TCHRO5RJznILvC8eoFUe4wgtAURqRWDc*24*26amp*3Bdata*3D04*7C01*7Cdivino.cesar*40microsoft.com*7C8c1737b992e847651e8d08d9f62d649b*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637811497098895122*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*26amp*3Bsdata*3D8hLm9BcYVRF810gFqf2*2B*2Fd28jzqU2k7htD*2FDLqR9vAM*3D*26amp*3Breserved*3D0__*3BJSUlJSUlJSUlJSUqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKiolJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!c3mFGaPH2PWpbeiHR44WrjfJKF0Ymg6aPQ8EOEMK0t5iYjdL4XwgsEvifrlDVrer2pCrdQ*24%26amp%3Bdata%3D04*7C01*7CDivino.Cesar*40microsoft.com*7Cd6152056b06744f7359e08da10e33a44*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637840865379134331*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26amp%3Bsdata%3DMX*2BMB2A*2FyA1sLbSbXPp0uIsckxM5OOc*2Fg*2BqPAMwSgAw*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqJSUlKioqKioqKioqKioqJSUlKioqKiUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!ACWV5N9M2RV99hQ!ZJvmUIbT0x_YJJPA3ap6R-qkOaEsH3YOGwu47flogbZamqV6nWVO2Kfx8uUYnVQOQ4zHVg%24&amp;data=04>>>
>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>        [3] Another option would be to "patch" the current
>>>>>>>>>>>>> implementation to be able
>>>>>>>>>>>>>            to handle the merges. I am not certain that the "patch"
>>>>>>>>>>>>> approach would be
>>>>>>>>>>>>>            better, however, the "pre-process" approach is certainly
>>>>>>>>>>>>> much easier to test
>>>>>>>>>>>>>            and more readable.
>>>>>>>>>>>>>
>>>>>>>>>>>>>        [4] I cannot say I understand 100% the effects of executing
>>>>>>>>>>>>>            split_unique_types(). Would the transformation that I am
>>>>>>>>>>>>> proposing need to
>>>>>>>>>>>>>            be after the call to split_unique_types?
>>>>>
>>>>