Create vmx_memchr() and use it (along with other JS string matching improvements)

[classilla]

A la https://bugzilla.mozilla.org/show_bug.cgi?id=1371215 :

We should be using the unrolled version, not memchr(), which is apparently gross and slow on anything before 10.12 (see https://gist.github.com/nico/2624336 ). In particular the defined (__clang__) is wrong, so we need to correct the block in https://hg.mozilla.org/mozilla-central/rev/f4048987a5e3

Once that is done, we can take https://hg.mozilla.org/integration/mozilla-inbound/rev/fce84022f5e3 and https://hg.mozilla.org/integration/mozilla-inbound/rev/35b9efa24066 (minus the change above, of course).

[classilla]

Conceivably we could even vectorize it. Here is a fast memchr():

https://github.com/ridiculousfish/HexFiend/blob/4d5bcee5715f5f288649f7471d1da5bd06376f46/framework/sources/HFFastMemchr.m

[classilla]

memchr() pops up a few other places, too. Maybe we should create a vmx_memchr() and start using it. In particular it's in netwerk/ nsprpub/ xpcom/ and even layout/ as well as ICU.

[classilla]

For comparison:
https://opensource.apple.com/source/Libc/Libc-391.2.10/string/FreeBSD/memchr.c.auto.html
https://opensource.apple.com/source/Libc/Libc-498.1.7/string/FreeBSD/memchr.c

No wonder it sucks.

[classilla]

This implies that for anything less than the size of stride (which I guess means at least one vector), a simple-minded routine is better.

https://sourceware.org/viewvc/src/newlib/libc/string/memchr.c?revision=1.4&view=markup

[classilla]

First pass, disabling memchr() and using the built-in unrolled FirstChar* matcher, improves V8 from a peak of 3001 (Quad in Reduced) to 3033 (same).

[classilla]

VMX version currently around 3050, though the biggest improvement is on regexp (as expected, since it matches against very long strings). There are still some possible improvements to be made, as well as the rest of the string matching changes.

[classilla]

No others to convert that make sense.