Implement CPU feature detection for ARM Linux.

webrtc/system_wrappers/cpu_features_webrtc.gyp

 # Copyright (c) 2014 The WebRTC project authors. All Rights Reserved.
 #
 # Use of this source code is governed by a BSD-style license
 # that can be found in the LICENSE file in the root of the source
 # tree. An additional intellectual property rights grant can be found
 # in the file PATENTS.  All contributing project authors may
 # be found in the AUTHORS file in the root of the source tree.
 
 {
+  'includes': [ '../build/common.gypi', ],
   'conditions': [
     ['OS=="android"', {
       'targets': [
         {
           'target_name': 'cpu_features_android',
           'type': 'static_library',
           'sources': [
             'source/cpu_features_android.c',
           ],
           'dependencies': [
             '../../build/android/ndk.gyp:cpu_features',
           ],
         },
       ],
     }],
+    ['OS=="linux"', {
+      'targets': [
+        {
+          'target_name': 'cpu_features_linux',

[kjellander_webrtc, 2016/04/04 06:09:45]

Does it make sense to add similar target in
webrtc/system_wrappers/cpu_features_chromium.gyp or will it not build and/or
provide any value to the Chromium build? Since they also have some support for
Linux ARM, I imagine they would also want to use this code.

[Simon Hosie, 2016/04/05 01:15:48]

I would have hoped so, but I can't seem to produce a link error in Chromium
either with or without this function.  This suggests that Chromium hard-codes
WebRTC's NEON support always-on or always-off, with no run-time detection under
Linux.

If it's always-off that's obviously not ideal, and I'm not sure how far that
issue would currently extend.  Android may be configured the same way, and I
would expect ChromeOS to follow the Linux path.  If there hasn't been any
complaint about building for ChromeOS previously then that may also be missing
out on NEON (although it could equally be hard-coded always-on on a per-platform
basis).

I don't know what GYP_DEFINE (or similar) is necessary to enable run-time
detection.  The original build-blocker, and the way I tested the function, was
in one of the unit tests which calls WebRtc_GetCPUFeaturesARM() outside of a
WEBRTC_DETECT_NEON guard (which makes sense in context; no need to fix that).

If I find out what to do to Chromium to make sure it requests run-time NEON
detection from WebRTC, then I can try to figure out what fits where.

[kjellander_webrtc, 2016/04/05 09:27:51]

I remember that in the past CPU detection was enabled for libvpx in Chromium
since
they shipped to devices that doesn't have Neon. IIRC that was about to change
and it
might have now. 
I've asked johannkoenig@ to comment on this (CC'ed).

Let's not worry more about the Chromium case in this CL - that can always be
worked
on in the future. The important thing now it unblock this work.
I'm pretty sure there is no GYP_DEFINES setting that controls this.
Sounds good, let's do that separate from this CL though.

+          'type': 'static_library',
+          'sources': [
+            'source/cpu_features_linux.c',
+          ],
+          'dependencies': [
+            '<(webrtc_root)/common.gyp:webrtc_common',
+          ],
+        },
+      ],
+    }],
   ], # conditions
 }