Optimize Function.prototype.call

Optimize Function.prototype.call

BUG=
R=verwaest@chromium.org, jkummerow@chromium.org

[p.antonov, 2014-06-24 14:46:44]

PTAL, expression stack management should be fine now.

[Jarin, 2014-06-24 21:27:32]

On 2014/06/24 14:46:44, p.antonov wrote:
> PTAL, expression stack management should be fine now.

Handling of deoptimization is still wrong. For example, the program below should
not do anything, but it gives an error:

Array.prototype.f = function() {
  return 0;
};

function g(x, y) { }

function f(deopt) {
  g([].f.call({}), deopt + 1);
}

f(0);
f(0);
%OptimizeFunctionOnNextCall(f);
f({});


Here is the result:

$ out/ia32.debug/d8 --allow-natives-syntax c.js
c.js:8: TypeError: undefined is not a function
  g([].f.call({}), deopt + 1);
                         ^
TypeError: undefined is not a function
    at f (c.js:8:26)
    at c.js:14:1


With --nocrankshaft, everything is working as expected (no output).

[Jarin, 2014-06-25 07:45:41]

I should also add that we would like to see more test coverage for
deoptimization before we accept such a patch. Deoptimization problems are
notoriously tricky to debug, and they are often exploitable. Inlining is
especially tricky because it involves combined stack frames - this has been a
source of subtle bugs in the past.

Ideally, deoptimization tests should try to deoptimize for every simulate that
your change has affected or introduced (both for the inlining and non-inlining
case).