Bug 15761 – Speed up JSImmediate::getTruncated* by using custom float -> int code

• Status: RESOLVED
• Resolution: INVALID
• Component: JavaScriptCore

[Eric Seidel (no email)]

Speed up JSImmediate::getTruncated* by using custom float -> int code

I've written some code for this (attached).  It seems to break sun-spider, even though my printf-debugging seems to suggest my code is correct.  Not sure yet what's wrong.  Anyone should feel free to fix/land this as needed, I probably won't get to look at it for several days.

[Eric Seidel (no email)]

Created attachment 16944 [details]
broken fix

[Eric Seidel (no email)]

Created attachment 16956 [details]
nearly correct functions (fail two tests) inside test harness

[Eric Seidel (no email)]

The test output:

Running JSImmediate::getTruncated* tests, this will take a while.
                       testing : -2147483648 : 1000 0000 0000 0000 0000 0000 0000 0000 
getTruncatedUInt32 -0.000000 expected: 0 (1) got: 0 (0)
                       testing : -822083584 : 1100 1111 0000 0000 0000 0000 0000 0000 
getTruncatedInt32  -2147483648.000000 expected: -2147483648 (1) got: -2147483648 (0)

The first failure is obvious.  Not sure if we need to support it (depending on how 0 is stored in JSImmediate floats), probably though.  The second failure seems to be related to exponent size.

[Eric Seidel (no email)]

FYI, in addition to being slightly wrong... this code is also slightly (but only slightly!) slower than the current float -> int code.  I'm confident that both correctness and speed can be fixed, but I'm a bit tired to do so myself.  Perhaps someone will do so while I'm in Mexico.

[Eric Seidel (no email)]

Created attachment 16957 [details]
an actual patch for JSC (same code as in test above)

[Darin Adler]

Oliver got good results by switching our immediate optimization from floating point to int instead.