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

[CoreyAshford]

On Tue, 13 Oct 2020 19:56:42 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Hi Corey, thanks for taking some stuff out of the “too short” path. There may be a performance regression when decoding
> many short arrays because of the stub call overhead and the usage of the slower part of the Java implementation. We
> could do it a little better in many cases to compute the maximum possible iteration count i: i = (sl - sp) / block_size
> if (i * block_size > sl - 12) i-- if (i <= 0) return 0 What do you think?

Are you thinking of a case where that produces a higher iteration count?  It looks effectively the same to me.

> I don’t think branch prediction hints are helpful for the “too short” check.

My thinking is that most of the time when the intrinsic is called, it will not take the early exit, but I suppose when
it is processing a sub-block_size buffer, it will return early every time.  I will remove the hints.

> And we should better use CCR1 instead of CCR2 which is specified as non-volatile.

Ah, I should have checked the calling conventions.  I thought all of the CR* regs are volatile.  I will fix that.

>  Did you already find a 2nd reviewer for the PPC64 part?

Your original comment said "2nd review", so I thought you meant you need to review it again after the changes.  So, no,
I haven't looked for or found a second reviewer.  Any suggestions?  The folks on the team here have been busy with
other work.

Btw, I'm off today, so I will push commits to the above-mentioned issues tomorrow.

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

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