Skip to content

V
V8
Switch branch/tag
  1. 26 Apr, 2019 1 commit
  3. 25 Apr, 2019 1 commit
  5. 24 Apr, 2019 1 commit
  7. 18 Apr, 2019 1 commit
  9. 16 Apr, 2019 1 commit
  11. 11 Apr, 2019 1 commit
  13. 09 Apr, 2019 1 commit
  15. 08 Apr, 2019 1 commit
  17. 01 Apr, 2019 1 commit
  19. 28 Mar, 2019 2 commits
  21. 27 Mar, 2019 1 commit
  23. 25 Mar, 2019 2 commits
  25. 22 Mar, 2019 1 commit
  27. 18 Mar, 2019 1 commit
  29. 15 Mar, 2019 1 commit
  31. 14 Mar, 2019 1 commit
  33. 12 Mar, 2019 1 commit
  35. 11 Mar, 2019 1 commit
  37. 08 Mar, 2019 1 commit
  39. 05 Mar, 2019 1 commit
  41. 01 Mar, 2019 1 commit
  43. 28 Feb, 2019 1 commit
    • Tom Tan's avatar
      Move Assembler::AbortedCodeGeneration() from .h to .cc for arm64 · 75d972a6
      Tom Tan authored 
      Assembler::AbortedCodeGeneration() is defined in assembler-arm64.h, but it calls
into Constant::Clear() which is defined in assembler-arm64.cc. This introduces
dependency to v8_base component when including assembler-arm64.h which is not
always possible like for V8 unittests target. To fix this, we could define both
in the same file, like Assembler::IsConstPoolEmpty() calls Constant::Clear() and
both are defined in assembler-arm64.h, so it works fine.

Bug: chromium:893460
Change-Id: I895cf0147950fca20142ea5ed18bcd020c1ab866
Reviewed-on: https://chromium-review.googlesource.com/c/1493293Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59955}
      75d972a6
  45. 25 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [objects] Free one bit in the SharedFunctionInfo::flags. · 591408cb
      Benedikt Meurer authored 
      We'll need one bit in the SharedFunctionInfo::flags to record whether
it's safe to skip arguments adaptor frames (for v8:8895), so this
just removes the SharedFunctionInfo::IsDerivedConstructorBit which is
redundant, since the same information is already available in the
SharedFunctionInfo::FunctionKindBits, and most places in the code
use that already, with the exception of the JSConstructStubGeneric
builtin.

This changes the JSConstructStubGeneric builtin to just check the
function kind instead of testing the explicit bit, which also makes
this more consistent. It seems like there's not much overhead to
that, doing an additional bitmasking plus two comparisons instead
of one. This shouldn't really matter since invocation and execution
of the constructors is going to dominate and optimized code inlines
all of this anyways. If this turns out to affect performance, we
can still look into encoding the FunctionKindBits more cleverly.

Drive-by-fix: Move the FunctionKindBits first in the flags to avoid
the shift when accessing the function kind. This seems logic, since
for the actual boolean bit fields it doesn't matter where they are
in the flags, whereas for the function kind this saves one shift.

Bug: v8:8834, v8:8895
Change-Id: I184a8f5cc5c140bdc272cf9a5ad546093c457306
Reviewed-on: https://chromium-review.googlesource.com/c/1482915Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59821}
      591408cb
  47. 22 Feb, 2019 1 commit
    • Jon Kunkee's avatar
      Move ARM64 Assembler::nop definition from header to source file · 7803fa68
      Jon Kunkee authored 
      When Assembler::nop is in the header, it is considered an inline
function. With GN arg is_component_build=true, the V8_EXPORT_PRIVATE
mark on the class causes it to be exported every time the header is
included. This, in turn, produces a reference to
Register::XRegFromCode.

Register::XRegFromCode is only ever defined as an inlined function, so
that reference is never fulfilled.

Clang can avoid this using the /Fc:dllexportInlines- flag to suppress
the export of Assembler::nop and so avoid generating the reference to
Register::XRegFromCode.

MSVC does not support this flag, so this change suppresses the export
by moving Assembler::nop's definition to the .cc file. This also allows
it to use the inline definition of Register::XRegFromCode.

Bug: v8:8870
Change-Id: I1cd33195677256c9dd06c7047fe84e1b912d3151
Reviewed-on: https://chromium-review.googlesource.com/c/1478216Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59785}
      7803fa68
  49. 21 Feb, 2019 1 commit
    • Tom Tan's avatar
      [Win][ARM64] Fix shift mask constant for LLP64 · 8dea08e8
      Tom Tan authored 
      Windows ARM64 does cross build for V8 and runs snapshot tool on build host
under simulator. Simulator is built with LLP64 data model so 0xFFFFL is 32-bit
long by default. It causes problem for the expression "0xFFFFL << shift" when
shift is 32, which actually does nothing on x64 because 0xFFFFL is only 32-bit.
The issue happens for instruction "movk rd, NUM lsl 32" which is simulated in

