DFG int-to-double conversion should be revealed to CSE

[Filip Pizlo]

Currently if we have an integer variable, like:

var x = 1;

And we use it in multiple places in a context that requires conversion to double, like:

... = x * 0.5;
... = sqrt(x);

Then we will convert it to double on each of those uses.  That's wasteful, and we should be able to remember that the conversion had already been performed by separately tracking the converted-to-double version of the value.

We have an even more gross problem if we do the following:

var x = o.f; // o.f predicted int
... = x * 0.5;
... = array[x];

The first statement will format x as a JSValue.  The second statement will speculate that x is a number and convert it to a double in-place. The third statement will then end up doing horrible slow things to try to perform an array access using a double as an index.

Again, if we had a way of separately tracking the converted-to-double form of this integer variable, this would not be a problem.

[Filip Pizlo]

Created attachment 133653 [details]
work in progress

[Filip Pizlo]

Created attachment 133657 [details]
work in progress

I'm almost ready to start testing it...

[Filip Pizlo]

Created attachment 133668 [details]
the patch

[Filip Pizlo]

Created attachment 133673 [details]
the patch

Rebased patch.

[Early Warning System Bot]

Comment on attachment 133673 [details]
the patch

Attachment 133673 [details] did not pass qt-wk2-ews (qt):
Output: http://queues.webkit.org/results/12129342

[Early Warning System Bot]

Comment on attachment 133673 [details]
the patch

Attachment 133673 [details] did not pass qt-ews (qt):
Output: http://queues.webkit.org/results/12134270

[Filip Pizlo]

(In reply to comment #6)
> (From update of attachment 133673 [details])
> Attachment 133673 [details] did not pass qt-ews (qt):
> Output: http://queues.webkit.org/results/12134270

Ooops, I need to write the 32-bit version of compileInt32ToDouble. :-(

[Filip Pizlo]

Created attachment 133695 [details]
the patch

Fix 32-bit.

[Gyuyoung Kim]

Comment on attachment 133695 [details]
the patch

Attachment 133695 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/12134479

[Philippe Normand]

Comment on attachment 133695 [details]
the patch

Attachment 133695 [details] did not pass gtk-ews (gtk):
Output: http://queues.webkit.org/results/12129524

[Filip Pizlo]

(In reply to comment #9)
> (From update of attachment 133695 [details])
> Attachment 133695 [details] did not pass efl-ews (efl):
> Output: http://queues.webkit.org/results/12134479

Fix on the way ... it appears that in the process of moving #if's around, I broke 64-bit.

[Build Bot]

Comment on attachment 133695 [details]
the patch

Attachment 133695 [details] did not pass mac-ews (mac):
Output: http://queues.webkit.org/results/12131501

[Filip Pizlo]

Created attachment 133696 [details]
the patch

Putting up for EWS.

[Filip Pizlo]

Landed in http://trac.webkit.org/changeset/112040