Skip to content

V
V8
Switch branch/tag
  1. 01 Apr, 2019 1 commit
  3. 26 Mar, 2019 1 commit
  5. 25 Mar, 2019 1 commit
  7. 15 Feb, 2019 1 commit
    • Junliang Yan's avatar
      PPC/s390: [builtins] Improve CallApiCallback calling convention. · 81bb8aed
      Junliang Yan authored 
      Port c142e0a2

Original Commit Message:

    Refactor the CallApiCallback builtin to

    - pass the context as with other stubs, and
    - pass holder and call data in registers.

    This avoids having to place holder and call data onto the stack, and
    thus makes it possible to easily call the CallApiCallback builtin from
    other builtins while just forwarding the (stack) arguments. The idea
    is to use this in the future to optimize the general case of calling
    into any API method via a FunctionTemplateInfo and doing appropriate
    security and/or interface checks upfront as necessary (eventually making
    the HandleApiCall C++ builtin obsolete at some point).

R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com, miladfar@ca.ibm.com
BUG=
LOG=N

Change-Id: I94583d1e0fa7c4696e628c363fefe273c8c5cab9
Reviewed-on: https://chromium-review.googlesource.com/c/1475331Reviewed-by: 's avatarMilad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#59633}
      81bb8aed
  9. 13 Feb, 2019 1 commit
    • Junliang Yan's avatar
      PPC/s390: [builtins] Improve CallApiCallback calling convention. · 421cf613
      Junliang Yan authored 
      Port c142e0a2

Original Commit Message:

    Refactor the CallApiCallback builtin to

    - pass the context as with other stubs, and
    - pass holder and call data in registers.

    This avoids having to place holder and call data onto the stack, and
    thus makes it possible to easily call the CallApiCallback builtin from
    other builtins while just forwarding the (stack) arguments. The idea
    is to use this in the future to optimize the general case of calling
    into any API method via a FunctionTemplateInfo and doing appropriate
    security and/or interface checks upfront as necessary (eventually making
    the HandleApiCall C++ builtin obsolete at some point).

R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: Ic6c246bb28a6affa6fe015c1207c773b375a2b30
Reviewed-on: https://chromium-review.googlesource.com/c/1470443Reviewed-by: 's avatarMilad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#59562}
      421cf613
  11. 17 Jan, 2019 1 commit
  13. 19 Dec, 2018 1 commit
  15. 04 Dec, 2018 1 commit
    • Junliang Yan's avatar
      PPC/s390: [nojit] Refactor CallApiCallback calling convention · a31338aa
      Junliang Yan authored 
      Port c6b0e12e

Original Commit Message:

    This is the first (and major) step towards converting CallApiCallback
    and CallApiGetter stubs into builtins.

    The CallApiCallbackStub was parameterized with the number of arguments
    passed on the stack. This CL converts the compile-time parameter into
    an explicit runtime parameter, and removes all uses of the stub
    parameter.

    (kCallData and kHolder are now passed on the stack).

R=jgruber@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I171fbb7d37525c2087e5dd9d7ff8fb5f959f2a7a
Reviewed-on: https://chromium-review.googlesource.com/c/1362163Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#58030}
      a31338aa
  17. 30 Nov, 2018 1 commit
  19. 19 Nov, 2018 1 commit
  21. 31 Aug, 2018 1 commit
  23. 29 Aug, 2018 1 commit
  25. 28 Aug, 2018 1 commit
  27. 22 Aug, 2018 1 commit
  29. 22 Jun, 2018 1 commit
  31. 21 Jun, 2018 2 commits
  33. 18 Jun, 2018 1 commit
  35. 12 Jun, 2018 1 commit
  37. 07 Jun, 2018 1 commit
  39. 30 May, 2018 1 commit
  41. 28 May, 2018 1 commit
  43. 08 May, 2018 1 commit
    • Junliang Yan's avatar
      PPC/s390: [builtins] Convert CEntry/GetProperty/StringAdd stubs to builtins · 7ff35bd5
      Junliang Yan authored 
      Port d8131cd6

Original Commit Message:

    Stubs and builtins are very similar. The main differences are that
    stubs can be parameterized and may be generated at runtime, whereas
    builtins are generated at mksnapshot-time and shipped with the snapshot
    (or embedded into the binary).

    My main motivation for these conversions is that we can generate
    faster calls and jumps to (embedded) builtins callees from (embedded)
    builtin callers. Instead of going through the builtins constants table
    indirection, we can simply do a pc-relative call/jump.

    This also unlocks other refactorings, e.g. removal of
    CallRuntimeDelayed.

R=jgruber@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I193e4275470d492912a7d0f8523c3b8c29f1b146
Reviewed-on: https://chromium-review.googlesource.com/1050732
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#53081}
      7ff35bd5
  45. 03 May, 2018 1 commit
  47. 22 Feb, 2018 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Introduce a dedicated FeedbackCell. · aff1f378
      Benedikt Meurer authored 
      This is preparatory cleanup work for eventually tracking the functions
(rather than concrete closures) in the CALL_IC, also for builtins like
the default PromiseCapability [[Resolve]] and [[Reject]] functions. It
adds a new FeedbackCell type, which is used by JSFunctions consistently
now to reference the feedback vector (or undefined if not the function
is not compiled yet or is a native/asm.js function).

This also changes the calling convention for FastNewClosure builtin and
the JSCreateClosure operator in TurboFan to carry the FeedbackCell here
instead of the parent FeedbackVector and the slot index. In addition we
eliminate the now unused %InterpreterNewClosure runtime function.

