Thanks for the new version. Unfortunately Minicloud seems to be down and therefore cannot test patch at the moment. I'll take look when I regain power64 access.

In D501#4558, @slandden wrote:

But I need it to shift H one to the left:
H1 = H << one;

Generally nice looking patch and great improvement for performance.

In T4906#133954, @JW wrote:

@jukivili,

I'd be interested in seeing the results of testing the patch. Can you provide a link to the results?

Attached patch should solve the issue for gcc 7.5 and clang 8.

Thanks for reporting this this. Your patch is correct.

Patch have been applied to master, https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=79ed620ec46adbb08f5cea6a4865a95a436e4109

Thanks for bug fix. I've prepared patch and send it to mailing list https://lists.gnupg.org/pipermail/gcrypt-devel/2020-January/004885.html. Let me know if Reported-by is ok/enough. I would have liked to put you as author of commit, but this Differential interface of quite horrible and does not give all the needed information (mainly "name <email>" format for git).

I've been wondering this also. I can start working on this.

Please note that C-based intrinsic implementation is the way to go now as that is the path chosen for PowerPC implementations in libgcrypt.

Poly1305 addition helper for ppc64 posted on mailing list: https://lists.gnupg.org/pipermail/gcrypt-devel/2019-September/004804.html

PowerPC SHA-256 and SHA-512 implementations with little bit more tuning committed. Most notably, SHA-512 on POWER8 now gives similar performance to OpenSSL:

Patches send to mailing list:
https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004800.html
https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004799.html

I'll start working on PowerPC GHASH implementation in September after SHA2 is done.

I'll start working on new PowerPC SHA2 implementations for libgcrypt in coming weeks.

Patches for PowerPC AES acceleration sent to mailing-list, based partly on initial work by Shawn Landden (@slandden): https://lists.gnupg.org/pipermail/gcrypt-devel/2019-August/004788.html

In D494#4450, @slandden wrote:

I will leave these in the main file, as they might benefit from "static", and I do not want to rely on LTO for that.

Thanks. I really like this Altivec intrinsic approach. I might reimplement rest of the bulk block cipher functions this way later (if I ever get PPC HW access).