Not lgtm.
As discussed in a separate mail thread, I think this is the wrong approach.
This
indicates that there are places in the code where we can't record type
feedback
yet, but those values flow into phis with incompatible feedback. Eg,
var v;
if (bool) {
v = some_double_thats_never_used();
} else {
v = some_smi;
}
if (!bool) { return v + 1; }
This will always deopt in CheckSmi in the first if(bool) branch, since that
double never goes into v+1, but the phi for v does. So we make the phi for
v smi
since v + 1 has only seen smi. And we'll get a t->s change in that branch
even
though it's a double. And we can never learn.
This approach works around it, but it actually does so invalidly. It
converts
the double to a smi to avoid the deopt, but if the value is eg NaN, there
is no
valid smi equivalent. So apart from somehow learning that v+1 should become
double, deopt is the only valid action.
I think the right fix is to record more type feedback. One place where that
should happen is return values of function calls. Another is context
variable
accesses.
https://codereview.chromium.org/163153002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
