Update libjpeg_turbo to use clz for bitcounting on ARM

Update libjpeg_turbo to use clz for bitcounting on ARM

Cherry-picked r1220 from upstream:
Use clz/bsr instructions on ARM for bit counting rather than the lookup table (reduces memory footprint and can improve performance in some cases.)

Upstream review:
http://sourceforge.net/p/libjpeg-turbo/patches/57/

Original review:
https://codereview.appspot.com/77480045/

Removing the lookup table saves 64k data for each process that uses jpeg encoding. Benchmarks on a few ARM devices shows encoding performance changes, from a slowdown of 3-4% on some devices, to a speedup of 10-20% on other devices. In average performance improves.

x86 will still use the lookup table because the bsr instruction showed to be slower on some chips.

BUG=

[noel chromium, 2014-05-23 12:13:52]

Looking good. Please also compute the diff for jchuff.c and add it to the
google.patch file.  Then upload a new change list with the google.patch changes
included?

[noel chromium, 2014-05-23 12:25:09]

Minor thing: the title of this issue should be the first line of the change
description, followed by an empty line, and then the body of the change
description.

[Olle Liljenzin, 2014-05-23 12:43:27]

Updated title of this issue and uploaded the updated google.patch file.

[noel chromium, 2014-05-23 13:19:13]

LGTM

[Olle Liljenzin, 2014-05-23 13:35:44]

Noel, I don't think I have permission to run 'git cl dcommit'. So could you do
it for me?

[noel chromium, 2014-05-23 23:57:48]

Committed the patch manually.  Reset your local libjpeg_turbo, git svn fetch,
and let me know if your changes were pulled into your client.

[Olle Liljenzin, 2014-05-26 11:12:21]

On 2014/05/23 23:57:48, noel chromium wrote:
> Committed the patch manually.  Reset your local libjpeg_turbo, git svn fetch,
> and let me know if your changes were pulled into your client.

Yes, fetch gives me the commit. So I should now roll the DEPS file?

[noel chromium, 2014-05-26 12:26:54]

Yes, prepare a patch to roll DEPS and upload it, reviewer inferno@chromium.org,
cc me, and run try jobs.

[Olle Liljenzin, 2014-05-26 12:47:41]

On 2014/05/26 12:26:54, noel chromium wrote:
> Yes, prepare a patch to roll DEPS and upload it, reviewer
mailto:inferno@chromium.org,
> cc me, and run try jobs.

https://codereview.chromium.org/302453007/

[noel chromium, 2014-05-27 00:11:00]

Doing the DEPS roll on https://codereview.chromium.org/300553007

[noel chromium, 2014-05-28 03:36:39]

re the x86 comment: "bsr instruction showed to be slower on some chips."  Just
curious: which chips - old ones, new ones, specific types ...?

[Olle Liljenzin, 2014-05-28 07:18:05]

On 2014/05/28 03:36:39, noel chromium wrote:
> re the x86 comment: "bsr instruction showed to be slower on some chips."  Just
> curious: which chips - old ones, new ones, specific types ...?

In the tests by DCR and me we found older AMDs to be slow.

When searching around I found the following draft paper by Torbjörn Granlund
that claims slow bsr timings on Intel P4, AMD K6-K9 and on Intel Atom, although
I haven't verified if these numbers apply directly to the jpeg encoding
performance:
https://gmplib.org/~tege/x86-timing.pdf


And thanks for all help with the review!