8251193: bin/idea.sh is generating wrong folder definitions for JVMCI modules #63
Conversation
… modules Reviewed-by: mcimadamore Contributed-by: Galder Zamarreno <galder@redhat.com>
|
👋 Welcome back sgehwolf! A progress list of the required criteria for merging this PR into |
|
@jerboaa The following labels will be automatically applied to this pull request: When this pull request is ready to be reviewed, an RFR email will be sent to the corresponding mailing lists. If you would like to change these labels, use the |
openjdk
bot
added
build
|
/label remove "rfr" |
|
@jerboaa Usage:
|
|
/label remove "core-libs" |
|
@jerboaa Usage:
|
|
/label remove "build" |
|
@jerboaa Usage:
|
|
/label remove build |
|
@jerboaa |
|
/label remove core-libs |
|
@jerboaa |
|
/contributor add Galder Zamarreno <galder@redhat.com> |
|
@jerboaa |
|
/contributor remove Galder Zamarreno <galder@redhat.com> |
|
@jerboaa |
|
/contributor add Galder Zamarreno galder@redhat.com |
|
@jerboaa |
|
/sponsor |
|
@mcimadamore This change does not need sponsoring - the author is allowed to integrate it. |
|
@jerboaa This change now passes all automated pre-integration checks. When the change also fulfills all project specific requirements, type
There are currently no new commits on the ➡️ To integrate this PR with the above commit message to the |
|
/integrate |
openjdk
bot
added
integrated
This patch aims to optimize extract operation on vector for AArch64
according to Neoverse N2 and V1 software optimization guide[1][2].
Currently, extract operation is used by "Vector.lane"[3]. As SVE
doesn’t have direct instruction support for such operation like
"pextr"[4] in x86, the final code is 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
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, openjdk#63
smov x10, v17.b[0]
```
hotspot/compiler/vectorapi, jdk/incubator/vector passed on SVE machine.
Refs:
// From Arm Neoverse N2 and V1 Software Optimization Guide
// NOTE: The data inside "()" belongs to V1
+--------------+---------+------------+--------------------+
| Instruction | Latency | Throughput | Utilized Pipelines |
+--------------+---------+------------+--------------------+
|WHILELE | 3| 1(1/2)| M(M0)|
+--------------+---------+------------+--------------------+
|LASTB(scalar) | 5(6)| 1| V1,M0|
+--------------+---------+------------+--------------------+
|EXT | 2| 2| V(V01)|
+--------------+---------+------------+--------------------+
|UMOV,SMOV | 2| 1| V|
+--------------+---------+------------+--------------------+
|ORR | 2| 2| V(V01)|
+--------------+---------+------------+--------------------+
|INS | 2| 2(4)| V|
+--------------+---------+------------+--------------------+
[1] https://developer.arm.com/documentation/pjdoc466751330-9685/latest/
[2] https://developer.arm.com/documentation/PJDOC-466751330-18256/0001
[3] https://github.com/openjdk/jdk/blob/master/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java#L2693
[4] https://www.felixcloutier.com/x86/pextrb:pextrd:pextrq
Change-Id: I90cfc1f8deb84145f42132d58d3b211c4a8933ad
…or 64/128-bit vector sizes
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, openjdk#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
Change-Id: Ic2a48f852011978d0f252db040371431a339d73c
* Rename all to smoketest. This patch changes JAVA_PATH to Conditional Variable Assignment, so we can define it using environment variable. We also refactor how to compile classes. we only recompile the class files when the java files have changed. This patch also brings back run_crazy_exception.sh. we drop it accidentally. * use JAVA_HOME instead of JDK_PATH. --------- Co-authored-by: Xin Liu <xxinliu@amazon.com>
* 7903536: jasm: the tool ignores options: -nowarn, -strict * Method getResourceString in the public void warning(int where, String id, Object... args) could get wrong result
Reviewed-by: mcimadamore
Contributed-by: Galder Zamarreno galder@redhat.com
Progress
Issue
Reviewers
Contributors
<galder@redhat.com>Download
$ git fetch https://git.openjdk.java.net/jdk pull/63/head:pull/63$ git checkout pull/63