On Mon, 29 Mar 2021 03:15:57 GMT, Nick Gasson <ngas...@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
