SkPMFloat: avoid loads and stores where possible.

SkPMFloat: avoid loads and stores where possible.

A store/load pair like this is a redundant no-op:
  store simd_register_a, memory_address
  load  memory_address, simd_register_a

Everyone seems to be good at removing those when using SSE, but GCC and Clang
are pretty terrible at this for NEON.  We end up issuing both redundant
commands, usually to and from the stack.  That's slow.  Let's not do that.

This CL unions in the native SIMD register type into SkPMFloat, so that we can
assign to and from it directly, which is generating a lot better NEON code.  On
my Nexus 5, the benchmarks improve from 36ns to 23ns.

SSE is just as fast either way, but I paralleled the NEON code for consistency.
It's a little terser.  And because it needed the platform headers anyway, I
moved all includes into SkPMFloat.h, again only for consistency.

I'd union in Sk4f too to make its conversion methods a little clearer,
but MSVC won't let me (it has a copy constructor... they're apparently not up
to speed with C++11 unrestricted unions).

BUG=skia:

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

[mtklein, 2015-03-18 16:24:27]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2015-03-18 16:24:36]

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

[commit-bot: I haz the power, 2015-03-18 16:24:37]

Note for Reviewers:
The CQ is waiting for an approval.
If you believe that the CL is not ready yet, or if you would like to L-G-T-M
with comments then please uncheck the CQ checkbox.

Waiting for LGTM from valid reviewer(s) till 2015-03-18 22:24 UTC

[commit-bot: I haz the power, 2015-03-18 16:29:23]

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

[commit-bot: I haz the power, 2015-03-18 16:29:23]

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

[mtklein, 2015-03-18 16:29:51]

Patchset #2 (id:20001) has been deleted

[mtklein, 2015-03-18 16:31:55]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2015-03-18 16:32:04]

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

[commit-bot: I haz the power, 2015-03-18 16:32:05]

Note for Reviewers:
The CQ is waiting for an approval.
If you believe that the CL is not ready yet, or if you would like to L-G-T-M
with comments then please uncheck the CQ checkbox.

Waiting for LGTM from valid reviewer(s) till 2015-03-18 22:32 UTC

[mtklein_C, 2015-03-18 16:36:49]

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

[mtklein_C, 2015-03-18 16:36:49]

What do you think about landing this first, to get the store/load noise out,
then taking another look at your 4-at-a-time CL?

[msarett, 2015-03-18 16:50:13]

lgtm

I think this is a good step.  The loads and stores in the benchmarks are
artificial anyway, so timing them doesn't really provide us with any useful
information (and they compile so poorly for Neon that they are distracting).

My one thought is that at some point we may care about the performance of the
loads and stores in conjunction with the convert code.  But I think we can worry
about this later on.  Also, I'm not sure that this is true at all because I
still only have a kind of vague picture of how we are using this pipeline.

[commit-bot: I haz the power, 2015-03-18 16:51:27]

Committed patchset #1 (id:1) as
https://skia.googlesource.com/skia/+/f94fa7112f67af6fc5db19f86d8397307ba17105

[mtklein, 2015-03-18 18:10:06]

> My one thought is that at some point we may care about the performance of the
> loads and stores in conjunction with the convert code.  But I think we can
worry
> about this later on.  Also, I'm not sure that this is true at all because I
> still only have a kind of vague picture of how we are using this pipeline.

I think at that point it'll be better served by a different bench, perhaps a
microbench but ideally some real drawing.  That way we can keep the current
benches focused on just the conversions.

[msarett, 2015-03-18 18:14:01]

Agreed.

Benchmarking the convert within the actual context it is used will probably be
the time and place to measure the impact of loads and stores.