Roll BoringSSL.

third_party/boringssl/win-x86_64/crypto/rc4/rc4-x86_64.asm

Index: third_party/boringssl/win-x86_64/crypto/rc4/rc4-x86_64.asm
diff --git a/third_party/boringssl/win-x86_64/crypto/rc4/rc4-x86_64.asm b/third_party/boringssl/win-x86_64/crypto/rc4/rc4-x86_64.asm
index e9335712cb7059b6a30f961866a7ac2413e06177..c183caca47d74fdd003267b071bca53a0802e899 100644
--- a/third_party/boringssl/win-x86_64/crypto/rc4/rc4-x86_64.asm
+++ b/third_party/boringssl/win-x86_64/crypto/rc4/rc4-x86_64.asm
@@ -37,8 +37,7 @@ $L$prologue::
 	mov	cl,BYTE PTR[((-4))+rdi]
 	cmp	DWORD PTR[256+rdi],-1
 	je	$L$RC4_CHAR
-	lea	r8,QWORD PTR[OPENSSL_ia32cap_P]
-	mov	r8d,DWORD PTR[r8]
+	mov	r8d,DWORD PTR[OPENSSL_ia32cap_P]

[agl, 2014/10/01 19:35:10]

This is obviously not a no-op change on Windows. It's unclear which is correct.
(It probably doesn't matter for now.)

[davidben, 2014/10/01 19:43:50]

Hrm. I'm guessing this is a result the GOTPCREL change. I'm not familiar with
masm syntax... does QWORD PTR vs DWORD PTR change the value of the address? At a
glance it seems equivalent. Load the address of QWORD PTR[OPENSSL_ia32cap_P]
into r8 then read a DWORD from r8 vs. read a DWORD from DWORD
PTR[OPENSSL_ia32cap_P].

I'll build with Win64 later and make sure all the CPUID bits are still doing
something.

[agl, 2014/10/01 20:17:37]

Yes, this is a result of the GOT change.

Actually, I'm much less worried about this now because I didn't notice that the
first instruction is an lea, not a mov.

 	xor	rbx,rbx
 	inc	r10b
 	sub	rbx,r10
@@ -557,8 +556,7 @@ $L$SEH_begin_asm_RC4_set_key::
 	xor	r10,r10
 	xor	r11,r11
 
-	lea	r8,QWORD PTR[OPENSSL_ia32cap_P]
-	mov	r8d,DWORD PTR[r8]
+	mov	r8d,DWORD PTR[OPENSSL_ia32cap_P]
 	bt	r8d,20
 	jc	$L$c1stloop
 	jmp	$L$w1stloop