Revert of 565 support for SIMD xfermodes (patchset #4 id:60001 of https://codereview.chromium.org/1245673002/)

Reason for revert:
NEON 565 gold images have gone ugly.  This is what I get for writing and testing SSE and just writing NEON.

E.g. colortype_xfermodes, dstreadshuffle, bigbitmaprect, pictures, textbloblooper, aaxfermodes (only Plus)

Original issue's description:
> 565 support for SIMD xfermodes
>
> This uses the most basic approach possible:
>   - to load an Sk4px from 565, convert to SkPMColors on the stack serially then load those SkPMColors.
>   - to store an Sk4px to 565, store to SkPMColors on the stack then convert to 565 serially.
>
> Clearly, we can optimize these loads and stores.  That's a TODO.
>
> The code using SkPMFloat is the same idea but a little more long-term viable, as we're only operating on one pixel at a time anyway.  We could probably write 565 <-> SkPMFloat methods, but I'd rather not until it's really compelling.
>
> The speedups are varied but similar across SSE and NEON: a few uninteresting, many 50% faster, some 2x faster, and SoftLight ~4x faster.
>
> This will cause minor GM diffs, but I don't think any layout test changes.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/942930dcaa51f66d82cdaf46ae62efebd16c8cd0
>
> Committed: https://skia.googlesource.com/skia/+/860dcaa2ddfdadc050af4f943a84a9d499315066

TBR=msarett@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:

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

1 files changed, 6 insertions, 15 deletions

diff --git a/src/core/Sk4px.h b/src/core/Sk4px.h
index 24a21c66c1..e1d4dc1244 100644
--- a/src/core/Sk4px.h
+++ b/src/core/Sk4px.h
@@ -10,7 +10,6 @@
 
 #include "SkNx.h"
 #include "SkColor.h"
-#include "SkColorPriv.h"
 
 // This file may be included multiple times by .cpp files with different flags, leading
 // to different definitions.  Usually that doesn't matter because it's all inlined, but
@@ -48,14 +47,6 @@ public:
     void store2(SkPMColor[2]) const;
     void store1(SkPMColor[1]) const;
 
-    // Same as above for 565.
-    static Sk4px Load4(const SkPMColor16 src[4]);
-    static Sk4px Load2(const SkPMColor16 src[2]);
-    static Sk4px Load1(const SkPMColor16 src[1]);
-    void store4(SkPMColor16 dst[4]) const;
-    void store2(SkPMColor16 dst[2]) const;
-    void store1(SkPMColor16 dst[1]) const;
-
     // 1, 2, or 4 SkPMColors with 16-bit components.
     // This is most useful as the result of a multiply, e.g. from mulWiden().
     class Wide : public Sk16h {
@@ -108,8 +99,8 @@ public:
 
     // A generic driver that maps fn over a src array into a dst array.
     // fn should take an Sk4px (4 src pixels) and return an Sk4px (4 dst pixels).
-    template <typename Fn, typename Dst>
-    static void MapSrc(int n, Dst* dst, const SkPMColor* src, const Fn& fn) {
+    template <typename Fn>
+    static void MapSrc(int n, SkPMColor* dst, const SkPMColor* src, const Fn& fn) {
         // This looks a bit odd, but it helps loop-invariant hoisting across different calls to fn.
         // Basically, we need to make sure we keep things inside a single loop.
         while (n > 0) {
@@ -138,8 +129,8 @@ public:
     }
 
     // As above, but with dst4' = fn(dst4, src4).
-    template <typename Fn, typename Dst>
-    static void MapDstSrc(int n, Dst* dst, const SkPMColor* src, const Fn& fn) {
+    template <typename Fn>
+    static void MapDstSrc(int n, SkPMColor* dst, const SkPMColor* src, const Fn& fn) {
         while (n > 0) {
             if (n >= 8) {
                 Sk4px dst0 = fn(Load4(dst+0), Load4(src+0)),
@@ -166,8 +157,8 @@ public:
     }
 
     // As above, but with dst4' = fn(dst4, src4, alpha4).
-    template <typename Fn, typename Dst>
-    static void MapDstSrcAlpha(int n, Dst* dst, const SkPMColor* src, const SkAlpha* a,
+    template <typename Fn>
+    static void MapDstSrcAlpha(int n, SkPMColor* dst, const SkPMColor* src, const SkAlpha* a,
                                const Fn& fn) {
         while (n > 0) {
             if (n >= 8) {