Improve FastCloneShallowArray/ObjectStubs with VFP copying on ARM

Improve FastCloneShallowArray/ObjectStubs with VFP copying on ARM
BUG=none
TEST=none

[danno, 2012-10-29 15:29:24]

http://codereview.chromium.org/11151005/diff/1/src/arm/code-stubs-arm.cc
File src/arm/code-stubs-arm.cc (right):

http://codereview.chromium.org/11151005/diff/1/src/arm/code-stubs-arm.cc#newc...
src/arm/code-stubs-arm.cc:334: return CpuFeatures::IsSupported(VFP2) ? 128 : 8;
By increasing this to 128, V8 will generate 128 versions of this stub rather
then 8, which will explode the footprint of clone stubs in the snapshot. 8 was
chosen because it finds the sweet-spot between amount of code generation and the
more frequent cases. Please keep it constant and fixed to 8, I think your
optimization still applies, even for shorter arrays.

http://codereview.chromium.org/11151005/diff/1/src/arm/code-stubs-arm.cc#newc...
src/arm/code-stubs-arm.cc:483: return CpuFeatures::IsSupported(VFP2) ? 96 : 6;
Similarly here, please keep at constant 6, unless you have code that
demonstrates that cases >6 are frequent enough to justify this.

http://codereview.chromium.org/11151005/diff/1/src/arm/macro-assembler-arm.cc
File src/arm/macro-assembler-arm.cc (right):

http://codereview.chromium.org/11151005/diff/1/src/arm/macro-assembler-arm.cc...
src/arm/macro-assembler-arm.cc:3168: ASSERT_LE(first.code(), last.code());
In debug mode, can you please actually verify in generated code assert that the
pointers are not tagged?

[Jay Conrod, 2012-10-29 19:47:37]

Thanks for the comments. This new revision should address everything.

[danno, 2012-10-30 14:28:59]

LGTM with a nit. I'll land this for you when the feature freeze is lifted for
3.15 later this week

http://codereview.chromium.org/11151005/diff/13001/src/arm/macro-assembler-ar...
File src/arm/macro-assembler-arm.cc (right):

http://codereview.chromium.org/11151005/diff/13001/src/arm/macro-assembler-ar...
src/arm/macro-assembler-arm.cc:3239: }
nit: two spaces

[m.m.capewell, 2012-10-31 13:37:41]

On Cortex-A9 using svn revision 12837, we see a performance decrease of ~6% on
Octane/Box2D and ~12% on Octane/CodeLoad after applying the patch. Can you
confirm?

[Jay Conrod, 2012-11-01 00:20:19]

I need to borrow a Cortex A9 device from someone here to confirm this. Will get
back to you soon.

[danno, 2012-11-02 14:12:51]

I have been able to confirm a regression on a nexus prime (A9), although the
regression isn't 100% reproducible. I additionally see a 3.5% regression on
Octane/PDF.js, which does seem reproducible. I'll wait to land this until the
regressions can be addressed.