[vector] RFC: Add AArch64 SVE 256-byte support for API fromArray with a mask

Paul Sandoz paul.sandoz at oracle.com
Thu Sep 3 16:39:20 UTC 2020


Hi Xiaohong,

Do you mind if we revisit this soon after integration of the API? (i.e. after the JEP has been marked as integrated?) 

Apologies if that delays things bit. To be honest I am struggling for time to focus on this right now, and my preference is to avoid any difficulties with merging so as the code is kept (beyond that required to merge) to that which was reviewed for integration.

Paul.

> On Aug 31, 2020, at 12:32 AM, Xiaohong Gong <Xiaohong.Gong at arm.com> wrote:
> 
> Add the original thread:
> https://mail.openjdk.java.net/pipermail/panama-dev/2020-February/007561.html
> 
> Thanks,
> Xiaohong Gong
> 
> From: Xiaohong Gong
> Sent: Monday, August 31, 2020 3:07 PM
> To: panama-dev at openjdk.java.net
> Cc: nd <nd at arm.com>
> Subject: RE: [vector] RFC: Add AArch64 SVE 256-byte support for API fromArray with a mask
> 
> Hi,
> 
> I just rebased this patch and made some fine tunings to the old version. The main idea
> is remaining unchanged.  One main difference from the old version is that the original
> byte vector "iotaMask[]" is changed to a byte mask vector in the updated patch. It can
> make it easier to restore the real lane numbers from "iotaMask[]".
> 
> The new webrev is: http://cr.openjdk.java.net/~xgong/vectorapi/vectorapi.fromarray/webrev.01/
> 
> Please help to take a look at this patch.  Any comments or better idea to address the
> 256-byte issue is very much appreciated!
> 
> Thanks,
> Xiaohong Gong
> 
>> Hi,
>> 
>> I'm adding AArch64 SVE 256-byte support for API fromArray with a
>> mask.
>> 
>> The issue of current implementation.
>> In Vector API Java implementations, byte[-128, 127] data type is
>> used to express the lane numbers of a ByteVector.
>> For AArch64 SVE, the maximum vector length is 256 bytes(2048/8)
>> which is out of the range of byte.
>> 
>> A test case for API ByteVector fromArray with a mask:
>> This API loads a vector from an array of type {@code byte[]}
>> starting at an offset and using a mask.
>> // Assume vector length is 256 bytes.
>> static final VectorSpecies<Byte> SPECIES = ByteVector.SPECIES_MAX;
>> int vl = SPECIES.length();  // 256
>> static final int LENGTH = 1024;
>> byte [] index = new byte[LENGTH];
>> boolean [] mask = new boolean[LENGTH];
>> 
>> for (int i = 0; i < LENGTH; i++) {
>> index[i] = (byte) i;
>> mask[i] = false;
>> }
>> 
>> for (int i = 0; i < 200; i++) {
>> mask[i] = true;
>> }
>> vmask = VectorMask.fromArray(SPECIES, mask, 0);
>> io = ByteVector.fromArray(SPECIES, index, 800, vmask);
>> System.out.println("io: " + io);
>> 
>> This test case fails. Error log is:
>> Caused by: java.lang.IllegalArgumentException: Vector creation
>> failed: value 255 cannot be represented in ETYPE byte; result of
>> cast is -1
>> at jdk.incubator.vector/jdk.incubator.vector.AbstractSpecies.badElementBits(AbstractSpecies.java:411)
>> at jdk.incubator.vector/jdk.incubator.vector.ByteVector$ByteSpecies.longToElementBits(ByteVector.java:3644)
>> at jdk.incubator.vector/jdk.incubator.vector.ByteVector$ByteSpecies.checkValue(ByteVector.java:3610)
>> at jdk.incubator.vector/jdk.incubator.vector.AbstractSpecies.iotaArray(AbstractSpecies.java:435)
>> at jdk.incubator.vector/jdk.incubator.vector.ByteMaxVector.<clinit>(ByteMaxVector.java:69)
>> ... 10 more
>> 
>> I have raised such concern before[1], and there are a lot of
>> discussions.
>> Based on these, I draft a patch that using two vectors to support
>> 256-byte vector. Could you please help to review it?
>> 
>> Webrev: http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.fromarray/webrev.00/index.html
>> 
>> In original version, byte array iota[] is used to store lane
>> numbers.
>> for (int i = 0; i < laneCount; i++) {
>> iota[i] = i;
>> }
>> In my version, byte array iota[] and iotaMask[] are used.
>> for (int i = 0; i < laneCount; i++) {
>> if (i < 128) {
>> iota[i] = i;
>> iotamask[i] = 0;
>> } else {
>> iota[i] = i - 128;
>> iotamask[i] = 1;
>> }
>> }
>> When lane numbers are needed, we need to restore real lane numbers
>> based on iota and iotaMask.
>> 
>> With this patch, byte vector with a mask can be loaded correctly.
>> correctly.
>> 
>> Regards
>> Yang
>> 
>> [1] https://mail.openjdk.java.net/pipermail/panama-dev/2019-November/006605.html



More information about the panama-dev mailing list