RFR: 8340079: Modify rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes
Paul Sandoz
psandoz at openjdk.org
Thu Sep 12 23:17:13 UTC 2024
On Mon, 19 Aug 2024 21:47:23 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:
> Currently the rearrange and selectFrom APIs check shuffle indices and throw IndexOutOfBoundsException if there is any exceptional source index in the shuffle. This causes the generated code to be less optimal. This PR modifies the rearrange/selectFrom Vector API methods to perform wrapIndexes instead of checkIndexes and performs optimizations to generate efficient code.
>
> Summary of changes is as follows:
> 1) The rearrange/selectFrom methods do wrapIndexes instead of checkIndexes.
> 2) Intrinsic for wrapIndexes and selectFrom to generate efficient code
>
> For the following source:
>
>
> public void test() {
> var index = ByteVector.fromArray(bspecies128, shuffles[1], 0);
> for (int j = 0; j < bspecies128.loopBound(size); j += bspecies128.length()) {
> var inpvect = ByteVector.fromArray(bspecies128, byteinp, j);
> index.selectFrom(inpvect).intoArray(byteres, j);
> }
> }
>
>
> The code generated for inner main now looks as follows:
> ;; B24: # out( B24 B25 ) <- in( B23 B24 ) Loop( B24-B24 inner main of N173 strip mined) Freq: 4160.96
> 0x00007f40d02274d0: movslq %ebx,%r13
> 0x00007f40d02274d3: vmovdqu 0x10(%rsi,%r13,1),%xmm1
> 0x00007f40d02274da: vpshufb %xmm2,%xmm1,%xmm1
> 0x00007f40d02274df: vmovdqu %xmm1,0x10(%rax,%r13,1)
> 0x00007f40d02274e6: vmovdqu 0x20(%rsi,%r13,1),%xmm1
> 0x00007f40d02274ed: vpshufb %xmm2,%xmm1,%xmm1
> 0x00007f40d02274f2: vmovdqu %xmm1,0x20(%rax,%r13,1)
> 0x00007f40d02274f9: vmovdqu 0x30(%rsi,%r13,1),%xmm1
> 0x00007f40d0227500: vpshufb %xmm2,%xmm1,%xmm1
> 0x00007f40d0227505: vmovdqu %xmm1,0x30(%rax,%r13,1)
> 0x00007f40d022750c: vmovdqu 0x40(%rsi,%r13,1),%xmm1
> 0x00007f40d0227513: vpshufb %xmm2,%xmm1,%xmm1
> 0x00007f40d0227518: vmovdqu %xmm1,0x40(%rax,%r13,1)
> 0x00007f40d022751f: add $0x40,%ebx
> 0x00007f40d0227522: cmp %r8d,%ebx
> 0x00007f40d0227525: jl 0x00007f40d02274d0
>
> Best Regards,
> Sandhya
API shapes are good!
I see you intrinsified `selectFrom` which, IIUC, optimally generates C2 nodes that are functionally equivalent to the Java expression `v.rearrange(this.toShuffle())`. That way we can better generate an optimal set of instructions?
Do you know what deficiencies there that blocks us from compiling the expression down to the same set of instructions as the intrinsic? Not suggesting we do that here, just for future reference.
Adding link to UTF-8 decoding use case for convenience and reminder: https://github.com/AugustNagro/utf8.java/blob/master/src/main/java/com/augustnagro/utf8/Utf8.java.
I think this is good enough to promote out of draft and create a CSR for the API changes.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2305377165
PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2305412450
PR Comment: https://git.openjdk.org/jdk/pull/20634#issuecomment-2346848993
More information about the hotspot-dev
mailing list