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

[CoreyAshford]

On Wed, 14 Oct 2020 10:29:40 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Hi Corey,
> Are you thinking of a case where that produces a higher iteration count?
> Sorry for the confusion. This is also fine: length = sl - sp - 12 i = length / block_size if (i <= 0) return 0 But I
> still wonder why we should use 2 branches. Why not srawi_ ble(CCR0, return_zero) ?

You're right!  I originally thought that the `srawi.` was setting only the Zero bit, but it sets others as well.

> Ah, I should have checked the calling conventions. I thought all of the CR* regs are volatile. I will fix that.
> Actually, we do save and restore all CRs, so it’s not a real problem with the current implementation. But I prefer
> staying closer to the elf ABI as long as there’s no good reason to do it differently.

Looks like I don't need that code at all now, but it's good to know for the future; I have an encode intrinsic in the
works.

> Your original comment said "2nd review", so I thought you meant you need to review it again after the changes.
> We usually require at least 2 reviews by different people for all non-trivial changes. And I don’t consider the PPC64
> part as trivial. In addition to that, I’m not familiar with Power 10.

I received permission to request help from the GNU toolchain team here to review it.  Due to family issues and work
schedule on my end, it will be at least the middle of next week before I can get a reviewer to have a look.

Thanks for your continued patience and help.

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

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