Ignore arm_neon_optional if arm_neon==1 in skia.

Ignore arm_neon_optional if arm_neon==1 in skia.

BUG=451035
Committed: https://crrev.com/b5054646a30a5ad3225dca300616c0d018f7b2fa
Cr-Commit-Position: refs/heads/master@{#330512}

[Fabrice (no longer in Chrome), 2015-05-19 11:54:32]

fdegans@chromium.org changed reviewers:
+ mtklein@chromium.org, pasko@chromium.org, reed@chromium.org

[Fabrice (no longer in Chrome), 2015-05-19 11:54:33]

PTAL, this fixes the tri-state, which I'm explaining below:

On Arm, NEON is an optional part of the platform. We have 2 variables in GYP
controlling this behavior: arm_neon and arm_neon_optional.
arm_neon indicates whether we want the target build to run on non-NEON platforms
(set to 0) or not (set to 1).
arm_neon_optional is used when arm_neon is set to 1. This indicates that we want
to use runtime NEON detection and have optional NEON code in critical codepaths.
Having both these variables set to 1 makes no sense, as this would indicate we
are producing a build that will not run on non-NEON platforms while still doing
runtime detection. Thus, arm_neon_optional should be ignored if arm_neon==1.

I agree this is a confusing tri-state with poorly-named variables.

[mtklein_C, 2015-05-19 12:47:16]

lgtm, but I'm fairly sure this is a no-op.  Skia ignores
SK_ARM_HAS_OPTIONAL_NEON when SK_ARM_HAS_NEON is set... if you set both, we
won't do any runtime checks.

[pasko, 2015-05-19 12:50:23]

again, can we wait for the data about non-neon devices before landing this?

[pasko, 2015-05-19 12:51:43]

On 2015/05/19 12:50:23, pasko wrote:
> again, can we wait for the data about non-neon devices before landing this?

ah, sorry, this one can actually land, lgtm

[Fabrice (no longer in Chrome), 2015-05-19 12:59:05]

On 2015/05/19 12:47:16, mtklein_C wrote:
> lgtm, but I'm fairly sure this is a no-op.  Skia ignores
> SK_ARM_HAS_OPTIONAL_NEON when SK_ARM_HAS_NEON is set... if you set both, we
> won't do any runtime checks.

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/skia/s...
This actually seems to be the other way around, SK_ARM_HAS_OPTIONAL_NEON takes
precedence.

[mtklein, 2015-05-19 13:01:20]

On 2015/05/19 12:59:05, Fabrice wrote:
> On 2015/05/19 12:47:16, mtklein_C wrote:
> > lgtm, but I'm fairly sure this is a no-op.  Skia ignores
> > SK_ARM_HAS_OPTIONAL_NEON when SK_ARM_HAS_NEON is set... if you set both, we
> > won't do any runtime checks.
> 
>
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/skia/s...
> This actually seems to be the other way around, SK_ARM_HAS_OPTIONAL_NEON takes
> precedence.

Wow, you're right!  That's dumb.

[Fabrice (no longer in Chrome), 2015-05-19 13:15:19]

The CQ bit was checked by fdegans@chromium.org

[commit-bot: I haz the power, 2015-05-19 13:15:34]

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

[commit-bot: I haz the power, 2015-05-19 13:19:39]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-05-19 13:20:34]

Patchset 2 (id:??) landed as
https://crrev.com/b5054646a30a5ad3225dca300616c0d018f7b2fa
Cr-Commit-Position: refs/heads/master@{#330512}