Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Ningsheng Jian]

On 7/29/20 7:44 PM, Andrew Haley wrote:

On 20/07/2020 04:51, Ningsheng Jian wrote:

Since we are getting ready to propose Vector API target to JDK 16 [1]. I
have regenerated webrev of aarch64 backend parts from panama repo, which
has been rebased to jdk/jdk very recently, by:

$ hg update vector-unstable && hg diff -r default > all.patch
$ grep "diff -r" all.patch | grep -e "src/hotspot/cpu/aarch64" | awk
'{print $4}' > aarch64_list
$ ksh ./webrev.ksh -r default -o aarch64_webrev aarch64_list

The new webrev:
http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/

Could you please help to take a look?


OK, thanks. It all looks fine. Sorry for the delay.


Thank you Andrew!

Regards,
Ningsheng

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Andrew Haley]

On 20/07/2020 04:51, Ningsheng Jian wrote:
> Since we are getting ready to propose Vector API target to JDK 16 [1]. I 
> have regenerated webrev of aarch64 backend parts from panama repo, which 
> has been rebased to jdk/jdk very recently, by:
> 
> $ hg update vector-unstable && hg diff -r default > all.patch
> $ grep "diff -r" all.patch | grep -e "src/hotspot/cpu/aarch64" | awk 
> '{print $4}' > aarch64_list
> $ ksh ./webrev.ksh -r default -o aarch64_webrev aarch64_list
> 
> The new webrev:
> http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/
> 
> Could you please help to take a look?

OK, thanks. It all looks fine. Sorry for the delay.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Ningsheng Jian]

Thank you Erik!

Regards,
Ningsheng

On 7/23/20 9:06 PM, Erik Joelsson wrote:

Hello Ningsheng,

Build change looks good.

/Erik

On 2020-07-23 01:02, Ningsheng Jian wrote:

Hi Vladimir,

Thanks for pointing out this. Yes, I missed that change in shared 
code. I've regenerated the webrev, with GensrcAdlc.gmk file change 
included:


http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 



Also add build-dev.

Thanks,
Ningsheng

On 7/23/20 5:36 AM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 





FTR there's one more aarch64-specific change in shared code to enable 
aarch64_neon.ad processing:


diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk 
b/make/hotspot/gensrc/GensrcAdlc.gmk

--- a/make/hotspot/gensrc/GensrcAdlc.gmk
+++ b/make/hotspot/gensrc/GensrcAdlc.gmk
@@ -129,6 +129,12 @@

$d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad 
\

  )))

+  ifeq ($(HOTSPOT_TARGET_CPU_ARCH), aarch64)
+    AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
$(AD_SRC_ROOTS), \

+ $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH)_neon.ad \
+    )))
+  endif
+
    ifeq ($(call check-jvm-feature, shenandoahgc), true)
  AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
$(AD_SRC_ROOTS), \


$d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/gc/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad 
\


Best regards,
Vladimir Ivanov


On 7/8/20 3:05 PM, Yang Zhang wrote:

Hi Andrew

I have updated this patch. Could you please help to review it again?
In this patch, the following changes are made:
1. Separate newly added NEON instructions to a new ad file
    aarch64_neon.ad
2. Add assembler tests for NEON instructions. Trailing spaces
    in the python script are also removed.

http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ 



Thanks,
Yang


-Original Message-
From: Andrew Haley 
Sent: Tuesday, June 30, 2020 12:10 AM
To: Yang Zhang ; Viswanathan, Sandhya 
; Paul Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of 
Vector API (Incubator): AArch64 backend changes


On 29/06/2020 08:48, Yang Zhang wrote:

1. Instructions that can be matched with NEON instructions directly.
MulVB, SqrtVF and AbsV have been merged into jdk master already.

2. Instructions that jdk master has middle end support for, but 
they cannot be matched with NEON instructions directly.
Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These 
new instructions can be moved into jdk master first, but for 
auto-vectorization, the performance might not get improved.


3. Panama/Vector API specific  instructions such as 
Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, 
MaxV/MinV, VectorBlend etc.
These instructions cannot be moved into jdk master first because 
there isn't middle-end support.


I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also 
update aarch64_asmtest.py and macroassemler.cpp. When the patch is 
ready, I will send it again.


Thank you *very* much for your hard work. Appreciated!

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com> 
https://keybase.io/andrewhaley

EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Erik Joelsson]

Hello Ningsheng,

Build change looks good.

/Erik

On 2020-07-23 01:02, Ningsheng Jian wrote:

Hi Vladimir,

Thanks for pointing out this. Yes, I missed that change in shared 
code. I've regenerated the webrev, with GensrcAdlc.gmk file change 
included:


http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 



Also add build-dev.

Thanks,
Ningsheng

On 7/23/20 5:36 AM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 




FTR there's one more aarch64-specific change in shared code to enable 
aarch64_neon.ad processing:


diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk 
b/make/hotspot/gensrc/GensrcAdlc.gmk

