Skip to content

V
V8
Switch branch/tag
  1. 16 Dec, 2020 3 commits
  3. 02 Dec, 2020 1 commit
  5. 01 Dec, 2020 1 commit
    • Ross McIlroy's avatar
      [Turboprop] Move deoptimizations for dynamic map checks into builtin. · b6643320
      Ross McIlroy authored 
      In order to reduce the codegen size of dynamic map checks, add the
ability to have an eager with resume deopt point, which can call
a given builitin to perform a more detailed check than can be done
in codegen, and then either deoptimizes itself (as if the calling
code had performed an eager deopt) or resumes execution in the
calling code after the check.

In addition, support for adding extra arguments to a
deoptimization continuation is added to enable us to pass the
necessary arguments to the DynamicMapChecks builtin.

Finally, a trampoline is added to the DynamicMapChecks which saves
the registers that might be clobbered by that builtin, to avoid
having to save them in the generated code. This trampoline also
performs the deoptimization based on the result of the
DynamicMapChecks builtin.

In order to ensure both the trampoline and DynamicMapChecks
builtin have the same call interface, and to limit the number
of registers that need saving in the trampoline, the
DynamicMapChecks builtin is moved to be a CSA builtin with a
custom CallInterfaceDescriptor, that calls an exported Torque
macro that implements the actual functionality.

All told, this changes the codegen for a monomorphic dynamic
map check from:
    movl rbx,<expected_map>
    cmpl [<object>-0x1],rbx
    jnz <deferred_call>
   resume_point:
    ...
   deferred_call:
    <spill registers>
    movl rax,<slot>
    movq rbx,<object>
    movq rcx,<handler>
    movq r10,<DynamicMapChecks>
    call r10
    cmpq rax,0x0
    jz <restore_regs>
    cmpq rax,0x1
    jz <deopt_point_1>
    cmpq rax,0x2
    jz <deopt_point_2>
    int3l
   restore_regs:
    <restore_regs>
    jmp <resume_point>
    ...
   deopt_point_1:
    call Deoptimization_Eager
   deopt_point_2:
    call Deoptimization_Bailout

To: movl rax,<slot>
    movl rcx,<expected_map>
    movq rdx,<handler>
    cmpl [<object>-0x1],rcx
    jnz <deopt_point>
   resume_point:
    ...
   deopt_point:
    call DynamicMapChecksTrampoline
    jmp <resume_point>

BUG=v8:10582

Change-Id: Ica4927b9acc963b9b73dc62d9379a7815335650f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2560197
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71545}
      b6643320
  7. 12 Nov, 2020 1 commit
  9. 23 Oct, 2020 1 commit
  11. 19 Oct, 2020 1 commit
  13. 05 Oct, 2020 1 commit
    • Sathya Gunasekaran's avatar
      [turboprop] Inline monomorphic map check · 2cf6ee0b
      Sathya Gunasekaran authored 
      Instead of loading the map from the feedback vector for monomorphic
access, this CL directly inlines the expected map constant as a static
check.

In case this static check fails, we call out to a builtin which performs
additional dynamic map checks.

There are several dynamic map checks performed by the builtin for various
cases such as:
(a) IC is monomorphic with a map that's different from the initial
static map that we checked, in which case we perform another dynamic
map check.
(b) IC is monomorphic but incoming map is a deprecated map in which case
we call out the runtime to migrate this incoming object to a new map and
then try to handle it.
(c) IC has now transitioned to polymorphic in which we use the old
dynamic polymorphic checks to validate the map and handler.

Bug: v8:10582, v8:9684
Change-Id: Id87265ed513e4aef87b8e66c826afbf10f50a1d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2429034
Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70304}
      2cf6ee0b
  15. 29 Sep, 2020 1 commit