RC4_CHAR is a bit in the x86(-64) CPUID information that switches the
RC4 asm code from using an array of 256 uint32_t's to 256 uint8_t's. It
was originally written for the P4, where the uint8_t style was faster.
(On modern chips, setting RC4_CHAR took RC4-MD5 from 458 to 304 MB/s.
Although I wonder whether, on a server with many connections, using less
cache wouldn't be better.)
However, I'm not too worried about a slowdown of RC4 on P4 systems these
days (the last new P4 chip was released nine years ago) and I want the
code to be simplier.
Also, RC4_CHAR was set when the CPUID family was 15, but Intel actually
lists 15 as a special code meaning "also check the extended family
bits", which the asm didn't do.
The RC4_CHAR support remains in the RC4 asm code to avoid drift with
upstream.
Change-Id: If3febc925a83a76f453b9e9f8de5ee43759927c6
Reviewed-on: https://boringssl-review.googlesource.com/3550
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Compilers have a bad habit of removing "superfluous" memset calls that
are trying to zero memory. For example, when memset()ing a buffer and
then free()ing it, the compiler might decide that the memset is
unobservable and thus can be removed.
Previously we tried to stop this by a) implementing memset in assembly
on x86 and b) putting the function in its own file for other platforms.
This change removes those tricks in favour of using asm directives to
scare the compiler away. As best as our compiler folks can tell, this is
sufficient and will continue to be so.
Change-Id: I40e0a62c3043038bafd8c63a91814a75a3c59269
Reviewed-on: https://boringssl-review.googlesource.com/1339
Reviewed-by: David Benjamin <davidben@chromium.org>
Reviewed-by: Adam Langley <agl@google.com>
Initial fork from f2d678e6e89b6508147086610e985d4e8416e867 (1.0.2 beta).
(This change contains substantial changes from the original and
effectively starts a new history.)
