Skip to content

V
V8
Switch branch/tag
  1. 10 Sep, 2015 3 commits
    • chunyang.dai's avatar
      X87: [calls] Consistent call protocol for calls. · 99f01307
      chunyang.dai authored 
      port b37907ff (r30648).

original commit message:

    The number of actual arguments should always be available, there's no
    point in trying to optimize away a simple assignment of an immediate to
    a register before some calls.

    The main motivation is to have a consistent state at the beginning of every
    function. Currently the arguments register (i.e. rax or eax) either contains
    the number of arguments or some random garbage depending on whether
    the callsite decided that the callee might need the information or not.
    This causes trouble with runtime implementations of functions that
    do not set internal_formal_parameter_count to the DontAdaptArguments
    sentinel (we don't have any of those yet), but also makes it impossible
    to sanity check the arguments in the callee, because the callee doesn't
    know whether the caller decided to pass the number of arguments or
    random garbage.

BUG=

Review URL: https://codereview.chromium.org/1335453002

Cr-Commit-Position: refs/heads/master@{#30669}
      99f01307
    • chunyang.dai's avatar
      X87: [builtins] Unify the various versions of [[Call]] with a Call builtin. · 20c9749b
      chunyang.dai authored 
      port ccbb4ff0 (r30629)

original commit message:

    The new Call and CallFunction builtins supersede the current
    CallFunctionStub (and CallIC magic) and will be the single bottleneck
    for all calling, including the currently special Function.prototype.call
    and Function.prototype.apply builtins, which had handwritten (and
    not fully compliant) versions of CallFunctionStub, and also the
    CallIC(s), which where also slightly different.

    This also reduces the overhead for API function calls, which is still
    unnecessary high, but let's do that step-by-step.

    This also fixes a bunch of cases where the implicit ToObject for
    sloppy receivers was done in the wrong context (in the caller
    context instead of the callee context), which basically meant
    that we allowed cross context access to %ObjectPrototype%.

BUG=

Review URL: https://codereview.chromium.org/1332703002

Cr-Commit-Position: refs/heads/master@{#30668}
      20c9749b
    • chunyang.dai's avatar
      X87: [runtime] Replace many buggy uses of %_CallFunction with %_Call. · 0cfa52d0
      chunyang.dai authored 
      port db2ba190 (r30634).

original commit message:

    The semantics of the %_CallFunction intrinsic seem to be very unclear,
    which resulted in a lot of bugs. Especially the combination with
    %IsSloppyModeFunction is always a bug, because the receiver would be
    wrapped in the wrong context. So the %IsSloppyModeFunction helper is
    gone now, and many of the buggy uses of %_CallFunction are also
    eliminated.

    If you ever need to call something with a different receiver, then
    %_Call is your friend now. It does what you want and implements the
    call sequence fully (and correct).

Review URL: https://codereview.chromium.org/1336443002

Cr-Commit-Position: refs/heads/master@{#30667}
      0cfa52d0
  3. 09 Sep, 2015 19 commits
  5. 08 Sep, 2015 18 commits