Default to arm_v7_neon.

Default to arm_v7_neon.

This aliases all devices we know have NEON over to that too.

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/5ae0e2b56373b67a0fe6a0f9d7a0373712d1fa63

[mtklein_C, 2015-04-21 17:04:29]

mtklein@chromium.org changed reviewers:
+ djsollen@google.com

[djsollen, 2015-04-21 21:13:44]

lgtm

[mtklein, 2015-04-21 21:17:06]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2015-04-21 21:17:27]

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

[commit-bot: I haz the power, 2015-04-21 21:25:38]

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

[Stephen White, 2015-04-22 20:56:09]

This seems to have affected some GM results (unless gold is lying to me).

E.g., https://gold.skia.org/#/triage/concavepaths?head=1

Was this expected?

[mtklein, 2015-04-23 03:28:13]

On 2015/04/22 20:56:09, Stephen White wrote:
> This seems to have affected some GM results (unless gold is lying to me).
> 
> E.g., https://gold.skia.org/#/triage/concavepaths?head=1
> 
> Was this expected?

Yes, though it's perhaps worth looking into.  sk_float_rsqrt() has a different
implementation when NEON is available, which is faster but somewhat lower
precision than the portable alternative.  This is used by
SkPoint::setLengthFast(), which is in turn used by distance field generation,
which I believe is used to draw these paths.  (Or at least that was the scenario
last time I traced it through.)  I've never seen it be a glaring problem, but if
we find places where the precision is noticeably too low, we can refine it with
another Newton's method step.