RFR: 8306136: [vectorapi] Intrinsics of VectorMask.laneIsSet()

[Eric Liu]

On Mon, 29 May 2023 11:53:03 GMT, Eric Liu <eliu at openjdk.org> wrote:

> VectorMask.laneIsSet() [1] is implemented based on VectorMask.toLong() [2], and it's performance highly depends on the intrinsification of toLong(). However, if `toLong()` is failed to intrinsify, on some architectures or unsupported species, it's much more expensive than pure getBits(). Besides, some CPUs (e.g. with Arm Neon) may not have efficient instructions to implementation toLong(), so we propose to intrinsify VectorMask.laneIsSet separately.
> 
> This patch optimize laneIsSet() by calling the existing intrinsic method VectorSupport.extract(), which actually does not introduce new intrinsic method. The C2 compiler intrinsification logic to support _VectorExtract has also been extended to better support laneIsSet(). It tries to extract the mask's lane value with an ExtractUB node if the hardware backend supports it. While on hardware without ExtractUB backend support , c2 will still try to generate toLong() related nodes, which behaves the same as before the patch.
> 
> Key changes in this patch:
> 
> 1. Reuse intrinsic `VectorSupport.extract()` in Java side. No new intrinsic method is introduced.
> 2. In compiler, `ExtractUBNode` is generated if backend support is. If not, the original "toLong" pattern is generated if it's implemented. Otherwise, it uses the default Java `getBits[i]` rather than the expensive and complicated toLong() based implementation.
> 3. Enable `ExtractUBNode` on AArch64 to extract the lane value for a vector mask in compiler, together with changing its bottom type to TypeInt::BOOL. This helps optimize the conditional selection generated by
> 
>    ```
> 
>        public boolean laneIsSet(int i) {
>            return VectorSupport.extract(..., defaultImpl) == 1L;
>        }
> 
>    ```
> 
> [Test]
> hotspot:compiler/vectorapi and jdk/incubator/vector passed.
> 
> [Performance]
> 
> Below shows the performance gain on 128-bit vector size Neon machine. For 64 and 128 SPECIES, the improvment caused by this intrinsics. For other SPECIES which can not be intrinfied, performance gain comes from the default Java implementation changes, i.e. getBits[i] vs. toLong().
> 
> 
> Benchmark                               Gain (after/before)
> microMaskLaneIsSetByte128_con           2.47
> microMaskLaneIsSetByte128_var           1.82
> microMaskLaneIsSetByte256_con           3.01
> microMaskLaneIsSetByte256_var           3.04
> microMaskLaneIsSetByte512_con           4.83
> microMaskLaneIsSetByte512_var           4.86
> microMaskLaneIsSetByte64_con            1.57
> microMaskL...

Compared with Vector.lane(), this patch does not use the switch-stmt for
VectorMask.laneIsSet() to transform variable index to constant, e.g.,


    public byte lane(int i) {
        switch(i) {
            case 0: return laneHelper(0);
            case 1: return laneHelper(1);
            case 2: return laneHelper(2);
            case 3: return laneHelper(3);
            case 4: return laneHelper(4);
            case 5: return laneHelper(5);
            case 6: return laneHelper(6);
            case 7: return laneHelper(7);
            case 8: return laneHelper(8);
            case 9: return laneHelper(9);
            case 10: return laneHelper(10);
            case 11: return laneHelper(11);
            case 12: return laneHelper(12);
            case 13: return laneHelper(13);
                 ...
                 ...
            default: throw new IllegalArgumentException("Index " + i + " must be zero or positive, and less than " + VLENGTH);
        }
    }



The switch-stmt ensures the constant position for ExtractNode, which
may be friendly for most architectures to generate efficient code. E.g.,
on AArch64, single instruction `umov` can extract scalar element from
vector for constant position. Nevertheless, it has some defects:

1. The switch-stmt is NOT cost free.
2. The switch-stmt maybe too huge to be inlined to callee. Thus it can
   hurt the performance.
3. It can NOT work for max species.

Besides, even if the index is not a constant, we can still intrinsify
the code to use `TBL` insn. Hence in my implementation, I've relax the
intrinsification condition to accept non-constant index.

Finally, to avoid performance regression on x86, this patch abandoned
this approach, generated backend rules for ExtractUB accepting both
immeidiate and register.

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

PR Comment: https://git.openjdk.org/jdk/pull/14200#issuecomment-1567043986