Re: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support

Hi Ningsheng, >> postaloc.cpp:312 & 322 >> >> 311 if (lrgs(val_idx).is_scalable()) { >> 312   assert(val->ideal_reg() == Op_VecA, "scalable vector >> register"); >> >> . . . >> >> 321   if (lrgs(val_idx).is_scalable()) { >> 322 assert(val->ideal_reg() == Op_VecA, "scal

Re: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support

On 20/08/2020 03:27, Ningsheng Jian wrote: > // Note that a vector register with 4 slots, denotes a 128-bit NEON Lose the comma. :-) Never known to miss a trivial point, -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhale

Re: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support

On 20/08/2020 05:48, Nick Gasson wrote: > On 08/19/20 19:10 pm, Andrew Haley wrote: >> On 19/08/2020 11:05, Magnus Ihse Bursie wrote: >>> This is maybe not relevant, but I was surprised to find >>> src/hotspot/cpu/aarch64/aarch64-asmtest.py, because a) it's python code, >>> and b) the name implies

Re: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support

On 20/08/2020 05:48, Nick Gasson wrote: > On 08/19/20 19:10 pm, Andrew Haley wrote: >> On 19/08/2020 11:05, Magnus Ihse Bursie wrote: >>> This is maybe not relevant, but I was surprised to find >>> src/hotspot/cpu/aarch64/aarch64-asmtest.py, because a) it's python code, >>> and b) the name implies

Re: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support

Hi Andrew, On 08/20/20 16:48 pm, Andrew Dinn wrote: >> >> It is perhaps a bit strange to have the test code under src/ and >> embedded in the assembler implementation. How about we move it under >> test/ using the existing gtest framework for native code tests? That >> runs in tier1 and also for

Re: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support

Hi, On 20/08/2020 09:58, Nick Gasson wrote: > > On 08/20/20 16:48 pm, Andrew Dinn wrote: >>> >>> It is perhaps a bit strange to have the test code under src/ and >>> embedded in the assembler implementation. How about we move it under >>> test/ using the existing gtest framework for native code te

Re: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support

On 08/20/20 17:08 pm, Andrew Haley wrote: >> >> I meant move the test itself - entry() and asm_check() in >> assembler_aarch64.cpp - under test/hotspot/gtest. The generator would >> move with it. > > Hmm. I'm still not sure how this would work. Let's see the patch and > we can talk about it. It sti

Re: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support

On 2020-08-20 11:40, Nick Gasson wrote: On 08/20/20 17:08 pm, Andrew Haley wrote: I meant move the test itself - entry() and asm_check() in assembler_aarch64.cpp - under test/hotspot/gtest. The generator would move with it. Hmm. I'm still not sure how this would work. Let's see the patch and we

Re: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support

On 20/08/2020 11:14, Magnus Ihse Bursie wrote: > On 2020-08-20 11:40, Nick Gasson wrote: >> http://cr.openjdk.java.net/~ngasson/asmtest/webrev.0/ >> >> Then you'd run it with >> >>    make exploded-test TEST="gtest:AssemblerAArch64" >> >> The downside is that it won't run on every startup of a debu

Re: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support

On 20/08/2020 11:38, Andrew Dinn wrote: > Well, perhaps this check ought to be done as a standalone test rather > than as debug build validation. I don't really have any deep commitment > either way. However, if we do proceed with this I think it ought to be > in a separate follow-up patch and with

Re: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support

On 2020-08-20 12:38, Andrew Dinn wrote: On 20/08/2020 11:14, Magnus Ihse Bursie wrote: On 2020-08-20 11:40, Nick Gasson wrote: http://cr.openjdk.java.net/~ngasson/asmtest/webrev.0/ Then you'd run it with    make exploded-test TEST="gtest:AssemblerAArch64" The downside is that it won't run o

RFR: 8251854 [macosx] Java forces the use of discrete GPU

Hello. Please review the fix for jdk/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8251854 Fix: http://cr.openjdk.java.net/~serb/8251854/webrev.00 This is a review request for the bug particularly fixed some time ago: https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html I