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

[CoreyAshford]

On Thu, 22 Oct 2020 14:32:40 GMT, Paul Murphy <github.com+12972156+pmur at openjdk.org> wrote:

>> CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   TestBase64.java: remove jdk.test.lib.Utils from @build which was causing Tier3 failures.
>
> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3884:
> 
>> 3882:             // |   vec_0x3fs   |  00111111   |       00111111       |       00111111       |  00111111   |  00111111   |       00111111       |       00111111       |  00111111   |
>> 3883:             // +---------------+-------------+----------------------+----------------------+-------------+-------------+----------------------+----------------------+-------------+
>> 3884:             // | after vpextd  |   b5:0..7   |       b4:0..7        |       b3:0..7        |   b2:0..7   |   b1:0..7   |       b0:0..7        |       00000000       |  00000000   |
> 
> Are theses comments correct or am I misunderstanding this? I read the final result as something starting as `b5:2..7 || b4:4..7|| b5:0..1` from vpextd.

Because the bytes are displayed e15..e8, instead of the other way around, it's hard to follow.  As an example, consider just the last four bytes of the table, but displayed in the reverse order:

00||b0:0..5    00||b0:6..7||b1:0..3    00||b1:4..7||b2:0..1    00||b2:2..7

After vpextd with bit select pattern 00111111 for all bytes:

b0:0..5||b0:6..7    b1:0..3||1:4..7    b2:0..1||b2:2..7
=
b0:0..7    b1:0..7    b2:0..7

Should I reverse the order of this table with a comment at the top, to explain the reason for the reversal?  It seems like a good idea.

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

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