Optimize isFinite and isNaN.

Optimize isFinite and isNaN.

Arithmetic on infinities and NaN is much slower than doing several exact comparisons.

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

[William Hesse, 2011-09-02 13:41:34]

LGTM.

[Sven Panne, 2011-09-02 16:00:14]

http://codereview.chromium.org/7830036/diff/1/src/v8natives.js
File src/v8natives.js (right):

http://codereview.chromium.org/7830036/diff/1/src/v8natives.js#newcode96
src/v8natives.js:96: return !NUMBER_IS_NAN(number) && number !== (1 / 0) &&
number !== (-1 / 0);
!NUMBER_IS_NAN(number) is equivalent to %_IsSmi(%IS_VAR(number)) || (number ==
number), but the double-untag before the cmp-id-and-branch (the compiled
equality check) already does the smi check. Therefore I propose to replace
(every?) !NUMBER_IS_NAN(foo) with (foo === foo). This gains another 5% speed for
issue 1657.

[PhistucK, 2011-09-02 20:24:34]

Can you clarify where it is fine/totally neutral for "const" to be in run time
JavaScript code?

http://codereview.chromium.org/7830036/diff/1/src/v8natives.js
File src/v8natives.js (left):

http://codereview.chromium.org/7830036/diff/1/src/v8natives.js#oldcode43
src/v8natives.js:43: 
I know this code was there already, but see http://crbug.com/80149 - should
"const" be used here (or anywhere in any run time code)?

[Lasse Reichstein, 2011-09-05 10:51:16]

It's never completely free to use const, since we do a runtime call to
initialize the variable, but in the global scope, that should only happen once.
Global code, properly written, won't get optimized, and the global object's
properties aren't treated like normal scoped variables, so for performance this
is the only difference. It won't affect optimization of the functions that can
access the variable.

http://codereview.chromium.org/7830036/diff/1/src/v8natives.js
File src/v8natives.js (left):

http://codereview.chromium.org/7830036/diff/1/src/v8natives.js#oldcode43
src/v8natives.js:43: 
We shouldn't use "const" at all.
The primary reason is that const isn't well-specified, and we might be forced to
change its semantics to match Safari. For that reason, we shouldn't be using it
for security (which is the reason it's used here - someone getting hold of the
builtins object shouldn't be able to change the behavior of internal builtin
functions.
It won't affect performance here, since global variables aren't as bad as local
const variables.
It will be changed, at some point, to not using const, but not for performance
reasons.

http://codereview.chromium.org/7830036/diff/1/src/v8natives.js
File src/v8natives.js (right):

http://codereview.chromium.org/7830036/diff/1/src/v8natives.js#newcode96
src/v8natives.js:96: return !NUMBER_IS_NAN(number) && number !== (1 / 0) &&
number !== (-1 / 0);
That depends a lot on the test.
My, admittedly very artificial, benchmark gets a 20% performance reduction when
I remove the %_IsSmi from the macro.
We can try changing the NUMBER_IS_NAN and NUMBER_IS_FINITE macros and give it a
run at the some benchmarks, but I won't do that in this CL.