Fix rounding in Uint8ClampedArray setter.

Fix rounding in Uint8ClampedArray setter.

According to Web IDL spec, we should round to
the nearest integer, choosing the even integer
if it lies halfway between two.

R=yangguo@chromium.org,kbr@chromium.org
BUG=v8:2294
Committed: https://code.google.com/p/v8/source/detail?r=12364

[ulan, 2012-08-21 17:29:33]

Please take a look.

[Yang, 2012-08-22 07:57:06]

LGTM with comments addressed.

https://chromiumcodereview.appspot.com/10831409/diff/1/src/arm/macro-assemble...
File src/arm/macro-assembler-arm.cc (right):

https://chromiumcodereview.appspot.com/10831409/diff/1/src/arm/macro-assemble...
src/arm/macro-assembler-arm.cc:3695: vmsr(ip);
Could you use EmitVFPTruncate instead? I'm not entirely sure why it checks for
VFP exceptions. Maybe you should too. Or you could modify EmitVFPTruncate to
make the check optional.

https://chromiumcodereview.appspot.com/10831409/diff/1/src/ia32/assembler-ia3...
File src/ia32/assembler-ia32.cc (right):

https://chromiumcodereview.appspot.com/10831409/diff/1/src/ia32/assembler-ia3...
src/ia32/assembler-ia32.cc:1947: emit_sse_operand(dst, src);
Did you also add this to disassembler?

https://chromiumcodereview.appspot.com/10831409/diff/1/src/platform-win32.cc
File src/platform-win32.cc (right):

https://chromiumcodereview.appspot.com/10831409/diff/1/src/platform-win32.cc#...
src/platform-win32.cc:59: }
Maybe it's better to throw a compile error here in case windows runs on
non-intel architecture in the future so that we will return to this issue.

https://chromiumcodereview.appspot.com/10831409/diff/1/test/mjsunit/regress/r...
File test/mjsunit/regress/regress-2294.js (right):

https://chromiumcodereview.appspot.com/10831409/diff/1/test/mjsunit/regress/r...
test/mjsunit/regress/regress-2294.js:65: %OptimizeFunctionOnNextCall(setElement)
setElement may be optimized before the first iteration ends, and you wouldn't be
able to test runtime code for several cases. How about inline all setElement
calls and checks into one large test function? You can call that function a
first time to test runtime code, a second time to make sure type information are
in place for optimization, optimize and run a third time to test optimized code.

[ulan, 2012-08-22 13:48:17]

Could you please take another look in src/platform.h?

https://chromiumcodereview.appspot.com/10831409/diff/1/src/arm/macro-assemble...
File src/arm/macro-assembler-arm.cc (right):

https://chromiumcodereview.appspot.com/10831409/diff/1/src/arm/macro-assemble...
src/arm/macro-assembler-arm.cc:3695: vmsr(ip);
On 2012/08/22 07:57:07, Yang wrote:
> Could you use EmitVFPTruncate instead? I'm not entirely sure why it checks for
> VFP exceptions. Maybe you should too. Or you could modify EmitVFPTruncate to
> make the check optional.
The number here is in 0-255 range, so there should be no exceptions.

https://chromiumcodereview.appspot.com/10831409/diff/1/src/ia32/assembler-ia3...
File src/ia32/assembler-ia32.cc (right):

https://chromiumcodereview.appspot.com/10831409/diff/1/src/ia32/assembler-ia3...
src/ia32/assembler-ia32.cc:1947: emit_sse_operand(dst, src);
On 2012/08/22 07:57:07, Yang wrote:
> Did you also add this to disassembler?

Done.

https://chromiumcodereview.appspot.com/10831409/diff/1/src/platform-win32.cc
File src/platform-win32.cc (right):

https://chromiumcodereview.appspot.com/10831409/diff/1/src/platform-win32.cc#...
src/platform-win32.cc:59: }
On 2012/08/22 07:57:07, Yang wrote:
> Maybe it's better to throw a compile error here in case windows runs on
> non-intel architecture in the future so that we will return to this issue.
I moved it to the header file and implemented the correct rounding in the
fallback case.

https://chromiumcodereview.appspot.com/10831409/diff/1/test/mjsunit/regress/r...
File test/mjsunit/regress/regress-2294.js (right):

https://chromiumcodereview.appspot.com/10831409/diff/1/test/mjsunit/regress/r...
test/mjsunit/regress/regress-2294.js:65: %OptimizeFunctionOnNextCall(setElement)
On 2012/08/22 07:57:07, Yang wrote:
> setElement may be optimized before the first iteration ends, and you wouldn't
be
> able to test runtime code for several cases. How about inline all setElement
> calls and checks into one large test function? You can call that function a
> first time to test runtime code, a second time to make sure type information
are
> in place for optimization, optimize and run a third time to test optimized
code.

Done.

[ulan, 2012-08-22 14:08:48]

Thanks! Fixed manual rounding as discussed offline. Landing.