Revert of update memset16/32 inlining heuristics (patchset #1 id:1 of https://coderev...

Reason for revert:
Who wants to land forever?

Original issue's description:
> update memset16/32 inlining heuristics
>
> I spent some time looking at perf.skia.org and it looks like we can do better.
>
> It is weird, weird, weird that on x86, we see three completely different behaviors:
>   - x86 Android: inlining better for small N, custom better for large N;
>   - Windows:     inlining better for large N, custom better for small N;
>   - other x86:   inlining generally better
>
> BUG=skia:4316,chromium:516426
>
> (Temporary, plan to revert.)
> TBR=reed@google.com
>
> Committed: https://skia.googlesource.com/skia/+/b68fa409fc00ce2f38e2a0fd6f9dc2379b372481

TBR=reed@google.com,jcgregorio@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:4316,chromium:516426

Review URL: https://codereview.chromium.org/1358793002

diff --git a/include/core/SkUtils.h b/include/core/SkUtils.h
index 7dcc4d1..4e24bd0 100644 (file)
--- a/include/core/SkUtils.h
+++ b/include/core/SkUtils.h
@@ -17,11 +17,13 @@ namespace SkOpts {
 
 ///////////////////////////////////////////////////////////////////////////////
 
-// Inlining heuristics were determined by using perf.skia.org and bench/MemsetBench.cpp.
-// When using MSVC, inline is better >= 1K and worse <= 100.  The Nexus Player was the opposite.
-// Otherwise, when NEON or SSE is available to GCC or Clang, they can handle it best.
-// See https://code.google.com/p/chromium/issues/detail?id=516426#c15 for more details.
-// See also skia:4316; it might be a good idea to use rep stosw/stosd here.
+// The inlining heuristics below were determined using bench/MemsetBench.cpp
+// on a x86 desktop, a Nexus 7 with and without NEON, and a Nexus 9:
+//   - on x86, inlining was never faster,
+//   - on ARMv7, inlining was faster for N<=10.  Putting this check inside the NEON
+//     code was not helpful; it's got to be here outside.
+//   - NEON code generation for ARMv8 with GCC 4.9 is terrible,
+//     making the NEON code ~8x slower that just a serial loop.
 
 /** Similar to memset(), but it assigns a 16bit value into the buffer.
     @param buffer   The memory to have value copied into it
@@ -29,12 +31,10 @@ namespace SkOpts {
     @param count    The number of times value should be copied into the buffer.
 */
 static inline void sk_memset16(uint16_t buffer[], uint16_t value, int count) {
-#if defined(_MSC_VER)
-    if (count > 300) { while (count --> 0) { *buffer++ = value; } return; }
-#elif defined(SK_BUILD_FOR_ANDROID) && defined(SK_CPU_X86)
-    if (count < 300) { while (count --> 0) { *buffer++ = value; } return; }
-#elif defined(SK_ARM_HAS_NEON) || SK_CPU_SSE_LEVEL >= SK_CPU_SSE_LEVEL_SSE2
-                     { while (count --> 0) { *buffer++ = value; } return; }
+#if defined(SK_CPU_ARM64)
+    while (count --> 0) { *buffer++ = value; } return;
+#elif defined(SK_CPU_ARM32)
+    if (count <= 10) { while (count --> 0) { *buffer++ = value; } return; }
 #endif
     SkOpts::memset16(buffer, value, count);
 }
@@ -45,12 +45,10 @@ static inline void sk_memset16(uint16_t buffer[], uint16_t value, int count) {
     @param count    The number of times value should be copied into the buffer.
 */
 static inline void sk_memset32(uint32_t buffer[], uint32_t value, int count) {
-#if defined(_MSC_VER)
-    if (count > 300) { while (count --> 0) { *buffer++ = value; } return; }
-#elif defined(SK_BUILD_FOR_ANDROID) && defined(SK_CPU_X86)
-    if (count < 300) { while (count --> 0) { *buffer++ = value; } return; }
-#elif defined(SK_ARM_HAS_NEON) || SK_CPU_SSE_LEVEL >= SK_CPU_SSE_LEVEL_SSE2
-                     { while (count --> 0) { *buffer++ = value; } return; }
+#if defined(SK_CPU_ARM64)
+    while (count --> 0) { *buffer++ = value; } return;
+#elif defined(SK_CPU_ARM32)
+    if (count <= 10) { while (count --> 0) { *buffer++ = value; } return; }
 #endif
     SkOpts::memset32(buffer, value, count);
 }