RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding [v3]

[CoreyAshford]

On Thu, 8 Oct 2020 10:41:32 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> CoreyAshford has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - stubGenerator_ppc.cpp: Fix multiple issues as per Martin Doerr's v2 review
>>    
>>     * Remove extraneous comma from SAP copyright notice
>>     * Move align(32) to the head of the loop rather than the beginning of the unwound code
>>     * Simplified looping condition to use a loop counter instead of a final
>>       address.  This eliminated the need for the "end" variable, and
>>       essentially replaced it with CTR, which is computed using a simple
>>       bitwise shift of the size.
>>     * Re-ran benchmarks against loop_unrolls values: 1, 2, 4, 8, 16 to find
>>       optimal value, now 4.
>>     * Corrected a typo in the word "elements"
>>  - vm_version_ppc.cpp: per Martin Doerr's review of v2: fix copy/paste error
>>  - vmIntrinsics.cpp: Per Martin Doerr's v2 review: rearrange order of case statement to be consistent with others.
>>  - runtime.cpp: per Martin Doerr's review of v2, correct comment as per current semantics of decodeBlock()
>>    
>>      * The reference to "ofs" seems to be a copy/paste error.
>>      * -1 is no longer returned from decodeBlock() in the event of a
>>        non-base64 character being encountered; only a count of bytes written
>>        to dst.
>>  - TestBase64.java: Change comment as per Martin Doerr's v2 review
>>  - Base64.java: Make changes as per Roger Riggs and Martin Doerr's v2 Review
>>    
>>      * Make comment about the sl parameter more precise
>>      * Fix comparison to avoid possible integer overflow of sp
>>  - library_call.cpp: Fix rebase merge error
>
> test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 90:
> 
>> 88:
>> 89:         // This should be enough to get both encodeBlock() and
>> 90:         // decodeBlock() compiled on the highest tier.
> 
> It's actually encode() and decode() which should get compiled. You should see them when testing
> with -XX:+PrintCompilation. And you should see usage of the intrinsics by -XX:+PrintInlining.

Ah, useful tips!  Thanks!

I will make this comment change.

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

PR: https://git.openjdk.java.net/jdk/pull/293