| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
[skip ci]
Reviewed-by: Tim Hudson <tjh@openssl.org>
|
| |
|
|
|
|
|
|
|
| |
Around 138 distinct errors found and fixed; thanks!
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3459)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Extend the s390x capability vector to store the longer facility list
available from z13 onwards. The bits indicating the vector extensions
are set to zero, if the kernel does not enable the vector facility.
Also add capability bits returned by the crypto instructions' query
functions.
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Tim Hudson <tjh@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4542)
|
| |
|
|
|
|
|
|
|
| |
Since return is inconsistent, I removed unnecessary parentheses and
unified them.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4541)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An instruction's QUERY function is executed at initialization, iff the required
MSA level is installed. Therefore, it is sufficient to check the bits returned
by the QUERY functions. The MSA level does not have to be checked at every
function call.
crypto/aes/asm/aes-s390x.pl: The AES key schedule must be computed if the
required KM or KMC function codes are not available. Formally, the availability
of a KMC function code does not imply the availability of the corresponding KM
function code.
Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4501)
|
| |
|
|
|
|
|
|
|
|
| |
Names were not removed.
Some comments were updated.
Replace Andy's address with openssl.org
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Paul Dale <paul.dale@oracle.com>
(Merged from https://github.com/openssl/openssl/pull/4516)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... script data load.
On related note an attempt was made to merge rotations with logical
operations. I mean as we know, ARM ISA has merged rotate-n-logical
instructions which can be used here. And they were used to improve
keccak1600-armv4 performance. But not here. Even though this approach
resulted in improvement on Cortex-A53 proportional to reduction of
amount of instructions, ~8%, it didn't exactly worked out on
non-Cortex cores. Presumably because they break merged instructions
to separate μ-ops, which results in higher *operations* count. X-Gene
and Denver went ~20% slower and Apple A7 - 40%. The optimization was
therefore dismissed.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
|
|
|
| |
VisualStudio 6 and earlier aren't supported.
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4263)
|
| |
|
|
|
|
|
| |
Reduce per-round instruction count in Thumb-2 case by 16%. This is
achieved by folding ldr/str pairs to their double-word counterparts.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
| |
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is achieved mostly by ~10% reduction of amount of instructions
per round thanks to a) switch to KECCAK_2X variant; b) merge of
almost 1/2 rotations with logical instructions. Performance is
improved on all observed processors except on Cortex-A15. This is
because it's capable of exploiting more parallelism and can execute
original code for same amount of time.
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/4057)
|
| |
|
|
|
|
|
| |
"More" refers to the fact that we make active BIT_INTERLEAVE choice
in some specific cases. Update commentary correspondingly.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
|
|
| |
Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4056)
|
| |
|
|
|
|
| |
Reviewed-by: Paul Dale <paul.dale@oracle.com>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3943)
|
| |
|
|
|
|
|
|
|
|
|
| |
Improvement is result of combination of data layout ideas from
Keccak Code Package and initial version of this module.
Hardware used for benchmarking courtesy of Atos, experiments run by
Romain Dolbeau <romain.dolbeau@atos.net>. Kudos!
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
|
|
|
| |
Hardware used for benchmarking courtesy of Atos, experiments run by
Romain Dolbeau <romain.dolbeau@atos.net>. Kudos!
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Optimize" is in quotes because it's rather a "salvage operation"
for now. Idea is to identify processor capability flags that
drive Knights Landing to suboptimial code paths and mask them.
Two flags were identified, XSAVE and ADCX/ADOX. Former affects
choice of AES-NI code path specific for Silvermont (Knights Landing
is of Silvermont "ancestry"). And 64-bit ADCX/ADOX instructions are
effectively mishandled at decode time. In both cases we are looking
at ~2x improvement.
AVX-512 results cover even Skylake-X :-)
Hardware used for benchmarking courtesy of Atos, experiments run by
Romain Dolbeau <romain.dolbeau@atos.net>. Kudos!
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
|
|
|
|
|
| |
New register usage pattern allows to achieve sligtly better
performance. Not as much as I hoped for. Performance is believed
to be limited by irreconcilable write-back conflicts, rather than
lack of computational resources or data dependencies.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
|
|
|
|
|
| |
This gives much more freedom to rearrange instructions. This is
unoptimized version, provided for reference. Basically you need
to compare it to initial 29724d0e15b4934abdf2d7ab71957b05d1a28256
to figure out the key difference.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
| |
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
| |
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
|
|
| |
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/3861)
|
| |
|
|
| |
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
|
| |
|
|
|
|
| |
[Also typo and readability fixes. Ryzen result is added.]
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
|
| |
|
|
| |
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
|
| |
|
|
| |
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
|
| |
|
|
| |
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
| |
|
|
| |
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
| |
|
|
| |
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
| |
|
|
| |
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
| |
|
|
| |
Reviewed-by: Richard Levitte <levitte@openssl.org>
|
| |
|
|
|
|
|
|
|
|
|
| |
Curiously enough out-of-order Silvermont benefited most from
optimization, 33%. [Originally mentioned "anomaly" turned to be
misreported frequency scaling problem. Correct results were
collected under older kernel.]
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/3739)
|
| |
|
|
|
|
| |
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/3739)
|
| |
|
|
|
|
|
|
| |
[skip ci]
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3705)
|
| |
|
|
|
|
|
|
| |
[skip ci]
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3705)
|
| |
|
|
|
|
|
| |
[skip ci]
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
(Merged from https://github.com/openssl/openssl/pull/3708)
|
| |
|
|
| |
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
|
|
| |
algorithm.
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
|
|
| |
[Also bypass sizeof(void *) == 8 check on some platforms.]
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
| |
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
| |
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
| |
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
| |
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
| |
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
| |
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
| |
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
| |
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
|
|
|
|
| |
...as discussed in section 2.2 of "Keccak implementation overview".
[skip ci]
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
|
|
|
| |
This targets 32-bit processors and is discussed in section 2.1 of
"Keccak implementation overview".
Reviewed-by: Rich Salz <rsalz@openssl.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The assembler already knows the actual path to the generated file and,
in other perlasm architectures, is left to manage debug symbols itself.
Notably, in OpenSSL 1.1.x's new build system, which allows a separate
build directory, converting .pl to .s as the scripts currently do result
in the wrong paths.
This also avoids inconsistencies from some of the files using $0 and
some passing in the filename.
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3431)
|
