RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
Dong Bo
dongbo at openjdk.java.net
Mon Mar 29 03:54:26 UTC 2021
On Mon, 29 Mar 2021 03:15:57 GMT, Nick Gasson <ngasson at openjdk.org> wrote:
>> Firstly, I wonder how important this is for most applications. I don't actually know, but let's put that to one side.
>>
>> There's a lot of unrolling, particularly in the non-SIMD case. Please consider taking out some of the unrolling; I suspect it'd not increase time by very much but would greatly reduce the code cache pollution. It's very tempting to unroll everything to make a benchmark run quickly, but we have to take a balanced approach.
>
>>
>> There's a lot of unrolling, particularly in the non-SIMD case. Please consider taking out some of the unrolling; I suspect it'd not increase time by very much but would greatly reduce the code cache pollution. It's very tempting to unroll everything to make a benchmark run quickly, but we have to take a balanced approach.
>
> But there's only ever one of these generated at startup, right? It's not like the string intrinsics that are expanded at every call site.
@nick-arm Thank you for watching this.
> That probably ought to go around the whole routine in generate_base64_decodeBlock rather than here?
>
There are two non-simd blocks in this intrinsic.
The 1st is at the begining, mainly to roll MIME decoding to non-simd processing due to the performance issue as I claimed before.
The 2nd is at the end to handle trailing inputs. So I guess we need generate_base64_decode_nosimdround here.
> "illegal inputs". Are there existing jtreg tests that cover these cases?
>
Yes, they are covered by `test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java`.
> This table and the one below seem to be identical to first half of the NoSIMD tables. Can't you just use one set of 256-entry tables for both SIMD and non-SIMD algorithms?
>
They are not identical, `*ForSIMD[64]==0`, `*forNoSIMD[64]=255`.
In SIMD case, `*ForSIMD[64]` acts as a pivot to tell us that we already get the decoded data with the 1st lookup when performing the 2nd lookup.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3228
More information about the core-libs-dev
mailing list