De-templatize Sk4pxXfermode code a bit.

De-templatize Sk4pxXfermode code a bit.

This deduplicates a few pieces of code:
  - we end up with one copy of each xfer32() driver loop instead of one per xfermode;
  - we end up with two* copies of each xfermode implementation instead of ten**.

* For a given Mode: Mode() itself and xfer_aa<Mode>().
** From unrolling: twice at a stride of 8, once at 4, once at 2, and once at 1, then all again for when we have AA.

This decreases the size of SkXfermode.o from 1.5M to 620K on x86-64 and from 1.3M to 680K on ARMv7+NEON.

If we wanted to, we could eliminate the xfer_aa<Mode>() copy by tagging each Mode() function as __attribute__((noinline)) or its equivalent.  This would result in another ~100K space savings.

Performance is affected in proportion to the original xfermode speed:
fast modes like Plus take the largest proportional hit, and slow modes
like HardLight or SoftLight see essentially no hit at all.

This adds SK_VECTORCALL to help keep this code fast on ARMv7 and Windows.  I've looked at the ARMv7 generated code... it looks good, even pretty.

For compatibility with SK_VECTORCALL, we now pass the vector-sized arguments by value instead of by reference.  Some refactoring now allows us to declare each mode as just a static function instead of a struct, which simplifies things.

TBR=reed@google.com
No public API changes.

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/e617e1525916d7ee684142728c0905828caf49da

CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu-GCC-Arm7-Debug-Android_NoNeon-Trybot

Committed: https://skia.googlesource.com/skia/+/cd1930d4f19297c4089d7cb278243e4815c5793d

[mtklein, 2015-07-21 18:10:21]

The CQ bit was checked by mtklein@google.com to run a CQ dry run

[commit-bot: I haz the power, 2015-07-21 18:10:32]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1242743004/1

[commit-bot: I haz the power, 2015-07-21 18:14:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-07-21 18:14:03]

Dry run: Try jobs failed on following builders:
  Build-Win-MSVC-x86-Debug-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Win-MSVC-x86-D...)
  Build-Win-MSVC-x86_64-Debug-Trybot on client.skia.compile (JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Win-MSVC-x86_6...)

[mtklein, 2015-07-21 18:16:49]

The CQ bit was checked by mtklein@google.com to run a CQ dry run

[commit-bot: I haz the power, 2015-07-21 18:17:02]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1242743004/20001

[mtklein_C, 2015-07-21 18:30:36]

mtklein@chromium.org changed reviewers:
+ msarett@google.com
- mtklein@google.com

[commit-bot: I haz the power, 2015-07-21 18:34:46]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-07-21 18:34:47]

Dry run: This issue passed the CQ dry run.

[msarett, 2015-07-21 18:59:21]

lgtm

I find it interesting that we are willing to sacrifice a little performance to
decrease the size of the binary.  Out of curiosity, was the revert of the
original CL caused by some sort of automated test failure or did you catch the
problem yourself?

[mtklein, 2015-07-21 19:01:26]

On 2015/07/21 18:59:21, msarett wrote:
> lgtm
> 
> I find it interesting that we are willing to sacrifice a little performance to
> decrease the size of the binary.  Out of curiosity, was the revert of the
> original CL caused by some sort of automated test failure or did you catch the
> problem yourself?

I think there is an automated test, but someone else caught it.

https://code.google.com/p/chromium/issues/detail?id=512342

[mtklein, 2015-07-21 19:03:04]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2015-07-21 19:03:13]

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

[commit-bot: I haz the power, 2015-07-21 19:03:40]

Committed patchset #2 (id:20001) as
https://skia.googlesource.com/skia/+/e617e1525916d7ee684142728c0905828caf49da

[mtklein, 2015-07-21 19:07:41]

A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/1245273005/ by mtklein@google.com.

The reason for reverting is:
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-GCC-Arm....

[mtklein, 2015-07-21 19:14:01]

The CQ bit was checked by mtklein@google.com

[mtklein, 2015-07-21 19:14:02]

The patchset sent to the CQ was uploaded after l-g-t-m from msarett@google.com
Link to the patchset: https://codereview.chromium.org/1242743004/#ps40001
(title: "fix no-neon build")

[commit-bot: I haz the power, 2015-07-21 19:14:12]

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

[commit-bot: I haz the power, 2015-07-21 19:17:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-07-21 19:17:11]

Try jobs failed on following builders:
  Build-Ubuntu-GCC-Arm7-Debug-Android_NoNeon-Trybot on client.skia.compile
(JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu-GCC-Arm...)

[mtklein_C, 2015-07-21 19:18:26]

The CQ bit was checked by mtklein@chromium.org

[mtklein_C, 2015-07-21 19:18:27]

The patchset sent to the CQ was uploaded after l-g-t-m from msarett@google.com
Link to the patchset: https://codereview.chromium.org/1242743004/#ps60001
(title: "really fix")

[commit-bot: I haz the power, 2015-07-21 19:18:40]

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

[mtklein, 2015-07-21 19:19:24]

On 2015/07/21 18:59:21, msarett wrote:
> lgtm
> 
> I find it interesting that we are willing to sacrifice a little performance to
> decrease the size of the binary.  Out of curiosity, was the revert of the
> original CL caused by some sort of automated test failure or did you catch the
> problem yourself?

Here's a proxy chart we can watch based on data available in perf.skia.org:

https://perf.skia.org/#3812

[commit-bot: I haz the power, 2015-07-21 19:39:59]

Committed patchset #4 (id:60001) as
https://skia.googlesource.com/skia/+/cd1930d4f19297c4089d7cb278243e4815c5793d

[mtklein, 2015-07-21 19:56:16]

On 2015/07/21 19:19:24, mtklein wrote:
> On 2015/07/21 18:59:21, msarett wrote:
> > lgtm
> > 
> > I find it interesting that we are willing to sacrifice a little performance
to
> > decrease the size of the binary.  Out of curiosity, was the revert of the
> > original CL caused by some sort of automated test failure or did you catch
the
> > problem yourself?
> 
> Here's a proxy chart we can watch based on data available in
http://perf.skia.org:
> 
> https://perf.skia.org/#3812

And here's the corresponding speed chart, lower is better:
https://perf.skia.org/#3816