--- a/make/hotspot/gensrc/GensrcAdlc.gmk
+++ b/make/hotspot/gensrc/GensrcAdlc.gmk
@@ -129,6 +129,12 @@

$d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad 
\

  )))

+  ifeq ($(HOTSPOT_TARGET_CPU_ARCH), aarch64)
+    AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
$(AD_SRC_ROOTS), \

+ $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH)_neon.ad \
+    )))
+  endif
+
    ifeq ($(call check-jvm-feature, shenandoahgc), true)
  AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
$(AD_SRC_ROOTS), \


$d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/gc/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad 
\


Best regards,
Vladimir Ivanov


On 7/8/20 3:05 PM, Yang Zhang wrote:

Hi Andrew

I have updated this patch. Could you please help to review it again?
In this patch, the following changes are made:
1. Separate newly added NEON instructions to a new ad file
    aarch64_neon.ad
2. Add assembler tests for NEON instructions. Trailing spaces
    in the python script are also removed.

http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ 



Thanks,
Yang


-Original Message-
From: Andrew Haley 
Sent: Tuesday, June 30, 2020 12:10 AM
To: Yang Zhang ; Viswanathan, Sandhya 
; Paul Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of 
Vector API (Incubator): AArch64 backend changes


On 29/06/2020 08:48, Yang Zhang wrote:

1. Instructions that can be matched with NEON instructions directly.
MulVB, SqrtVF and AbsV have been merged into jdk master already.

2. Instructions that jdk master has middle end support for, but 
they cannot be matched with NEON instructions directly.
Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These 
new instructions can be moved into jdk master first, but for 
auto-vectorization, the performance might not get improved.


3. Panama/Vector API specific  instructions such as 
Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, 
MaxV/MinV, VectorBlend etc.
These instructions cannot be moved into jdk master first because 
there isn't middle-end support.


I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also 
update aarch64_asmtest.py and macroassemler.cpp. When the patch is 
ready, I will send it again.


Thank you *very* much for your hard work. Appreciated!

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com> 
https://keybase.io/andrewhaley

EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Ningsheng Jian]

Hi Vladimir,

Thanks for pointing out this. Yes, I missed that change in shared code. 
I've regenerated the webrev, with GensrcAdlc.gmk file change included:


http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/

Also add build-dev.

Thanks,
Ningsheng

On 7/23/20 5:36 AM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 



FTR there's one more aarch64-specific change in shared code to enable 
aarch64_neon.ad processing:


diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk 
b/make/hotspot/gensrc/GensrcAdlc.gmk

--- a/make/hotspot/gensrc/GensrcAdlc.gmk
+++ b/make/hotspot/gensrc/GensrcAdlc.gmk
@@ -129,6 +129,12 @@

$d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad 
\

  )))

+  ifeq ($(HOTSPOT_TARGET_CPU_ARCH), aarch64)
+    AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
$(AD_SRC_ROOTS), \

+ $d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH)_neon.ad \
+    )))
+  endif
+
    ifeq ($(call check-jvm-feature, shenandoahgc), true)
  AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
$(AD_SRC_ROOTS), \


$d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/gc/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad 
\


Best regards,
Vladimir Ivanov


On 7/8/20 3:05 PM, Yang Zhang wrote:

Hi Andrew

I have updated this patch. Could you please help to review it again?
In this patch, the following changes are made:
1. Separate newly added NEON instructions to a new ad file
    aarch64_neon.ad
2. Add assembler tests for NEON instructions. Trailing spaces
    in the python script are also removed.

http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ 



Thanks,
Yang


-Original Message-
From: Andrew Haley 
Sent: Tuesday, June 30, 2020 12:10 AM
To: Yang Zhang ; Viswanathan, Sandhya 
; Paul Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of 
Vector API (Incubator): AArch64 backend changes


On 29/06/2020 08:48, Yang Zhang wrote:

1. Instructions that can be matched with NEON instructions directly.
MulVB, SqrtVF and AbsV have been merged into jdk master already.

2. Instructions that jdk master has middle end support for, but they 
cannot be matched with NEON instructions directly.
Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These 
new instructions can be moved into jdk master first, but for 
auto-vectorization, the performance might not get improved.


3. Panama/Vector API specific  instructions such as Load/StoreVector 
( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend 
etc.
These instructions cannot be moved into jdk master first because 
there isn't middle-end support.


I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also 
update aarch64_asmtest.py and macroassemler.cpp. When the patch is 
ready, I will send it again.


Thank you *very* much for your hard work. Appreciated!

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Vladimir Ivanov]

http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/ 


FTR there's one more aarch64-specific change in shared code to enable 
aarch64_neon.ad processing:


diff --git a/make/hotspot/gensrc/GensrcAdlc.gmk 
b/make/hotspot/gensrc/GensrcAdlc.gmk

--- a/make/hotspot/gensrc/GensrcAdlc.gmk
+++ b/make/hotspot/gensrc/GensrcAdlc.gmk
@@ -129,6 +129,12 @@

$d/os_cpu/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_OS)_$(HOTSPOT_TARGET_CPU_ARCH).ad 
\

 )))

