Reland "Integrate SIMD optimisations for zlib"

Reland "Integrate SIMD optimisations for zlib"

This reland adds an MSan suppression entry to work around gaps in MSan's
support for some of the intrinsics this patch uses. This version also inlines
the insert_string_sse function as it uses inline assembly and therefore does
not need to be in the static library.

Original CL: https://codereview.chromium.org/552123005

These optimisations have been published on zlib mailing list and at
https://github.com/jtkukunas/zlib/

This change merges the following optimisation patches:
- "For x86, add CPUID check."
- "Adds SSE2 optimized hash shifting to fill_window."
- "add SSE4.2 optimized hash function"
- "add PCLMULQDQ optimized CRC folding"

From Jim Kukunas <james.t.kukunas@linux.intel.com>; and adapts them to the
current zlib version in Chromium.

The optimisations are enabled at runtime if all the necessary CPU features are
present. As the optimisations require extra cflags to enable the compiler to
use the instructions the optimisations are held in their own static library
with a stub implementation to allow linking on other platforms.

TEST=net_unittests(GZipUnitTest) passes, Chrome functions and performance
improvement seen on RoboHornet benchmark on Linux Desktop
BUG=401517
Committed: https://crrev.com/a5022d5eab6f77889aceed6ab0ccaf44a657ffc4
Cr-Commit-Position: refs/heads/master@{#301162}

[robert.bradford, 2014-10-24 15:11:27]

Patchset #2 (id:20001) has been deleted

[robert.bradford, 2014-10-24 16:18:45]

robert.bradford@intel.com changed reviewers:
+ agl@chromium.org, hans@chromium.org

[robert.bradford, 2014-10-24 16:18:46]

Hi Adam,

Apologies for the noise around the revert but when I saw the builder go red I
though it best to revert and investigate in detail. To me it looks like MSan is
tripping over the 3 operand intrinsic, http://crbug.com/426868 filed. A
blacklist entry is included in the delta relative to the original CL.

This CL also has two other differences, a fix to address an issue highlighted by
ASan where we were always loading 16 bytes at a time in crc_fold_copy() even if
there were fewer than that bytes remaining. 

The second difference was the inlining of insert_string_sse(), something that I
got wrong when moving functions to the static library (highlighted by hans's
question). This function uses inline assembly so can included in deflate.c
without requiring extra cflags with gcc/clang. It should also allow build on
Windows/clang.

[hans, 2014-10-24 17:28:15]

https://codereview.chromium.org/677713002/diff/40001/third_party/zlib/deflate.c
File third_party/zlib/deflate.c (right):

https://codereview.chromium.org/677713002/diff/40001/third_party/zlib/deflate...
third_party/zlib/deflate.c:2103: #if defined(_MSC_VER) && !defined(__clang__)
Thanks, this should fix the Win-Clang issue I was seeing.

I was wondering why we couldn't use the intrinsic on GCC and Clang instead of
the inline assembly, and now I see that the intrinsic is only available when
compiling with -msse4.2, which we can't use, so the inline asm seems necessary.

[agl, 2014-10-24 17:47:16]

https://codereview.chromium.org/677713002/diff/40001/third_party/zlib/deflate.c
File third_party/zlib/deflate.c (right):

https://codereview.chromium.org/677713002/diff/40001/third_party/zlib/deflate...
third_party/zlib/deflate.c:2112: /* This should never happen */
This is a static error, so can #error be used?

[robert.bradford, 2014-10-24 18:39:02]

On 2014/10/24 17:47:16, agl wrote:
>
https://codereview.chromium.org/677713002/diff/40001/third_party/zlib/deflate.c
> File third_party/zlib/deflate.c (right):
> 
>
https://codereview.chromium.org/677713002/diff/40001/third_party/zlib/deflate...
> third_party/zlib/deflate.c:2112: /* This should never happen */
> This is a static error, so can #error be used?

Thanks for looking. Unfortunately it's not a static error, as that function does
get built on all platforms, e.g ARM but it should never be called because the
caller checks the global variable x86_cpu_enable_simd before calling
insert_string_sse. This way was preferable to surrounding the whole function and
it's call site with per-arch #ifdefs.

[agl, 2014-10-24 18:47:22]

On 2014/10/24 18:39:02, robert.bradford wrote:
> Thanks for looking. Unfortunately it's not a static error, as that function
does
> get built on all platforms, e.g ARM but it should never be called because the
> caller checks the global variable x86_cpu_enable_simd before calling
> insert_string_sse. This way was preferable to surrounding the whole function
and
> it's call site with per-arch #ifdefs.

Oh I see, it's in deflate.c. Fair enough.

[agl, 2014-10-24 18:47:27]

The CQ bit was checked by agl@chromium.org

[agl, 2014-10-24 18:47:28]

lgtm

[commit-bot: I haz the power, 2014-10-24 18:49:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/677713002/40001

[commit-bot: I haz the power, 2014-10-24 19:08:11]

Committed patchset #2 (id:40001)

[commit-bot: I haz the power, 2014-10-24 19:09:03]

Patchset 2 (id:??) landed as
https://crrev.com/a5022d5eab6f77889aceed6ab0ccaf44a657ffc4
Cr-Commit-Position: refs/heads/master@{#301162}

[qyearsley, 2014-10-24 23:04:14]

A revert of this CL (patchset #2 id:40001) has been created in
https://codereview.chromium.org/665203006/ by qyearsley@chromium.org.

The reason for reverting is: Speculatively reverting because XP Tests (1) is
having failures.

https://build.chromium.org/p/chromium.win/builders/XP%20Tests%20(1).