Bug: v8:2206, v8:7253, v8:7310
Change-Id: Ib4ce456e276e0273e57c163dcdd0b33abf863656
Reviewed-on: https://chromium-review.googlesource.com/928403
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51474}
      aff1f378
  49. 13 Feb, 2018 1 commit
    • Junliang Yan's avatar
      PPC/s390: [Ignition] [TurboFan] Generate speculation poison in code generator. · abac06aa
      Junliang Yan authored 
      Port a021b6c4

Original Commit Message:

    Moves generation of speculation poison to be based on the PC target vs the
    actual PC being executed. The speculation poison is generated in the prologue
    of the generated code if CompilationInfo::kGenerateSpeculationPoison is set.
    The result is stored in a known register, which can then be read using the
    SpeculationPoison machine node.

    Currently we need to ensure the SpeculationPoison node is scheduled right after
    the code prologue so that the poison register doesn't get clobbered. This is
    currently not verified, however it's only use is in RawMachineAssembler where
    it is manually scheduled early.

    The Ignition bytecode handlers are updated to use this speculation poison
    rather than one generated by comparing the target bytecode.

R=rmcilroy@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:798964
LOG=N

Change-Id: I4b9a1b0865b6164171cf83f0e45c36c69ac08a18
Reviewed-on: https://chromium-review.googlesource.com/914848Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#51273}
      abac06aa
  51. 31 Jan, 2018 1 commit
  53. 21 Dec, 2017 1 commit
  55. 14 Dec, 2017 1 commit
  57. 22 Nov, 2017 1 commit
  59. 30 Oct, 2017 1 commit
  61. 25 Oct, 2017 1 commit
  63. 13 Oct, 2017 1 commit
  65. 25 Sep, 2017 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Properly optimize literals in inlined functions. · 855b88ae
      Benedikt Meurer authored 
      When inlining based on SharedFunctionInfo rather than based on concrete
JSFunction, we weren't able to properly optimize array, object and
regexp literals inside the inlinee, because we didn't know the concrete
FeedbackVector for the inlinee inside JSCreateLowering. This was because
JSCreateLowering wasn't properly updated after the literals moved to the
FeedbackVector. Now with this CL we also have the VectorSlotPair on the
literal creation operators, just like we do for property accesses and
calls, and are thus able to always access the appropriate FeedbackVector
and optimize the literal creation.

The impact is illustrated by the micro-benchmark on the tracking bug,
which goes from

  createEmptyArrayLiteral: 1846 ms.
  createShallowArrayLiteral: 1868 ms.
  createShallowObjectLiteral: 2246 ms.

to

  createEmptyArrayLiteral: 1175 ms.
  createShallowArrayLiteral: 1187 ms.
  createShallowObjectLiteral: 1195 ms.

with this CL, so up to 2x faster now.

Drive-by-fix: Also remove the unused CreateEmptyObjectLiteral builtin
and cleanup the names of the other builtins to be consistent with the
names of the TurboFan operators and Ignition bytecodes.

Bug: v8:6856
Change-Id: I453828d019b27c9aa1344edac0dd84e91a457097
Reviewed-on: https://chromium-review.googlesource.com/680656
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48140}
      855b88ae
  67. 06 Sep, 2017 1 commit
    • Anisha Rohra's avatar
      s390/PPC: Remove InterpreterExitTrampoline. · 40c98daa
      Anisha Rohra authored 
      Port 30f08f39

  Always return to the InterpreterEntryTrampoline rather than calling the
  InterpreterExitTrampoline from the Return bytecode handler. This fixes a
  regression which occured if we upset the call/return stack by skipping the
  return to the InterpreterEntryTrampoline from the return bytecode handler.

R=bjaideep@ca.ibm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: Id2bae444e72cd7ddfb74f4861fc2c4f7b5e9bda5
Reviewed-on: https://chromium-review.googlesource.com/653618Reviewed-by: 's avatarJaideep Bajwa <bjaideep@ca.ibm.com>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#47858}
      40c98daa
  69. 01 Sep, 2017 1 commit
  71. 29 Aug, 2017 1 commit
    • Jaideep Bajwa's avatar
      PPC/s390: [Interpreter] Adapt Call bytecode handlers to drop their stack-frame. · e5b93bd5
      Jaideep Bajwa authored 
      Port 51a15140

Original Commit Message:

    This change adapts the Call bytecode handlers such that they don't require
    a stack frame. It does this by modifying the call bytecode handler to
    tail-call the Call or InterpreterPushArgsAndCall builtins. As a result, the
    callee function will return to the InterpreterEntryTrampoline when it returns
    (since this is the return address on the interpreter frame), which is
    adapted to dispatch to the next bytecode handler. The return bytecode
    handler is modified to tail-call a new InterpreterExitTramoline instead
    of returning to the InterpreterEntryTrampoline.

    Overall this significanlty reduces the amount of stack space required for
    interpreter frames, increasing the maximum depth of recursive calls from
    around 6000 to around 12,500 on x64.

R=rmcilroy@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=chromium:753705
LOG=N

Change-Id: Ieac490d82098c13741080061eda762d54baf8c04
Reviewed-on: https://chromium-review.googlesource.com/639315Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#47694}
      e5b93bd5
  73. 24 Aug, 2017 1 commit
  75. 15 Aug, 2017 1 commit
  77. 08 Aug, 2017 1 commit