+  ifeq ($(HOTSPOT_TARGET_CPU_ARCH), aarch64)
+AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, $(AD_SRC_ROOTS), \
+ 
$d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/$(HOTSPOT_TARGET_CPU_ARCH)_neon.ad \

+)))
+  endif
+
   ifeq ($(call check-jvm-feature, shenandoahgc), true)
 AD_SRC_FILES += $(call uniq, $(wildcard $(foreach d, 
$(AD_SRC_ROOTS), \


$d/cpu/$(HOTSPOT_TARGET_CPU_ARCH)/gc/shenandoah/shenandoah_$(HOTSPOT_TARGET_CPU).ad 
\


Best regards,
Vladimir Ivanov


On 7/8/20 3:05 PM, Yang Zhang wrote:

Hi Andrew

I have updated this patch. Could you please help to review it again?
In this patch, the following changes are made:
1. Separate newly added NEON instructions to a new ad file
    aarch64_neon.ad
2. Add assembler tests for NEON instructions. Trailing spaces
    in the python script are also removed.

http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/ 



Thanks,
Yang


-Original Message-
From: Andrew Haley 
Sent: Tuesday, June 30, 2020 12:10 AM
To: Yang Zhang ; Viswanathan, Sandhya 
; Paul Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of 
Vector API (Incubator): AArch64 backend changes


On 29/06/2020 08:48, Yang Zhang wrote:

1. Instructions that can be matched with NEON instructions directly.
MulVB, SqrtVF and AbsV have been merged into jdk master already.

2. Instructions that jdk master has middle end support for, but they 
cannot be matched with NEON instructions directly.
Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These 
new instructions can be moved into jdk master first, but for 
auto-vectorization, the performance might not get improved.


3. Panama/Vector API specific  instructions such as Load/StoreVector 
( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend 
etc.
These instructions cannot be moved into jdk master first because 
there isn't middle-end support.


I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also 
update aarch64_asmtest.py and macroassemler.cpp. When the patch is 
ready, I will send it again.


Thank you *very* much for your hard work. Appreciated!

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Ningsheng Jian]

Hi Andrew and all,

Since we are getting ready to propose Vector API target to JDK 16 [1]. I 
have regenerated webrev of aarch64 backend parts from panama repo, which 
has been rebased to jdk/jdk very recently, by:


$ hg update vector-unstable && hg diff -r default > all.patch
$ grep "diff -r" all.patch | grep -e "src/hotspot/cpu/aarch64" | awk 
'{print $4}' > aarch64_list

$ ksh ./webrev.ksh -r default -o aarch64_webrev aarch64_list

The new webrev:
http://cr.openjdk.java.net/~njian/vectorapi/8223347-integration/aarch64-webrev.01/

Could you please help to take a look?

Yang's previous webrevs can still be found at [2], with review comments 
addressed in the latest webrev above.


[1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2020-July/042427.html
[2] 
http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/



Thanks,
Ningsheng

On 7/8/20 3:05 PM, Yang Zhang wrote:

Hi Andrew

I have updated this patch. Could you please help to review it again?
In this patch, the following changes are made:
1. Separate newly added NEON instructions to a new ad file
aarch64_neon.ad
2. Add assembler tests for NEON instructions. Trailing spaces
in the python script are also removed.

http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/

Thanks,
Yang


-Original Message-
From: Andrew Haley 
Sent: Tuesday, June 30, 2020 12:10 AM
To: Yang Zhang ; Viswanathan, Sandhya 
; Paul Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

On 29/06/2020 08:48, Yang Zhang wrote:

1. Instructions that can be matched with NEON instructions directly.
MulVB, SqrtVF and AbsV have been merged into jdk master already.

2. Instructions that jdk master has middle end support for, but they cannot be 
matched with NEON instructions directly.
Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new 
instructions can be moved into jdk master first, but for auto-vectorization, 
the performance might not get improved.

3. Panama/Vector API specific  instructions such as Load/StoreVector ( 16 
bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc.
These instructions cannot be moved into jdk master first because there isn't 
middle-end support.

I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also update 
aarch64_asmtest.py and macroassemler.cpp. When the patch is ready, I will send 
it again.


Thank you *very* much for your hard work. Appreciated!

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Yang Zhang]

Hi Andrew

I have updated this patch. Could you please help to review it again?
In this patch, the following changes are made:
1. Separate newly added NEON instructions to a new ad file
   aarch64_neon.ad
2. Add assembler tests for NEON instructions. Trailing spaces
   in the python script are also removed.

http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.02/

Thanks,
Yang


-Original Message-
From: Andrew Haley  
Sent: Tuesday, June 30, 2020 12:10 AM
To: Yang Zhang ; Viswanathan, Sandhya 
; Paul Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

On 29/06/2020 08:48, Yang Zhang wrote:
> 1. Instructions that can be matched with NEON instructions directly.
> MulVB, SqrtVF and AbsV have been merged into jdk master already.
> 
> 2. Instructions that jdk master has middle end support for, but they cannot 
> be matched with NEON instructions directly.
> Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new 
> instructions can be moved into jdk master first, but for auto-vectorization, 
> the performance might not get improved. 
> 
> 3. Panama/Vector API specific  instructions such as Load/StoreVector ( 16 
> bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. 
> These instructions cannot be moved into jdk master first because there isn't 
> middle-end support.
> 
> I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also update 
> aarch64_asmtest.py and macroassemler.cpp. When the patch is ready, I will 
> send it again.

Thank you *very* much for your hard work. Appreciated!

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Yang Zhang]

Hi Sandhya

Thanks very much for your help.

Regards,
Yang

-Original Message-
From: Viswanathan, Sandhya  
Sent: Wednesday, July 1, 2020 2:57 AM
To: Yang Zhang ; Andrew Haley ; Paul 
Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

Hi Yang,

I have merged vectorIntrinsics with changes from panama/default.

Hope this helps.
Best Regards,
Sandhya

-Original Message-
From: Yang Zhang 
Sent: Monday, June 29, 2020 12:49 AM
To: Viswanathan, Sandhya ; Andrew Haley 
; Paul Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

Hi Andrew,

1. Instructions that can be matched with NEON instructions directly.
MulVB, SqrtVF and AbsV have been merged into jdk master already.

2. Instructions that jdk master has middle end support for, but they cannot be 
matched with NEON instructions directly.
Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new 
instructions can be moved into jdk master first, but for auto-vectorization, 
the performance might not get improved. 

3. Panama/Vector API specific  instructions such as Load/StoreVector ( 16 
bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. 
These instructions cannot be moved into jdk master first because there isn't 
middle-end support.

I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also update 
aarch64_asmtest.py and macroassemler.cpp. When the patch is ready, I will send 
it again.



Hi Sandhya,

Could you please help to manual merge panama vectorIntrinsics/vector-unstable 
to jdk master? So that I can update this patch based on latest jdk master.

Regards
Yang


-Original Message-
From: Viswanathan, Sandhya 
Sent: Thursday, June 25, 2020 3:04 AM
To: Yang Zhang ; Andrew Haley ; Paul 
Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

Hi Andrew/Yang,
 
We couldn’t propose Vector API to target in time for JDK 15 and hoping to do so 
early in JDK 16 timeframe.
The implementation reviews on other components have made good progress. 
We have so far ok to PPT from (runtime, shared compiler changes, x86 backend).
Java API implementation review is in progress.
I wanted to check with you both if we have a go ahead from aarch64 backed point 
of view.

Best Regards,
Sandhya

-Original Message-
From: hotspot-compiler-dev  On 
Behalf Of Yang Zhang
Sent: Tuesday, May 26, 2020 7:59 PM
To: Andrew Haley ; Paul Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

> But to my earlier question. please: can the new instructions be moved into 
> jdk head first, and then merged into the Panama branch, or not?

The new instructions can be classified as:
1. Instructions that can be matched with NEON instructions directly.
MulVB and SqrtVF have been merged into jdk master already. The patch of AbsV is 
in review [1].

2. Instructions that Jdk master has middle end support for, but they cannot be 
matched with NEON instructions directly.
Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new 
instructions can be moved into jdk master first, but for auto-vectorization, 
the performance might not get improved.
May I have a new patch for these? 

3. Panama/Vector API specific  instructions Such as Load/StoreVector ( 16 
bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. 
These instructions cannot be moved into jdk master first because there isn't 
middle-end support.

Regards
Yang

[1] 
https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-May/008861.html

-Original Message-
From: Andrew Haley 
Sent: Tuesday, May 26, 2020 4:25 PM
To: Yang Zhang ; Paul Sandoz 
Cc: hotspot-compiler-...@openjdk.java.net; hotspot-...@openjdk.java.net; 
core-libs-dev@openjdk.java.net; aarch64-port-...@openjdk.java.net; nd 

Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

On 25/05/2020 09:26, Yang Zhang wrote:
> In jdk master, what we need to do is that writing m4 file for existing 
> vector instructions and placed them to a new file aarch64_neon.ad.
> If no question, I will do it right away.

I'm not entirely sure that such a change i

RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Viswanathan, Sandhya]

Hi Yang,

I have merged vectorIntrinsics with changes from panama/default.

Hope this helps.
Best Regards,
Sandhya

-Original Message-
From: Yang Zhang  
Sent: Monday, June 29, 2020 12:49 AM
To: Viswanathan, Sandhya ; Andrew Haley 
; Paul Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

Hi Andrew,

1. Instructions that can be matched with NEON instructions directly.
MulVB, SqrtVF and AbsV have been merged into jdk master already.

2. Instructions that jdk master has middle end support for, but they cannot be 
matched with NEON instructions directly.
Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new 
instructions can be moved into jdk master first, but for auto-vectorization, 
the performance might not get improved. 

3. Panama/Vector API specific  instructions such as Load/StoreVector ( 16 
bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. 
These instructions cannot be moved into jdk master first because there isn't 
middle-end support.

I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also update 
aarch64_asmtest.py and macroassemler.cpp. When the patch is ready, I will send 
it again.



Hi Sandhya,

Could you please help to manual merge panama vectorIntrinsics/vector-unstable 
to jdk master? So that I can update this patch based on latest jdk master.

Regards
Yang


-Original Message-
From: Viswanathan, Sandhya 
Sent: Thursday, June 25, 2020 3:04 AM
To: Yang Zhang ; Andrew Haley ; Paul 
Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

Hi Andrew/Yang,
 
We couldn’t propose Vector API to target in time for JDK 15 and hoping to do so 
early in JDK 16 timeframe.
The implementation reviews on other components have made good progress. 
We have so far ok to PPT from (runtime, shared compiler changes, x86 backend).
Java API implementation review is in progress.
I wanted to check with you both if we have a go ahead from aarch64 backed point 
of view.

Best Regards,
Sandhya

-Original Message-
From: hotspot-compiler-dev  On 
Behalf Of Yang Zhang
Sent: Tuesday, May 26, 2020 7:59 PM
To: Andrew Haley ; Paul Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

> But to my earlier question. please: can the new instructions be moved into 
> jdk head first, and then merged into the Panama branch, or not?

The new instructions can be classified as:
1. Instructions that can be matched with NEON instructions directly.
MulVB and SqrtVF have been merged into jdk master already. The patch of AbsV is 
in review [1].

2. Instructions that Jdk master has middle end support for, but they cannot be 
matched with NEON instructions directly.
Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new 
instructions can be moved into jdk master first, but for auto-vectorization, 
the performance might not get improved.
May I have a new patch for these? 

3. Panama/Vector API specific  instructions Such as Load/StoreVector ( 16 
bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. 
These instructions cannot be moved into jdk master first because there isn't 
middle-end support.

Regards
Yang

[1] 
https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-May/008861.html

-Original Message-
From: Andrew Haley 
Sent: Tuesday, May 26, 2020 4:25 PM
To: Yang Zhang ; Paul Sandoz 
Cc: hotspot-compiler-...@openjdk.java.net; hotspot-...@openjdk.java.net; 
core-libs-dev@openjdk.java.net; aarch64-port-...@openjdk.java.net; nd 

Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

On 25/05/2020 09:26, Yang Zhang wrote:
> In jdk master, what we need to do is that writing m4 file for existing 
> vector instructions and placed them to a new file aarch64_neon.ad.
> If no question, I will do it right away.

I'm not entirely sure that such a change is necessary now. In particular, 
reorganizing the existing vector instructions is IMO excessive, but I admit 
that it might be an improvement.

But to my earlier question. please: can the new instructions be moved into jdk 
head first, and then merged into the Panama branch, or not?
It'd help if this was possible.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley
EAC8 43EB D3EF DB9

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Andrew Haley]

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

--
On 29/06/2020 08:48, Yang Zhang wrote:
> 1. Instructions that can be matched with NEON instructions directly.
> MulVB, SqrtVF and AbsV have been merged into jdk master already.
> 
> 2. Instructions that jdk master has middle end support for, but they cannot 
> be matched with NEON instructions directly.
> Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new 
> instructions can be moved into jdk master first, but for auto-vectorization, 
> the performance might not get improved. 
> 
> 3. Panama/Vector API specific  instructions such as Load/StoreVector ( 16 
> bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. 
> These instructions cannot be moved into jdk master first because there isn't 
> middle-end support.
> 
> I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also update 
> aarch64_asmtest.py and macroassemler.cpp. When the patch is ready, I will 
> send it again.

Thank you *very* much for your hard work. Appreciated!

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Yang Zhang]

Hi Andrew,

1. Instructions that can be matched with NEON instructions directly.
MulVB, SqrtVF and AbsV have been merged into jdk master already.

2. Instructions that jdk master has middle end support for, but they cannot be 
matched with NEON instructions directly.
Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new 
instructions can be moved into jdk master first, but for auto-vectorization, 
the performance might not get improved. 

3. Panama/Vector API specific  instructions such as Load/StoreVector ( 16 
bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. 
These instructions cannot be moved into jdk master first because there isn't 
middle-end support.

I will put 2 and 3 in a new ad file aarch64_neon.ad. I will also update 
aarch64_asmtest.py and macroassemler.cpp. When the patch is ready, I will send 
it again.



Hi Sandhya,

Could you please help to manual merge panama vectorIntrinsics/vector-unstable 
to jdk master? So that I can update this patch based on latest jdk master.

Regards
Yang


-Original Message-
From: Viswanathan, Sandhya  
Sent: Thursday, June 25, 2020 3:04 AM
To: Yang Zhang ; Andrew Haley ; Paul 
Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

Hi Andrew/Yang,
 
We couldn’t propose Vector API to target in time for JDK 15 and hoping to do so 
early in JDK 16 timeframe.
The implementation reviews on other components have made good progress. 
We have so far ok to PPT from (runtime, shared compiler changes, x86 backend).
Java API implementation review is in progress.
I wanted to check with you both if we have a go ahead from aarch64 backed point 
of view.

Best Regards,
Sandhya

-Original Message-
From: hotspot-compiler-dev  On 
Behalf Of Yang Zhang
Sent: Tuesday, May 26, 2020 7:59 PM
To: Andrew Haley ; Paul Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

> But to my earlier question. please: can the new instructions be moved into 
> jdk head first, and then merged into the Panama branch, or not?

The new instructions can be classified as:
1. Instructions that can be matched with NEON instructions directly.
MulVB and SqrtVF have been merged into jdk master already. The patch of AbsV is 
in review [1].

2. Instructions that Jdk master has middle end support for, but they cannot be 
matched with NEON instructions directly.
Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new 
instructions can be moved into jdk master first, but for auto-vectorization, 
the performance might not get improved.
May I have a new patch for these? 

3. Panama/Vector API specific  instructions Such as Load/StoreVector ( 16 
bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. 
These instructions cannot be moved into jdk master first because there isn't 
middle-end support.

Regards
Yang

[1] 
https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-May/008861.html

-Original Message-
From: Andrew Haley 
Sent: Tuesday, May 26, 2020 4:25 PM
To: Yang Zhang ; Paul Sandoz 
Cc: hotspot-compiler-...@openjdk.java.net; hotspot-...@openjdk.java.net; 
core-libs-dev@openjdk.java.net; aarch64-port-...@openjdk.java.net; nd 

Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

On 25/05/2020 09:26, Yang Zhang wrote:
> In jdk master, what we need to do is that writing m4 file for existing 
> vector instructions and placed them to a new file aarch64_neon.ad.
> If no question, I will do it right away.

I'm not entirely sure that such a change is necessary now. In particular, 
reorganizing the existing vector instructions is IMO excessive, but I admit 
that it might be an improvement.

But to my earlier question. please: can the new instructions be moved into jdk 
head first, and then merged into the Panama branch, or not?
It'd help if this was possible.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Viswanathan, Sandhya]

Hi Andrew/Yang,
 
We couldn’t propose Vector API to target in time for JDK 15 and hoping to do so 
early in JDK 16 timeframe.
The implementation reviews on other components have made good progress. 
We have so far ok to PPT from (runtime, shared compiler changes, x86 backend).
Java API implementation review is in progress.
I wanted to check with you both if we have a go ahead from aarch64 backed point 
of view.

Best Regards,
Sandhya

-Original Message-
From: hotspot-compiler-dev  On 
Behalf Of Yang Zhang
Sent: Tuesday, May 26, 2020 7:59 PM
To: Andrew Haley ; Paul Sandoz 
Cc: nd ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net
Subject: RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

> But to my earlier question. please: can the new instructions be moved into 
> jdk head first, and then merged into the Panama branch, or not?

The new instructions can be classified as:
1. Instructions that can be matched with NEON instructions directly.
MulVB and SqrtVF have been merged into jdk master already. The patch of AbsV is 
in review [1].

2. Instructions that Jdk master has middle end support for, but they cannot be 
matched with NEON instructions directly.
Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new 
instructions can be moved into jdk master first, but for auto-vectorization, 
the performance might not get improved.
May I have a new patch for these? 

3. Panama/Vector API specific  instructions Such as Load/StoreVector ( 16 
bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. 
These instructions cannot be moved into jdk master first because there isn't 
middle-end support.

Regards
Yang

[1] 
https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-May/008861.html

-Original Message-
From: Andrew Haley 
Sent: Tuesday, May 26, 2020 4:25 PM
To: Yang Zhang ; Paul Sandoz 
Cc: hotspot-compiler-...@openjdk.java.net; hotspot-...@openjdk.java.net; 
core-libs-dev@openjdk.java.net; aarch64-port-...@openjdk.java.net; nd 

Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

On 25/05/2020 09:26, Yang Zhang wrote:
> In jdk master, what we need to do is that writing m4 file for existing 
> vector instructions and placed them to a new file aarch64_neon.ad.
> If no question, I will do it right away.

I'm not entirely sure that such a change is necessary now. In particular, 
reorganizing the existing vector instructions is IMO excessive, but I admit 
that it might be an improvement.

But to my earlier question. please: can the new instructions be moved into jdk 
head first, and then merged into the Panama branch, or not?
It'd help if this was possible.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Yang Zhang]

> But to my earlier question. please: can the new instructions be moved into 
> jdk head first, and then merged into the Panama branch, or not?

The new instructions can be classified as:
1. Instructions that can be matched with NEON instructions directly.
MulVB and SqrtVF have been merged into jdk master already. The patch of AbsV is 
in review [1].

2. Instructions that Jdk master has middle end support for, but they cannot be 
matched with NEON instructions directly.
Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV
These new instructions can be moved into jdk master first, but for 
auto-vectorization, the performance might not get improved.
May I have a new patch for these? 

3. Panama/Vector API specific  instructions
Such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, 
MaxV/MinV, VectorBlend etc. 
These instructions cannot be moved into jdk master first because there isn't 
middle-end support.

Regards
Yang

[1] 
https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-May/008861.html

-Original Message-
From: Andrew Haley  
Sent: Tuesday, May 26, 2020 4:25 PM
To: Yang Zhang ; Paul Sandoz 
Cc: hotspot-compiler-...@openjdk.java.net; hotspot-...@openjdk.java.net; 
core-libs-dev@openjdk.java.net; aarch64-port-...@openjdk.java.net; nd 

Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

On 25/05/2020 09:26, Yang Zhang wrote:
> In jdk master, what we need to do is that writing m4 file for existing 
> vector instructions and placed them to a new file aarch64_neon.ad.
> If no question, I will do it right away.

I'm not entirely sure that such a change is necessary now. In particular, 
reorganizing the existing vector instructions is IMO excessive, but I admit 
that it might be an improvement.

But to my earlier question. please: can the new instructions be moved into jdk 
head first, and then merged into the Panama branch, or not?
It'd help if this was possible.

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Andrew Haley]

On 25/05/2020 09:26, Yang Zhang wrote:
> In jdk master, what we need to do is that writing m4 file for existing
> vector instructions and placed them to a new file aarch64_neon.ad.
> If no question, I will do it right away.

I'm not entirely sure that such a change is necessary now. In particular,
reorganizing the existing vector instructions is IMO excessive, but I
admit that it might be an improvement.

But to my earlier question. please: can the new instructions be moved
into jdk head first, and then merged into the Panama branch, or not?
It'd help if this was possible.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

RE: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Yang Zhang]

Hi  Andrew

Please check the following.

>> We have made changes similar in spirit to the x64 ad file (reducing in size 
>> at least), so I think it reasonable request before integration to reduce the 
>> cognitive and maintenance burden.
> So here's a question: can the changes to the AArch64 back end be made to 
> mainline now? Or is there a problem in that the C2 patterns being used don't 
> exist?

X86 ad file has been refactored to reduce code size in  a series of
JBSs [1]. I also investigated how to make similar changes to AArch64
ad file in Aug 2019. In summary, these changes wouldn't have a great
impact on AArch64. If making similar changes to AArch64, about ~200kb
(1% of total code size) will be reduced [2]. So I don't think we need to make
these changes to AArch64 for now.

To reduce maintenance burden, I agree that all the vector stuff should be
moved into a new file, just like AArch64 SVE has done [3]. All the SVE
instructions are generated by m4 file and placed in aarch64_sve.ad. 
For newly added NEON instructions in Vector API, they are all generated by
m4 file. In jdk master, what we need to do is that writing m4 file for existing
vector instructions and placed them to a new file aarch64_neon.ad.
If no question, I will do it right away.

[1] https://bugs.openjdk.java.net/browse/JDK-8230015 
[2] The data came from:
I implement an example (merging vaddB/S/I/F) in AArch64 platform. The
code size reduction in libjvm.so is ~15kb. If all the vector instructions
are merged, the estimated size reduction would be ~200kb.
The code size from vector support in AArch64 backend is ~450kb (2% of
total size). Original libjvm.so is 20770256, while libjvm.so without
vector support is 20317328. Based on the idea of generic vector operands,
half of vector stuff can be removed. So the estimated size
reduction is also ~200kb.
[3] 
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-March/037628.html

Regards
Yang



-Original Message-
From: Andrew Haley  
Sent: Saturday, May 23, 2020 5:16 PM
To: Paul Sandoz 
Cc: Yang Zhang ; hotspot-compiler-...@openjdk.java.net; 
hotspot-...@openjdk.java.net; core-libs-dev@openjdk.java.net; 
aarch64-port-...@openjdk.java.net; nd 
Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API 
(Incubator): AArch64 backend changes

On 5/22/20 7:01 PM, Paul Sandoz wrote:
> We have made changes similar in spirit to the x64 ad file (reducing in size 
> at least), so I think it reasonable request before integration to reduce the 
> cognitive and maintenance burden.

So here's a question: can the changes to the AArch64 back end be made to 
mainline now? Or is there a problem in that the C2 patterns being used don't 
exist?

--
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Andrew Haley]

On 5/22/20 7:01 PM, Paul Sandoz wrote:
> We have made changes similar in spirit to the x64 ad file (reducing in size 
> at least), so I think it reasonable request before integration to reduce the 
> cognitive and maintenance burden.

So here's a question: can the changes to the AArch64 back end be made to
mainline now? Or is there a problem in that the C2 patterns being used
don't exist?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Paul Sandoz]

> On May 22, 2020, at 10:40 AM, Andrew Haley  wrote:
> 
> On 5/22/20 5:12 PM, Paul Sandoz wrote:
> 
>> I am not terribly familiar with the AArch64 code, but I would note
>> the Vector API comes with a bunch of unit tests should exercise the
>> code gen, just not as directly as I presume you would like.
> 
> Yes, you've understood me: direct is what I want. The assembler tests
> are intended to make sure we generate exactly the right instructions,
> rather than having something painfully hard to debug later on. When a
> patch adds a lot of instructions to the assembler, that IMO is the
> right time to test that they generate correctly-encoded
> instructions. But yes, that can go into a follow-up patch, as long as
> it gets done fairly shortly.

Ok.


> 
>> To what extent do you feel we can follow up with additional issues
>> and fix them after the initial integration?
> 
> We can do that. Note that after this patch, aarch64.ad is 21762 lines
> long. I know we don't have any hard-and-fast rule about this, but I'd
> rather it didn't get forgotten.

We have made changes similar in spirit to the x64 ad file (reducing in size at 
least), so I think it reasonable request before integration to reduce the 
cognitive and maintenance burden.

(FWIW I don’t know to what extent some functionality is utilized by the auto 
vectorizer and whether that impacts its location or not.) 


> Maybe I should do that one myself, but
> I guess I'd rather avoid the problem of version skew between the
> Panama repo and mainline. That'd make merging rather grim.
> 
> Yang, against which repo is this webrev intended to be applied?
> 

I cannot speak for Yang but we have been generating webrevs from the Panama dev 
repo, branch vector-unstable (unfortunate name I know!) and doing:

  hg diff -r default

Where the default is regularly, but manually, pulled from jdk/jdk.

More specifically:

- code is generally pushed to the vectorIntrinsics branch

- on a manual but regular basis vectorIntrinsics is synced up to jdk/jdk (via 
the default branch).

- on a manual but regular basis vector-unstable is synced with vectorIntrinsics

- occasionally there are fixes pushed directly to vector-unstable for the 
purposes of integration (e.g. removal of the perf test or the x64 SVML stubs).

Hth,
Paul.

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Andrew Haley]

On 5/22/20 5:12 PM, Paul Sandoz wrote:

> I am not terribly familiar with the AArch64 code, but I would note
> the Vector API comes with a bunch of unit tests should exercise the
> code gen, just not as directly as I presume you would like.

Yes, you've understood me: direct is what I want. The assembler tests
are intended to make sure we generate exactly the right instructions,
rather than having something painfully hard to debug later on. When a
patch adds a lot of instructions to the assembler, that IMO is the
right time to test that they generate correctly-encoded
instructions. But yes, that can go into a follow-up patch, as long as
it gets done fairly shortly.

> To what extent do you feel we can follow up with additional issues
> and fix them after the initial integration?

We can do that. Note that after this patch, aarch64.ad is 21762 lines
long. I know we don't have any hard-and-fast rule about this, but I'd
rather it didn't get forgotten. Maybe I should do that one myself, but
I guess I'd rather avoid the problem of version skew between the
Panama repo and mainline. That'd make merging rather grim.

Yang, against which repo is this webrev intended to be applied?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Paul Sandoz]

HI Andrew,

Thanks for looking. 

I am not terribly familiar with the AArch64 code, but I would note the Vector 
API comes with a bunch of unit tests should exercise the code gen, just not as 
directly as I presume you would like.

To what extent do you feel we can follow up with additional issues and fix them 
after the initial integration?

Paul.


> On May 22, 2020, at 6:00 AM, Andrew Haley  wrote:
> 
> On 5/19/20 11:55 AM, Yang Zhang wrote:
>> Following up on review requests of API [0], Java implementation and
>> test [1], General Hotspot changes[2] for Vector API and x86 backend
>> changes [3]. Here's a request for review of AArch64 backend changes
>> required for supporting the Vector API:
>> 
>> JEP: https://openjdk.java.net/jeps/338
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8223347
>> Webrev: 
>> http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.01/
>> 
>> Complete implementation resides in vector-unstable branch of panama/dev
>> repository [4].
> 
> This looks great, and it's very impressive. Unfortunately, there are few
> of us sufficiently knowledgeable about Panama to review it in the detail
> that perhaps it deserves. I'm happy with it.
> 
> However, we need tests for the new assembly instructions, so please add some
> to aarch64_asmtest.py and update macroassemler.cpp.
> 
> Also, aarch64.ad is getting to be far too large, and perhaps all the vector
> stuff should be moved into a new file. Thanks.
> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. 
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 

Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes

[Andrew Haley]

On 5/19/20 11:55 AM, Yang Zhang wrote:
> Following up on review requests of API [0], Java implementation and
> test [1], General Hotspot changes[2] for Vector API and x86 backend
> changes [3]. Here's a request for review of AArch64 backend changes
> required for supporting the Vector API:
> 
> JEP: https://openjdk.java.net/jeps/338
> JBS: https://bugs.openjdk.java.net/browse/JDK-8223347
> Webrev: 
> http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.01/
> 
> Complete implementation resides in vector-unstable branch of panama/dev
> repository [4].

This looks great, and it's very impressive. Unfortunately, there are few
of us sufficiently knowledgeable about Panama to review it in the detail
that perhaps it deserves. I'm happy with it.

However, we need tests for the new assembly instructions, so please add some
to aarch64_asmtest.py and update macroassemler.cpp.

Also, aarch64.ad is getting to be far too large, and perhaps all the vector
stuff should be moved into a new file. Thanks.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. 
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671