Truncate rather than round to nearest when performing float-to-integer...

Truncate rather than round to nearest when performing float-to-integer
conversions for external array types, which implement the Typed Array
spec. The new code paths are for SSE3 and SSE2 capable processors.
The code for non-SSE2 processors is unchanged for now. The ARM port
appears to already be correct.

Moved the generation of the external array load and store intrinsics
to the stub cache (on all platforms) so that they are generated at run
time and can take advantage of CPU features.

This functionality is covered by the array-unit-tests.html test in the
WebGL conformance test suite:
http://khronos.org/webgl/wiki/Testing/Conformance
https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/tests/conformance/array-unit-tests.html

Manually verified all of the SSE3/SSE2/non-SSE2 code paths by enabling
each in turn. Tested in Chromium on 32-bit Mac OS X and 64-bit Linux.

BUG=http://code.google.com/p/chromium/issues/detail?id=50972
TEST=none (see above)


Committed: http://code.google.com/p/v8/source/detail?r=6373

[Ken Russell (switch to Gerrit), 2011-01-14 01:03:36]

Please review. Thanks.

[William Hesse, 2011-01-14 14:58:17]

http://codereview.chromium.org/6315004/diff/1/src/ia32/stub-cache-ia32.cc
File src/ia32/stub-cache-ia32.cc (right):

http://codereview.chromium.org/6315004/diff/1/src/ia32/stub-cache-ia32.cc#new...
src/ia32/stub-cache-ia32.cc:3574: __ pop(ecx);
Why are SSE3 features used on ia32, but not on x64?  I see that the int32 case
uses cvttsd2siq on x64, but on the other cases, if cvttsd2si is best on x64, why
isn't it best on ia32.

http://codereview.chromium.org/6315004/diff/1/src/ia32/stub-cache-ia32.cc#new...
src/ia32/stub-cache-ia32.cc:3650: Label not_infinity;
I don't see why numbers outside the 32-bit int range are not returning MIN_INT,
which is then not screened out by this test.  So finite large numbers will
return MIN_INT, but on x64, they will return MIN_INT64 or large numbers mod
2^32.  Isn't this a difference between platforms?  What does the spec say.

http://codereview.chromium.org/6315004/diff/1/src/x64/assembler-x64.cc
File src/x64/assembler-x64.cc (right):

http://codereview.chromium.org/6315004/diff/1/src/x64/assembler-x64.cc#newcod...
src/x64/assembler-x64.cc:2723: 
disasm-x64.cc has an assert on line 1117 that will now fail.  It needs to be
changed, to look like the way disasm-x6 handles cvttsd2si.

[Ken Russell (switch to Gerrit), 2011-01-14 22:37:25]

I also simplified the code in stub-cache.cc which constructed the name of the
code stub, and removed the changes to string-stream.{h,cc} in favor of adding
two symbols to heap.h.

http://codereview.chromium.org/6315004/diff/1/src/ia32/stub-cache-ia32.cc
File src/ia32/stub-cache-ia32.cc (right):

http://codereview.chromium.org/6315004/diff/1/src/ia32/stub-cache-ia32.cc#new...
src/ia32/stub-cache-ia32.cc:3574: __ pop(ecx);
On 2011/01/14 14:58:17, William Hesse wrote:
> Why are SSE3 features used on ia32, but not on x64?  I see that the int32 case
> uses cvttsd2siq on x64, but on the other cases, if cvttsd2si is best on x64,
why
> isn't it best on ia32.

x64 can assume SSE2. This plus the availability of cvttsd2siq means x64 doesn't
need to touch the FP stack at all. The 32-bit code must use the FP stack at
least in some cases. It would make the 32-bit code much more complicated to use
the SSE2 instructions as the common case and only use fistpp / fistp as the
fallback for all of the array types.

http://codereview.chromium.org/6315004/diff/1/src/ia32/stub-cache-ia32.cc#new...
src/ia32/stub-cache-ia32.cc:3650: Label not_infinity;
On 2011/01/14 14:58:17, William Hesse wrote:
> I don't see why numbers outside the 32-bit int range are not returning
MIN_INT,
> which is then not screened out by this test.  So finite large numbers will
> return MIN_INT, but on x64, they will return MIN_INT64 or large numbers mod
> 2^32.  Isn't this a difference between platforms?  What does the spec say.

You're right, and the x64 code's behavior is what is desired here. I've changed
to use the fisttp_d / fistp_d code path for both the signed and unsigned int
array cases; this allows the +/-Infinity test to be removed, just like in the
x64 code.

http://codereview.chromium.org/6315004/diff/1/src/x64/assembler-x64.cc
File src/x64/assembler-x64.cc (right):

http://codereview.chromium.org/6315004/diff/1/src/x64/assembler-x64.cc#newcod...
src/x64/assembler-x64.cc:2723: 
On 2011/01/14 14:58:17, William Hesse wrote:
> disasm-x64.cc has an assert on line 1117 that will now fail.  It needs to be
> changed, to look like the way disasm-x6 handles cvttsd2si.

Done. Tested in 64-bit Chromium with --js-flags="--print_code_stubs" and
verified no assertion failures with the typed array unit tests.

[William Hesse, 2011-01-17 09:34:14]

LGTM.  Is there a bug filed for all cases where the spec is not implemented
exactly?

[Ken Russell (switch to Gerrit), 2011-01-18 21:42:40]

On 2011/01/17 09:34:14, William Hesse wrote:
> LGTM.  Is there a bug filed for all cases where the spec is not implemented
> exactly?

I've just filed http://code.google.com/p/v8/issues/detail?id=1056 to track the
remaining issues.

[Mads Ager (chromium), 2011-01-19 08:06:47]

This does not compile on ARM. I fixed that in r6376. However, the tests do not
pass on ARM after the compile fix. I'll revert this now. To test with the arm
simulator please use: tools/test.py --simulator=arm