Define S32A_Opaque_BlitRow32_SSE4_asm prototype only if SK_CPU_SSE_LEVEL >= SSE41

src/opts/SkBlitRow_opts_SSE4.h

 /*
  * Copyright 2014 The Android Open Source Project
  *
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  */
 
 #ifndef SkBlitRow_opts_SSE4_DEFINED
 #define SkBlitRow_opts_SSE4_DEFINED
 
 #include "SkBlitRow.h"
 
 #ifdef CRBUG_399842_FIXED

[mtklein, 2014/11/26 14:34:50]

Are you certain the change you're making here unblocks you?  I'm not sure I see
how that could be the case.

It looks like this header and the two .S files providing the implementation are
completely #ifdef'd away.  (cs.chromium.org/CRBUG_399842_FIXED)

We've disabled this proc because of the maintenance pain trying to use assembly
causes, and have not gotten around yet to rewriting it with intrinsics.

 
 /* Check if we are able to build assembly code, GCC/AT&T syntax:
  *  1) Clang and GCC are generally OK.  OS X's old LLVM-GCC 4.2 can't handle it;
  *  2) We're intentionally not linking this in even when supported (Clang) on Windows;
  *  3) MemorySanitizer cannot instrument assembly at all.
+ *  4) For other systems with old GCC 4.2 that can't handle it (e.g. OpenBSD).
  */
 #if /* 1)*/ (defined(__clang__) || (defined(__GNUC__) && !defined(SK_BUILD_FOR_MAC))) \
     /* 2)*/ && !defined(SK_BUILD_FOR_WIN)                                             \
-    /* 3)*/ && !defined(MEMORY_SANITIZER)
+    /* 3)*/ && !defined(MEMORY_SANITIZER)                                             \
+    /* 4)*/ && SK_CPU_SSE_LEVEL >= SK_CPU_SSE_LEVEL_SSE41

[mtklein, 2014/11/26 14:34:50]

If I'm thinking right, adding this check would restrict us to running this
method only when the build is built with global support for SSE 4.1, i.e. never.

Just like the SSSE3 code in the Mozilla bug, we want to compile this method
itself with -msse4.1, but we generally need to do a runtime cpuid to know
whether or not this method is safe to call.  That code, opts_check_x86.cpp,
needs to then see this declaration, but can't be built with -msse4.1 unless
we're certain the target machine will support SSE4.1.

(We tend to do builds with unconditional support for up to SSE2 now, though the
code will always be structured to work with vanilla portable code if you pass no
-msseN flags.)

We admittedly pay little attention to compilers that cannot compile SSSE3 or
SSE4 (or NEON or Thumb for ARM).  If the approach in
SkBitmapProcState_opts_SSSE3.cpp of linking stubs that throw works for you,
let's do the same for SSE4.  (Though every time I read those stubs I get a
little confused about why we want them to throw.  I'd think we want them to call
portable code in case we end up detecting that the machine really does support
SSSE3 / SSE4 and we try to use those methods?)

 extern "C" void S32A_Opaque_BlitRow32_SSE4_asm(SkPMColor* SK_RESTRICT dst,
                                                const SkPMColor* SK_RESTRICT src,
                                                int count, U8CPU alpha);
 
 #define SK_ATT_ASM_SUPPORTED
 #endif
 
 #endif // CRBUG_399842_FIXED
 
 #endif