Define S32A_Opaque_BlitRow32_SSE4_asm prototype only if SK_CPU_SSE_LEVEL >= SSE41

Define S32A_Opaque_BlitRow32_SSE4_asm prototype only if SK_CPU_SSE_LEVEL >= SSE41

Define the S32A_Opaque_BlitRow32_SSE4_asm prototype
only if SK_CPU_SSE_LEVEL >= SK_CPU_SSE_LEVEL_SSE41.

This change is needed to build Skia within Firefox on
systems (OpenBSD/i386) with an old GCC 4.2 which can't handle -mss4.1.

See: https://bugzilla.mozilla.org/show_bug.cgi?id=1028827

BUG=skia:

[fraetz, 2014-10-30 12:20:32]

fabian.raetz@gmail.com changed reviewers:
+ henrik.smiding@intel.com, mtklein@skia.org

[fraetz, 2014-10-30 12:31:33]

fabian.raetz@gmail.com changed reviewers:
+ reed@google.com

[fraetz, 2014-11-26 10:41:15]

On 2014/10/30 12:31:33, fraetz wrote:
> mailto:fabian.raetz@gmail.com changed reviewers:
> + mailto:reed@google.com

Hi,

is there anything i can do to get this merged? 

This issue is blocking the Firefox issue.

[reed1, 2014-11-26 14:22:58]

reed@google.com changed reviewers:
+ mtklein@google.com

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

https://codereview.chromium.org/673903006/diff/1/src/opts/SkBlitRow_opts_SSE4.h
File src/opts/SkBlitRow_opts_SSE4.h (right):

https://codereview.chromium.org/673903006/diff/1/src/opts/SkBlitRow_opts_SSE4...
src/opts/SkBlitRow_opts_SSE4.h:13: #ifdef CRBUG_399842_FIXED
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.

https://codereview.chromium.org/673903006/diff/1/src/opts/SkBlitRow_opts_SSE4...
src/opts/SkBlitRow_opts_SSE4.h:24: /* 4)*/ && SK_CPU_SSE_LEVEL >=
SK_CPU_SSE_LEVEL_SSE41
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?)