Bug 15617 – improve speed of integer conversions

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Darin Adler]

I was able to get a 1% speedup on SunSpider by eliminating an unnecessary float/double conversion.

[Darin Adler]

Created attachment 16798 [details]
patch with change log

[Mark Rowe (bdash)]

This looks nearly identical to Eric's patch on bug 15607.

[Darin Adler]

I have a better version in the works.

[Darin Adler]

Created attachment 16802 [details]
patch with change log

[Darin Adler]

Created attachment 16803 [details]
patch with change log (newer version with fixed .exp file)

[Eric Seidel (no email)]

Comment on attachment 16803 [details]
patch with change log (newer version with fixed .exp file)

Looks great.  I assume you ran the tests.  Also, (pot calling the kettle black here) I think it would be nice to replace all your float special values 4294967296.0, etc with some nice names (to make the code make sense to someone who didn't just hack on it for a couple hours. :)  (Also, nice catch with toInt32SlowCase calling toUInt32.  I'm curious if that would ever be "wrong" (such that we could build a test).  I guess it just changes what values could be stored in the float, since it's just doing the sign wrap at a different time.

[Darin Adler]

(In reply to comment #6)
> (Also, nice catch with
> toInt32SlowCase calling toUInt32.  I'm curious if that would ever be "wrong"
> (such that we could build a test).

It wasn't wrong in the sense of "buggy". It was just inefficient for negative numbers.

[Darin Adler]

(In reply to comment #6)
> I think it would be nice to replace all your float special values
> 4294967296.0, etc with some nice names (to make the code make sense to someone
> who didn't just hack on it for a couple hours. :)

I'll consider that. I'm worried that if I use const double or const float that it will generate different code, so it's a change I need to make carefully with measurements.