skip neon code in libwebp when neon is explicitly unavailable

skip neon code in libwebp when neon is explicitly unavailable

This patch makes it possible to build libwebp without runtime neon detection/usage.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=242079

[Mostyn Bramley-Moore, 2013-11-28 23:07:23]

@fbarchard: PTAL

[fbarchard, 2013-11-29 06:39:19]

On 2013/11/28 23:07:23, Mostyn Bramley-Moore wrote:
> @fbarchard: PTAL

Your cl will limit neon to a build that enables neon for the full binary.
libyuv has run time dispatching - the intent is to create a fat binary that runs
on cpus.  Which requires 2 builds - one for neon and one for non-neon.  Is that
the intent?

[Mostyn Bramley-Moore, 2013-11-29 08:20:50]

On 2013/11/29 06:39:19, fbarchard wrote:
> On 2013/11/28 23:07:23, Mostyn Bramley-Moore wrote:
> > @fbarchard: PTAL
> 
> Your cl will limit neon to a build that enables neon for the full binary.
> libyuv has run time dispatching - the intent is to create a fat binary that
runs
> on cpus.  Which requires 2 builds - one for neon and one for non-neon.  Is
that
> the intent?

The intent is to make it possible to build explicitly non-neon builds, while
still allowing fat binary builds- I added the missing arm_neon_optional check in
patch set 4.

[fbarchard, 2013-12-02 09:50:40]

WEBP_USE_NEON is not set in the gyp file?
Won't this completely disable webp Neon code?

Take a look at how skia did their neon.
https://chromium.googlesource.com/experimental/chromium/src/+/git-svn/skia/sk...

[Mostyn Bramley-Moore, 2013-12-03 13:41:04]

On 2013/12/02 09:50:40, fbarchard wrote:
> WEBP_USE_NEON is not set in the gyp file?
> Won't this completely disable webp Neon code?
> 
> Take a look at how skia did their neon.
>
https://chromium.googlesource.com/experimental/chromium/src/+/git-svn/skia/sk...

I don't think so- dsp.h sets WEBP_USE_NEON if __ARM_NEON__ is set, and ARM
claims that GCC sets __ARM_NEON__ when compiling for a target that supports
NEON:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0004a/CHDBAIDJ...

And the android_rel build appears to have still built these files, eg:
[113/17070] CC obj/third_party/libwebp/dsp/libwebp_dsp_neon.dec_neon.o

[fbarchard, 2013-12-09 18:56:29]

have you confirmed that neon is available on fat binaries, where Neon is
optional?

[Mostyn Bramley-Moore, 2013-12-09 23:48:00]

Not yet- I'll try to confirm this tomorrow and get back to you.

[Mostyn Bramley-Moore, 2013-12-20 00:09:37]

Sorry it took me so long to get back to this.

I tried making a build with the arm-linux-gnueabihf-gcc-4.7 compiler available
in ubuntu, and these gyp settings:
  arm_version=7
  arm_arch='armv7-a'
  arm_fpu='vfpv3-d16'
  arm_neon_optional=1
  arm_neon=0

With this setup, the three *_neon.c files are built with -mfpu=neon and the rest
are built with -mfpu=vfpv3-d16.  When building with -mfpu=neon the compiler
defines __ARM_NEON__ 1 and so the neon code is built, just like it is without
this CL, so it looks like the fat build works as expected.

If I set arm_neon_option=0 instead, then -mfpu=vfpv3-d16 is always used, and as
expected no neon code is built.

This behaviour looks correct to me.

[Mostyn Bramley-Moore, 2013-12-20 00:10:51]

> If I set arm_neon_option=0 instead, then -mfpu=vfpv3-d16 is always used, and
as
> expected no neon code is built.

I meant to say "arm_neon_optional=0", of course.

[fbarchard, 2013-12-20 02:17:25]

On 2013/12/20 00:10:51, Mostyn Bramley-Moore wrote:
> > If I set arm_neon_option=0 instead, then -mfpu=vfpv3-d16 is always used, and
> as
> > expected no neon code is built.
> 
> I meant to say "arm_neon_optional=0", of course.

lgtm

May want to check that android try bot.  Thanks

[commit-bot: I haz the power, 2013-12-20 09:11:50]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mostynb@opera.com/95873002/50001

[commit-bot: I haz the power, 2013-12-20 12:45:06]

Change committed as 242079