@gcwilson Can you notify the performance team of this new patch?

It turns out that Openssl's main loop of single-block mode was not optimized.

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).

Here's generic review comments for full series:

• I think cryptogam files should be placed in to separate sub-directory, lets say 'crypto/cryptogams'. This would give clearer separation from other assembly files and ones generated from cryptogams perl.
• Generated assembly files should have short header comment that they are (auto)generated from the perl files.
• With new OCB code, PowerPC part in rijndael.c has grown large and this platform specific code (altivec.h implementation and cryptogam wrapper functions) needs to be split to new source file, 'rijndael-ppc.c'.
• Does all PPC compiler versions have 'altivec.h' available? Should additional header file check be added to configure.ac for checking if altivec.h exists or not?
• For C files, libgcrypt follows GNU coding standards for coding style:
  • https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=doc/HACKING#l74
  • https://www.gnu.org/prep/standards/html_node/Writing-C.html#Writing-C
• Please add ChangeLog entries for each patch:
  • https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=doc/HACKING#l19
  • https://www.gnu.org/prep/standards/html_node/Change-Logs.html
• Please send your DCO to libgcrypt mailing-list:
  • https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=doc/HACKING#l31

I find Phabricator differential interface is quite horrible to use. I have not been able to fetch these patch cleanly and need to manually edit the diff files to fix importing to git. It's probably better if you send patches to the mailing-list, or leave git pull location at parent task T4531.

and cryptogam wrapper functions

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.

(if I ever get PPC HW access).

https://minicloud.parqtec.unicamp.br/

click "request access". It is *free*.

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.

Ok. There is need for some clean-up work in rijndael.c and I'll do this change as part of that. Bulk functions are mainly called through 'hd->bulk.<mode>_enc/dec' indirect function calls and 'ctx->use_<hwf>' code paths in '_gcry_aes_<mode>_enc/dec' functions are only really used by 'selftest_<mode>_128' functions at the end of rijndael.c. So I'm planning of removing those code paths from '_gcry_aes_<mode>_enc/dec' functions and handle HW feature detection and picking correct bulk function in each of those selftest functions (... split hw feature detection from setkey to new function that can also be used by selftest functions).

I find Phabricator differential interface is quite horrible to use.

Me too.

I find autotools to be EXTREMELY difficult to use. I tried to put rijndael.c stuff in its own file

(and it needs these CFLAGS -mabi=altivec -maltivec -mvsx -mpower8-vector )
but every time I try I get cryptic error messages from autotools/libtool that I don't understand,
and learning autotools just seems like a pointless thing to do.

autotools is so automatic that you NEVER know what is going.

Managed to get the build correct. (patches in 1 sec)

Putting the cryptogams stuff in its own folder requires some autotools wizardry,
as the straight-forward method I tried requires enabling a feature "subdir-objects" that
other parts of the libgcrypt code base say caused problems.