Simulator::VisitMoveWideImmediate. "0xFFFL << shift" acts as mask to clear bits
32-47 of the orignal value in rd. Under LLP64, the mask happens unexpectedly to
the lowest 16 bits of rd register and corrupts the result of rd. Specify 0xFFFFL
as 64 bit as 0xFFFFLL fixes this problem.

Bug: chromium:893460
Change-Id: Ibd911ce595e83637432a3e1f79a9bf28fcbe09f6
Reviewed-on: https://chromium-review.googlesource.com/c/1475330
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59778}
      8dea08e8
  51. 19 Feb, 2019 1 commit
  53. 18 Feb, 2019 2 commits
  55. 15 Feb, 2019 1 commit
  57. 14 Feb, 2019 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce a CallFunctionTemplate builtin. · a2d9924c
      Benedikt Meurer authored 
      When calling into API callbacks from TurboFan optimized, we can
currently only take a fast-path when TurboFan is able to find some
information about the receiver in the graph, or when the API callback
specifies that it neither requires an access check (aka "accepts any
receiver") nor an interface check (aka "compatible receiver check").

This change introduces a new CallFunctionTemplate builtin that sits
in front of the CallApiCallback builtin and does both the access as well
as the interface check as necessary (and raises appropriate exceptions).
This way TurboFan can still call into the API callback via the fast-path
even without ahead knowledge about the receiver, which is significantly
faster than the generic call machinery for API callbacks.

On the test case from the Angular team[1], the interesting metrics
improve from

  DOM_mono: 0.273 ms
  DOM_mega: 0.571 ms
  DOM_call: 0.649 ms

to

  DOM_mono: 0.264 ms
  DOM_mega: 0.572 ms
  DOM_call: 0.368 ms

so the DOM_call is only about **1.4 times slower** than the DOM_mono and
about **1.5 times faster** than the DOM_mega case (compared to **2.4
times slower**). Execution time in the DOM_call was reduced by around
**~45%**.

Currently this new code path is limited to TurboFan optimized code, but
the idea is to eventually migrate the API calls from baseline to also
use the new CSA functionality, but there are lot's of subleties to take
into account, so starting with small changes to get coverage for the
basic building blocks.

[1]: https://mhevery.github.io/perf-tests/DOM-megamorphic.html

Bug: v8:8820
Change-Id: Ie1029cf182ce05a6e519fd9a9d4fa825db8adb4c
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Reviewed-on: https://chromium-review.googlesource.com/c/1470129
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59598}
      a2d9924c
  59. 13 Feb, 2019 2 commits
  61. 12 Feb, 2019 1 commit
  63. 11 Feb, 2019 2 commits
  65. 07 Feb, 2019 2 commits
    • Sigurd Schneider's avatar
      [cleanup] Move Code class out of objects.cc · 0c20a4c6
      Sigurd Schneider authored 
      Drive-by: Refactor FlushInstructionCache to its own header. This removes
dependencies of objects.cc and code.cc

Bug: v8:8562
Change-Id: If23f3b9d4f2068e08c61c0f4b070ecfe1b9a6cc0
Reviewed-on: https://chromium-review.googlesource.com/c/1456081Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59435}
      0c20a4c6
    • deepak1556's avatar
      DISALLOW_IMPLICIT_CONSTRUCTORS for MacroAssembler · 9e060e47
      deepak1556 authored 
      When BUILDING_V8_SHARED in release builds __declspec(dllexport)
causes generation of implicit constructors in the forwarding class
while its deleted in TurboAssemblerBase, which leads to compilation
errors like:

In file included from gen/v8/v8_base_jumbo_6.cc:41:
In file included from .\../../v8/src/interface-descriptors.cc:7:
In file included from ../../v8\src/macro-assembler.h:40:
../../v8\src/x64/macro-assembler-x64.h(92,9):  error: call to deleted constructor of 'v8::internal::TurboAssemblerBase'
      : TurboAssemblerBase(std::forward<Args>(args)...) {}
        ^                  ~~~~~~~~~~~~~~~~~~~~~~~~
../../v8\src/x64/macro-assembler-x64.h(536,25):  note: in instantiation of function template specialization 'v8::internal::TurboAssembler::TurboAssembler<v8::internal::TurboAssembler>' requested here
class V8_EXPORT_PRIVATE MacroAssembler : public TurboAssembler {
                        ^
../../v8\src/turbo-assembler.h(127,34):  note: 'TurboAssemblerBase' has been explicitly marked deleted here
  DISALLOW_IMPLICIT_CONSTRUCTORS(TurboAssemblerBase);
                                 ^
1 error generated.

The original changes were made in https://chromium-review.googlesource.com/c/v8/v8/+/1414913

R=mstarzinger@chromium.org,jgruber@chromium.org,clemensh@chromium.org

Bug: NONE
Change-Id: I87a5a678b8bae13b3adc6f1c6ac0b9313ed18d85
Reviewed-on: https://chromium-review.googlesource.com/c/1454676
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59427}
      9e060e47
  67. 06 Feb, 2019 1 commit