Skip to content

V
V8
Switch branch/tag
  1. 12 Mar, 2019 1 commit
  3. 11 Mar, 2019 1 commit
  5. 08 Mar, 2019 1 commit
  7. 05 Mar, 2019 1 commit
  9. 01 Mar, 2019 1 commit
  11. 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
  13. 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
  15. 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
  17. 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
  19. 19 Feb, 2019 1 commit
  21. 18 Feb, 2019 2 commits
  23. 15 Feb, 2019 1 commit
  25. 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
  27. 13 Feb, 2019 2 commits
  29. 12 Feb, 2019 1 commit
  31. 11 Feb, 2019 2 commits
  33. 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
  35. 06 Feb, 2019 1 commit
  37. 05 Feb, 2019 1 commit
  39. 01 Feb, 2019 1 commit
  41. 31 Jan, 2019 2 commits
    • Sigurd Schneider's avatar
      Fix pointer-compression related #defines · 0194eb58
      Sigurd Schneider authored 
      1) Ensure 31bit Smis are enabled if pointer compression is.
2) Enable some code for 31bit Smis

Bug: v8:8344
Change-Id: Ib1e68ebfcfd49e16d1548879b7670c88dc73449b
Reviewed-on: https://chromium-review.googlesource.com/c/1445979
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59248}
      0194eb58
    • Pierre Langlois's avatar
      [arm64] Correctly print V registers. · 77a643e3
      Pierre Langlois authored 
      The arm64 backend defines registers with a common base `CPURegister` class which
can represent both general purpose and vector registers. We would use it to
define the `RegisterName` function which results in printing all registers with
`xN` when using the --trace-turbo-graph flag:

~~~
[x0|R|f64] = Arm64LdrD : MRR [x7|R|tp] [x5|R|w64]
 ^^
 This is the d0 register, not x0
~~~

We have `Register` and `VRegister` classes to distinguish general purpose
registers from vector registers, use those to define `RegisterName` functions
and print vector registers as `vN` intead:

~~~
[v0|R|f64] = Arm64LdrD : MRR [x7|R|tp] [x5|R|w64]
~~~

Since FloatRegister, DoubleRegister and Simd128Register are typedef of
VRegister, we cannot differentiate them with the current `DEFINE_REGISTER_NAMES`
abstraction. Architecturaly, S, D and Q registers are aliases of V registers so
that's not a problem.

Change-Id: Ic43036117c834070d3311b65c99ad1e24e1f9c3f
Reviewed-on: https://chromium-review.googlesource.com/c/1445990Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#59234}
      77a643e3
  43. 30 Jan, 2019 2 commits
  45. 28 Jan, 2019 1 commit
  47. 23 Jan, 2019 1 commit
  49. 17 Jan, 2019 3 commits
  51. 16 Jan, 2019 1 commit
    • Clemens Hammacher's avatar
      [assembler] Allow to pass custom buffer implementations · 1a3aab51
      Clemens Hammacher authored 
      When generating an Assembler, you currently have two choices: Either
let the Assembler allocate a growable internal buffer, which is owned
by the Assembler. Or provide an externally allocated buffer, which
cannot grow.
This CL changes this interface to allow providing any implementation of
a buffer. The provided buffer can be a view to an externally owned
buffer, which still can grow.
This will be used to split WebAssembly compilation and code submission.
The buffer needs to be able to grow, but cannot be owned by the
Assembler because it has to survive until the code is submitted.

R=mstarzinger@chromium.org

Bug: v8:8689
Change-Id: Ib6c5ebffc8b71d0778944abac34f02c5cc7dbd79
Reviewed-on: https://chromium-review.googlesource.com/c/1411347
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58848}
      1a3aab51
  53. 14 Jan, 2019 1 commit
    • Camillo Bruni's avatar
      Reland "[parser] Inline byte scope data into PreparseData object" · a6f44629
      Camillo Bruni authored 
      This is a reland of e2d44ede

Original change's description:
> [parser] Inline byte scope data into PreparseData object
> 
> Each PreparseData object had at least one pointer to a PodArray for its
> serialized scope data. These objects usually have only tens of bytes of
> payload. By inlining the byte data we save 3 words per PreparseData object.
> This optimization saves 140KB of data on cnn.com.
> 
> 
> - Store data_length and inner_length as int32 saving a words on 64bit
> - Inline store byte data into PreparseData
> - OnHeapConsumedPreparseData directly uses the PreparseData object
> - get_inner, set_inner no longer allow Null sentinels
> 
> Change-Id: I1f62154d05ea2f98a6574efa738b32a8a84319d5
> Reviewed-on: https://chromium-review.googlesource.com/c/1406673
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58751}

Change-Id: I1f0a22c641d0d67f435b01c82daf8da7f144bff4
Reviewed-on: https://chromium-review.googlesource.com/c/1407066Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58785}
      a6f44629
  55. 11 Jan, 2019 3 commits
  57. 08 Jan, 2019 2 commits