Skip to content

V
V8
Switch branch/tag
  1. 18 Apr, 2019 1 commit
  3. 06 Mar, 2019 1 commit
    • Yu Yin's avatar
      [mips][builtin] Improve CallApiCallback calling convention. · d9b59c7d
      Yu Yin authored 
      Port https://crrev.com/c/1469821

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).

Change-Id: Ice52b68678fbea69e765c22daa3134524860e5de
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1505234Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarPredrag Rudic <prudic@wavecomp.com>
Commit-Queue: Yu Yin <xwafish@gmail.com>
Cr-Commit-Position: refs/heads/master@{#60049}
      d9b59c7d
  5. 01 Mar, 2019 1 commit
  7. 17 Jan, 2019 1 commit
  9. 15 Jan, 2019 1 commit
  11. 14 Jan, 2019 1 commit
    • Predrag Rudic's avatar
      MIPS[64] Fix floating point register allocation · ff7ced51
      Predrag Rudic authored 
      Failure to make snapshot in debug mode on MIPS was caused by bad
floating point register allocation for function parameters. According to
MIPS convention, floating point parameters  cannot be stored on odd
numbered floating point register. Which was the case (f7 was allocated).
This patch ensures that f12 and f14 are used for storing fp parameters.

To be able to determine types of parameters in InitializePlatformSpecific
method, InitializePlatformIndependent has to be executed first.
InitializePlatformIndependent requires number of parameters in arguments.
That is the reason for changing definitions of CompareDescriptor and
BinaryDescriptor classes.

Change-Id: I7d723e03385f756114df60e33798400e97d99d8f
Reviewed-on: https://chromium-review.googlesource.com/c/1400415Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Predrag Rudic <prudic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#58768}
      ff7ced51
  13. 19 Dec, 2018 1 commit
  15. 04 Dec, 2018 1 commit
    • Jakob Gruber's avatar
      [nojit] Refactor CallApiCallback calling convention · c6b0e12e
      Jakob Gruber authored 
      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.

Drive-by: The implementation is now mostly consistent across platforms.
Drive-by: Refactor the calling convention to free up two registers
(kCallData and kHolder are now passed on the stack).

Bug: v8:7777
Change-Id: I212dccc2930de89c264a13755918c9fae7842f1f
Reviewed-on: https://chromium-review.googlesource.com/c/1354887
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58005}
      c6b0e12e
  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. 25 May, 2018 1 commit
  43. 07 May, 2018 1 commit
    • jgruber's avatar
      [builtins] Convert CEntry/GetProperty/StringAdd stubs to builtins · d8131cd6
      jgruber authored 
      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.

TBR=mlippautz@chromium.org

Bug: v8:6666
Change-Id: I4cd63477f19a330ec70bbf20e2af8a42fb05fabb
Reviewed-on: https://chromium-review.googlesource.com/1044245Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53027}
      d8131cd6
  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. 12 Feb, 2018 1 commit
    • Ross McIlroy's avatar
      [Ignition] [TurboFan] Generate speculation poison in code generator. · a021b6c4
      Ross McIlroy authored 
      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.

BUG=chromium:798964

Change-Id: I2a3d0cfc694e88d7a8fe893282bd5082f693d5e2
Reviewed-on: https://chromium-review.googlesource.com/893160
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51229}
      a021b6c4
  51. 29 Jan, 2018 1 commit
  53. 21 Dec, 2017 1 commit
  55. 14 Dec, 2017 1 commit
  57. 16 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. 05 Sep, 2017 1 commit
  69. 01 Sep, 2017 1 commit
  71. 25 Aug, 2017 1 commit
    • Ross McIlroy's avatar
      [Interpreter] Adapt Call bytecode handlers to drop their stack-frame. · 51a15140
      Ross McIlroy authored 
      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.

BUG=chromium:753705

Change-Id: I23328e4cef878df3aca4db763b47d72a2cce664c
Reviewed-on: https://chromium-review.googlesource.com/634364
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47617}
      51a15140
  73. 24 Aug, 2017 1 commit
  75. 15 Aug, 2017 1 commit
  77. 07 Aug, 2017 1 commit
    • Benedikt Meurer's avatar
      [ic] Properly integrate the CallIC into Ignition. · ee350c31
      Benedikt Meurer authored 
      Drop the deprecated CallConstructStub and remove the use of CallICStub
from fullcodegen, since that feedback is unused completely every since
Crankshaft got removed, thus we can safely unlink all the CallIC stuff
from fullcodegen nowadays, and completely nuke the CallICStub and the
CallICTrampolineStub now (we can also transitively nuke the unused
CreateAllocationSiteStub and CreateWeakCellStub).

Instead the CallIC logic is integrated into Ignition now, and part of
the bytecode handlers for [[Call]] and [[Construct]]. There's still some
follow-up cleanup with the way the Array constructor feedback is
integrated, but that's way easier now.

Bug: v8:5517, v8:6399, v8:6409, v8:6679
Change-Id: I0a6c6046faceca9b1606577bc9e63d9295e44619
Reviewed-on: https://chromium-review.googlesource.com/603609
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47196}
      ee350c31