Skip to content

V
V8
Switch branch/tag
  1. 10 May, 2021 1 commit
  3. 05 May, 2021 1 commit
    • Nico Hartmann's avatar
      [TurboFan] Add %VerifyType intrinsic · f486a343
      Nico Hartmann authored 
      This CL adds a new %VerifyType compiler intrinsic that can be used
by tests and fuzzers to generate a runtime type check of the given
input value. Internally, %VerifyType is lowered to %AssertType
which is why checks are currently limited to range types.

tests to be const-correct.

Drive-by: Add a few consts to NodeProperties accessors to allow
Bug: v8:11724
Change-Id: I06842062d0e8278a5ba011d5a09947fe05b6e85e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859959
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74377}
      f486a343
  5. 13 Apr, 2021 1 commit
  7. 11 Mar, 2021 3 commits
    • Clemens Backes's avatar
      Reland "[no-wasm] Exclude src/wasm from compilation" · 3f9ff062
      Clemens Backes authored 
      This is a reland of 80f5dfda. A condition
in pipeline.cc was inverted, which lead to a CSA verifier error.

Original change's description:
> [no-wasm] Exclude src/wasm from compilation
>
> This is the biggest chunk, including
> - all of src/wasm,
> - torque file for wasm objects,
> - torque file for wasm builtins,
> - wasm builtins,
> - wasm runtime functions,
> - int64 lowering,
> - simd scala lowering,
> - WasmGraphBuilder (TF graph construction for wasm),
> - wasm frame types,
> - wasm interrupts,
> - the JSWasmCall opcode,
> - wasm backing store allocation.
>
> Those components are all recursively entangled, so I found no way to
> split this change up further.
>
> Some includes that were recursively included by wasm headers needed to
> be added explicitly now.
>
> backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
> because it only tests wasm backing stores. This file is excluded from
> no-wasm builds then.
>
> R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
>
> Bug: v8:11238
> Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
> Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73344}

TBR=jgruber@chromium.org

Bug: v8:11238
Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73348}
      3f9ff062
    • Clemens Backes's avatar
      Revert "[no-wasm] Exclude src/wasm from compilation" · 92bc3d38
      Clemens Backes authored 
      This reverts commit 80f5dfda.

Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview

Original change's description:
> [no-wasm] Exclude src/wasm from compilation
>
> This is the biggest chunk, including
> - all of src/wasm,
> - torque file for wasm objects,
> - torque file for wasm builtins,
> - wasm builtins,
> - wasm runtime functions,
> - int64 lowering,
> - simd scala lowering,
> - WasmGraphBuilder (TF graph construction for wasm),
> - wasm frame types,
> - wasm interrupts,
> - the JSWasmCall opcode,
> - wasm backing store allocation.
>
> Those components are all recursively entangled, so I found no way to
> split this change up further.
>
> Some includes that were recursively included by wasm headers needed to
> be added explicitly now.
>
> backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
> because it only tests wasm backing stores. This file is excluded from
> no-wasm builds then.
>
> R=​jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
>
> Bug: v8:11238
> Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
> Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73344}

Bug: v8:11238
Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73346}
      92bc3d38
    • Clemens Backes's avatar
      [no-wasm] Exclude src/wasm from compilation · 80f5dfda
      Clemens Backes authored 
      This is the biggest chunk, including
- all of src/wasm,
- torque file for wasm objects,
- torque file for wasm builtins,
- wasm builtins,
- wasm runtime functions,
- int64 lowering,
- simd scala lowering,
- WasmGraphBuilder (TF graph construction for wasm),
- wasm frame types,
- wasm interrupts,
- the JSWasmCall opcode,
- wasm backing store allocation.

Those components are all recursively entangled, so I found no way to
split this change up further.

Some includes that were recursively included by wasm headers needed to
be added explicitly now.

backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
because it only tests wasm backing stores. This file is excluded from
no-wasm builds then.

R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org

Bug: v8:11238
Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73344}
      80f5dfda
  9. 10 Mar, 2021 1 commit
  11. 24 Nov, 2020 1 commit
    • Leszek Swirski's avatar
      [utils] Add CompareCharsEqual · 52cfffde
      Leszek Swirski authored 
      Add a CompareCharsEqual to complement CompareChars, where we only care
about equality and not ordering. For such cases, we can memcmp for two-
byte as well as one-byte strings (we can't for CompareChars because the
ordering would be incorrect on little-endian systems).

Replace uses of CompareChars that only compare the result against zero,
with CompareCharsEqual. Additionally, use some template magic to
simplify the "make unsigned" operation in these methods.

Change-Id: I0d65bee81b98d3938d15daa4af331c90558ea84f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557980
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71385}
      52cfffde
  13. 17 Nov, 2020 1 commit
  15. 22 Jun, 2020 1 commit
  17. 18 Jun, 2020 1 commit
  19. 20 Apr, 2020 1 commit
  21. 15 Apr, 2020 1 commit
  23. 10 Feb, 2020 1 commit
  25. 31 Jan, 2020 1 commit
  27. 11 Nov, 2019 1 commit
  29. 20 Aug, 2019 1 commit
  31. 23 May, 2019 2 commits
  33. 22 May, 2019 1 commit
  35. 21 May, 2019 1 commit
  37. 15 May, 2019 1 commit
    • Tobias Tebbi's avatar
      Reland: [csa] verify skipped write-barriers in MemoryOptimizer · a19c3ffb
      Tobias Tebbi authored 
      With very few exceptions, this verifies all skipped write-barriers in
CSA and Torque, showing that the MemoryOptimizer together with some
type information on the stored value are enough to avoid unsafe skipped
write-barriers.

Changes to CSA:
SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
MemoryOptimizer by default.
Type information about the stored values (TNode<Smi>) is exploited to
safely skip write barriers for stored Smi values.
In some cases, the code is re-structured to make it easier to consume
for the MemoryOptimizer (manual branch and load elimination).

Changes to the MemoryOptimizer:
Improve the MemoryOptimizer to remove write barriers:
- When the store happens to a CSA-generated InnerAllocate, by ignoring
  Bitcasts and additions.
- When the stored value is the HeapConstant of an immortal immovable root.
- When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
- Fast C-calls are treated as non-allocating.
- Runtime calls can be white-listed as non-allocating.

Remaining missing cases:
- C++-style iterator loops with inner pointers.
- Inner allocates that are reloaded from a field where they were just stored
  (for example an elements backing store). Load elimination would fix that.
- Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
  We could handle that in Torque.
- Double-aligned allocations, which are not lowered in the MemoryOptimizer
  but in CSA.

Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
can be handled by overload resolution (in Torque and C++).

Reland Change: Support pointer compression operands.

R=jarin@chromium.org
TBR=mvstanton@chromium.org

Bug: v8:7793
Change-Id: I84e1831eb6bf9be14f36db3f8b485ee4fab6b22e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1612904
Auto-Submit: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61522}
      a19c3ffb
  39. 13 May, 2019 1 commit
  41. 10 May, 2019 1 commit
    • Ross McIlroy's avatar
      Revert "[class] implement private method declarations" · bf07d790
      Ross McIlroy authored 
      This reverts commit b9191bd3.

Reason for revert: Clusterfuzz bugs
BUG=chromium:961507,chromium:961508

Original change's description:
> [class] implement private method declarations
>
> This patch implements the declarations of private methods, the access
> of private methods would be left to a future patch.
> When a private methods declaration is encountered, we now:
>
> - Create a brand symbol during class evaluation and store it in the
>   context.
> - Create the closures for the private methods
> - Load the brand from the context and store it in the instance in the
>   constructor.
>
> Design: https://docs.google.com/document/d/1T-Ql6HOIH2U_8YjWkwK2rTfywwb7b3Qe8d3jkz72KwA/edit#
>
> Bug: v8:8330
> Change-Id: I2d695cbdc8a7367ddc7620d627b318f779d36150
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1568708
> Commit-Queue: Joyee Cheung <joyee@igalia.com>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61387}

TBR=rmcilroy@chromium.org,gsathya@chromium.org,verwaest@chromium.org,joyee@igalia.com

Change-Id: I429bbe8af9f94598de132814aa2c3ab9fa69b986
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8330
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1605730
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61406}
      bf07d790
  43. 09 May, 2019 1 commit
  45. 26 Apr, 2019 1 commit
    • Ross McIlroy's avatar
      Revert "[csa] verify skipped write-barriers in MemoryOptimizer" · dd6c9536
      Ross McIlroy authored 
      This reverts commit da7322c0.

Reason for revert: Breaking the pointer compression bots, e.g.:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20pointer%20compression/3047

Original change's description:
> [csa] verify skipped write-barriers in MemoryOptimizer
> 
> With very few exceptions, this verifies all skipped write-barriers in
> CSA and Torque, showing that the MemoryOptimizer together with some
> type information on the stored value are enough to avoid unsafe skipped
> write-barriers.
> 
> Changes to CSA:
> SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
> MemoryOptimizer by default.
> Type information about the stored values (TNode<Smi>) is exploited to
> safely skip write barriers for stored Smi values.
> In some cases, the code is re-structured to make it easier to consume
> for the MemoryOptimizer (manual branch and load elimination).
> 
> Changes to the MemoryOptimizer:
> Improve the MemoryOptimizer to remove write barriers:
> - When the store happens to a CSA-generated InnerAllocate, by ignoring
>   Bitcasts and additions.
> - When the stored value is the HeapConstant of an immortal immovable root.
> - When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
> - Fast C-calls are treated as non-allocating.
> - Runtime calls can be white-listed as non-allocating.
> 
> Remaining missing cases:
> - C++-style iterator loops with inner pointers.
> - Inner allocates that are reloaded from a field where they were just stored
>   (for example an elements backing store). Load elimination would fix that.
> - Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
>   We could handle that in Torque.
> - Double-aligned allocations, which are not lowered in the MemoryOptimizer
>   but in CSA.
> 
> Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
> can be handled by overload resolution (in Torque and C++).
> 
> R=​jarin@chromium.org
> TBR=mvstanton@chromium.org
> 
> Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
> Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61016}

TBR=mvstanton@chromium.org,jarin@chromium.org,tebbi@chromium.org

Change-Id: I36877cd6d08761726ef8dce8a3e3f2ce3eebe6cf
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1585732Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61038}
      dd6c9536
  47. 25 Apr, 2019 1 commit
    • Tobias Tebbi's avatar
      [csa] verify skipped write-barriers in MemoryOptimizer · da7322c0
      Tobias Tebbi authored 
      With very few exceptions, this verifies all skipped write-barriers in
CSA and Torque, showing that the MemoryOptimizer together with some
type information on the stored value are enough to avoid unsafe skipped
write-barriers.

Changes to CSA:
SKIP_WRITE_BARRIER and Store*NoWriteBarrier are verified by the
MemoryOptimizer by default.
Type information about the stored values (TNode<Smi>) is exploited to
safely skip write barriers for stored Smi values.
In some cases, the code is re-structured to make it easier to consume
for the MemoryOptimizer (manual branch and load elimination).

Changes to the MemoryOptimizer:
Improve the MemoryOptimizer to remove write barriers:
- When the store happens to a CSA-generated InnerAllocate, by ignoring
  Bitcasts and additions.
- When the stored value is the HeapConstant of an immortal immovable root.
- When the stored value is a SmiConstant (recognized by BitcastToTaggedSigned).
- Fast C-calls are treated as non-allocating.
- Runtime calls can be white-listed as non-allocating.

Remaining missing cases:
- C++-style iterator loops with inner pointers.
- Inner allocates that are reloaded from a field where they were just stored
  (for example an elements backing store). Load elimination would fix that.
- Safe stored value types that cannot be expressed in CSA (e.g., Smi|Hole).
  We could handle that in Torque.
- Double-aligned allocations, which are not lowered in the MemoryOptimizer
  but in CSA.

Drive-by change: Avoid Smi suffix for StoreFixedArrayElement since this
can be handled by overload resolution (in Torque and C++).

R=jarin@chromium.org
TBR=mvstanton@chromium.org

Change-Id: I0af9b710673f350e0fe81c2e59f37da93c024b7c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571414
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61016}
      da7322c0
  49. 02 Feb, 2019 1 commit
  51. 18 Dec, 2018 1 commit
  53. 07 Nov, 2018 1 commit
  55. 06 Nov, 2018 1 commit
  57. 10 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [async] Improve async function handling. · 0038e5f0
      Benedikt Meurer authored 
      This change introduces new intrinsics used to desugar async functions
in the Parser and the BytecodeGenerator, namely we introduce a new
%_AsyncFunctionEnter intrinsic that constructs the generator object
for the async function (and in the future will also create the outer
promise for the async function). This generator object is internal
and never escapes to user code, plus since async functions don't have
a "prototype" property, we can just a single map here instead of tracking
the prototype/initial_map on every async function. This saves one word
per async function plus one initial_map per async function that was
invoked at least once.

We also introduce two new intrinsics %_AsyncFunctionReject, which
rejects the outer promise with the caught exception, and another
%_AsyncFunctionResolve, which resolves the outer promise with the
right hand side of the `return` statement. These functions also perform
the DevTools part of the job (aka popping from the promise stack and
sending the debug event). This allows us to get rid of the implicit
try-finally from async functions completely; because the finally
block only called to the %AsyncFunctionPromiseRelease builtin, which
was used to inform DevTools.

In essence we now turn an async function like

```js
async function f(x) { return await bar(x); }
```

into something like this (in Parser and BytecodeGenerator respectively):

```
function f(x) {
  .generator_object = %_AsyncFunctionEnter(.closure, this);
  .promise = %AsyncFunctionCreatePromise();
  try {
    .tmp = await bar(x);
    return %_AsyncFunctionResolve(.promise, .tmp);
  } catch (e) {
    return %_AsyncFunctionReject(.promise, e);
  }
}
```

Overall the bytecode for async functions gets significantly shorter
already (and will get even shorter once we put the outer promise into
the async function generator object). For example the bytecode for a
simple async function

```js
async function f(x) { return await x; }
```

goes from 175 bytes to 110 bytes (a ~38% reduction in size), which
is in particular due to the simplification around the try-finally
removal.

Overall this seems to improve the doxbee-async-es2017-native test by
around 2-3%. On the test case mentioned in v8:8276 we go from
1124ms to 441ms, which corresponds to a 60% reduction in total
execution time!

Tbr: marja@chromium.org
Bug: v8:7253, v8:7522, v8:8276
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Id29dc92de7490b387ff697860c900cee44c9a7a4
Reviewed-on: https://chromium-review.googlesource.com/c/1269041
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56502}
      0038e5f0
  59. 08 Oct, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Introduce the notion of context-sensitivity for JS operators. · 51274d3c
      Benedikt Meurer authored 
      This change adds predicates to check whether a given JavaScript operator
needs the "current context" or if any surrounding context (including the
"native context") does it. For example JSAdd doesn't ever need the
current context, but actually only the native context. In the
BytecodeGraphBuilder we use this predicate to check whether a given
operator needs the current context, and if not, we just pass in the
native context.

Doing so we improve the performance on the benchmarks given in the
tracking bug significantly, and go from something around

  arrayMap: 476 ms.
  arrayFilter: 312 ms.
  arrayEvery: 241 ms.
  arraySome: 152 ms.

to

  arrayMap: 377 ms.
  arrayFilter: 296 ms.
  arrayEvery: 191 ms.
  arraySome: 91 ms.

which is an up to 40% improvement. So for idiomatic modern JavaScript
which uses higher order functions quite a lot, not just the builtins
provided by the JSVM, this is going to improve peak performance
noticably.

This also makes it possible to completely eliminate all the allocations
in the aliased sloppy arguments example

```js
function foo(a) { return arguments.length; }
```

concretely we don't allocate the function context anymore and we also
don't allocate the arguments object anymore (the JSStackCheck was the
reason why we did this in the past, because it was holding on to the
current context, which also kept the allocation for the arguments
alive).

Bug: v8:6200, v8:8060
Change-Id: I1db56d00d6b510ce6337608c0fff16af96e95eef
Design-Document: bit.ly/v8-turbofan-context-sensitive-js-operators
Reviewed-on: https://chromium-review.googlesource.com/c/1267176Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56441}
      51274d3c
  61. 05 Oct, 2018 1 commit
    • Peter Marshall's avatar
      [cleanup] Don't declare inline runtime functions by default · 49420760
      Peter Marshall authored 
      For each intrinsic/runtime function we define in runtime.h, an inline
version is automatically declared. We only ever use 24 of the inline
functions. Even though we don't call the other ones, macro magic means
they still take up space by existing in various arrays and tables like
kIntrinsicFunctions. They also create code in switch statements.

Some drive-by cleanups:
 - Remove the switch in NameForRuntimeId() and just use the table of
   runtime functions to lookup the name directly.
 - Remove tests for IsFunction, ClassOf and StringAdd intrinsics as
   they are the last users of the inline versions of these.
 - Remove the MaxSmi inline version as it is only used in tests.

Saves 64 KiB binary size.

Change-Id: I4c870ddacd2655ffcffa97d93200ed8f853752f5
Reviewed-on: https://chromium-review.googlesource.com/c/1261939
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56412}
      49420760
  63. 05 Sep, 2018 1 commit
    • Hai Dang's avatar
      Reland "[interpreter] Add bytecode for leading array spreads." · 5f8a4272
      Hai Dang authored 
      This is a reland of 1c48d52b.

It turned out that IterableToList doesn't always behave according to
the ES operation with the same name. Specifically, it allows holey arrays
to take its fast path, which produces an output array with holes where
actually "undefined" elements should appear.

This CL changes the version of IterableToList that is used for spreads
(IterableToListWithSymbolLookup) such that holey arrays take the slow path.
It also includes tests for such situations.

Original change's description:
> [interpreter] Add bytecode for leading array spreads.
>
> This CL improves the performance of creating [...a, b] or [...a].
> If the array literal has a leading spread, this CL emits the bytecode
> [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
> is implemented by [IterableToListDefault] builtin to create the initial
> array for the leading spread. IterableToListDefault has a fast path to
> clone efficiently if the spread is an actual array.
>
> The bytecode generated is now shorter. Bytecode generation is refactored
> into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
> from this optimization also.
> For now, turbofan also lowers the bytecode to the builtin.
>
> The idiomatic use of [...a] to clone the array a now performs better
> than a simple for-loop, but still does not match the performance of slice.
>
> Bug: v8:7980
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
> Reviewed-on: https://chromium-review.googlesource.com/1181024
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Commit-Queue: Hai Dang <dhai@google.com>
> Cr-Commit-Position: refs/heads/master@{#55520}

Bug: v8:7980
Change-Id: I0b5603a12d2b588327658bf0a9b214bd0f22e237
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1201882
Commit-Queue: Hai Dang <dhai@google.com>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55639}
      5f8a4272
  65. 31 Aug, 2018 1 commit
    • Georg Neis's avatar
      Revert "[interpreter] Add bytecode for leading array spreads." · ef569028
      Georg Neis authored 
      This reverts commit 1c48d52b.

Reason for revert: Clusterfuzz found something.

Original change's description:
> [interpreter] Add bytecode for leading array spreads.
> 
> This CL improves the performance of creating [...a, b] or [...a].
> If the array literal has a leading spread, this CL emits the bytecode
> [CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
> is implemented by [IterableToListDefault] builtin to create the initial
> array for the leading spread. IterableToListDefault has a fast path to
> clone efficiently if the spread is an actual array.
> 
> The bytecode generated is now shorter. Bytecode generation is refactored
> into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
> from this optimization also.
> For now, turbofan also lowers the bytecode to the builtin.
> 
> The idiomatic use of [...a] to clone the array a now performs better
> than a simple for-loop, but still does not match the performance of slice.
> 
> Bug: v8:7980
> 
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
> Reviewed-on: https://chromium-review.googlesource.com/1181024
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Commit-Queue: Hai Dang <dhai@google.com>
> Cr-Commit-Position: refs/heads/master@{#55520}

TBR=rmcilroy@chromium.org,neis@chromium.org,sigurds@chromium.org,gsathya@chromium.org,jgruber@chromium.org,dhai@google.com

Change-Id: I1c86ddcc24274da9f5a8dd3d8bf8d869cbb55cb6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7980
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1199303Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55544}
      ef569028
  67. 30 Aug, 2018 1 commit
    • Hai Dang's avatar
      [interpreter] Add bytecode for leading array spreads. · 1c48d52b
      Hai Dang authored 
      This CL improves the performance of creating [...a, b] or [...a].
If the array literal has a leading spread, this CL emits the bytecode
[CreateArrayFromIterable] to create the literal. CreateArrayFromIterable
is implemented by [IterableToListDefault] builtin to create the initial
array for the leading spread. IterableToListDefault has a fast path to
clone efficiently if the spread is an actual array.

The bytecode generated is now shorter. Bytecode generation is refactored
into to BuildCreateArrayLiteral, which allows VisitCallSuper to benefit
from this optimization also.
For now, turbofan also lowers the bytecode to the builtin.

The idiomatic use of [...a] to clone the array a now performs better
than a simple for-loop, but still does not match the performance of slice.

Bug: v8:7980

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ibde659c82d3c7aa1b1777a3d2f6426ac8cc15e35
Reviewed-on: https://chromium-review.googlesource.com/1181024Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Commit-Queue: Hai Dang <dhai@google.com>
Cr-Commit-Position: refs/heads/master@{#55520}
      1c48d52b
  69. 17 Aug, 2018 1 commit
  71. 25 Apr, 2018 1 commit
    • Andreas Haas's avatar
      Reland: [refactoring] Remove the isolate from signatures of ExternalReferences · 2a3c2c73
      Andreas Haas authored 
      I missed one required change which was hidden behind an #if. The fix is in
the diff between Patch 1 and Patch 3.

Original message:
In this CL I remove the isolate from signatures of ExternalReference
accessor functions where the isolate is not used. The uses of the
isolate were already removed in previous CLs.

Changes:
* I split the ExternalReference list in external-reference.h into
those which need the isolate for initialization and those which do not.

* I removed the public constructors and replaced them by
  ExternalReference::Create(). The reason is to separate external
  creation more clearly from internal creation, because externally
  created ExternalReferences sometimes need redirection, whereas
  internally created ExternalReferences are just stored as they are.
  In addition, by removing the isolate from the signature of the
  public constructors, they suddenly exactly matched the interal
  constructor.

* Replace all uses of the public constructors with
  ExternalReference::Create().

* Remove the isolate from all call sites where necessary.


This is a step towards making WebAssembly compilation independent of
the isolate.

R=mstarzinger@chromium.org

Bug: v8:7570
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I750c162f5d58ed32e866722b0db920f8b9bd8057
Reviewed-on: https://chromium-review.googlesource.com/1026673Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52777}
      2a3c2c73
  73. 24 Apr, 2018 1 commit
    • Andreas Haas's avatar
      Revert "[refactoring] Remove the isolate from signatures of ExternalReferences" · 7bfed2ad
      Andreas Haas authored 
      This reverts commit 44ea425a.

Reason for revert: https://ci.chromium.org/buildbot/client.v8.ports/V8%20Arm%20-%20debug%20builder/13575

Original change's description:
> [refactoring] Remove the isolate from signatures of ExternalReferences
> 
> In this CL I remove the isolate from signatures of ExternalReference
> accessor functions where the isolate is not used. The uses of the
> isolate were already removed in previous CLs.
> 
> Changes:
> * I split the ExternalReference list in external-reference.h into
> those which need the isolate for initialization and those which do not.
> 
> * I removed the public constructors and replaced them by
>   ExternalReference::Create(). The reason is to separate external
>   creation more clearly from internal creation, because externally
>   created ExternalReferences sometimes need redirection, whereas
>   internally created ExternalReferences are just stored as they are.
>   In addition, by removing the isolate from the signature of the
>   public constructors, they suddenly exactly matched the interal
>   constructor.
> 
> * Replace all uses of the public constructors with
>   ExternalReference::Create().
> 
> * Remove the isolate from all call sites where necessary.
> 
> 
> This is a step towards making WebAssembly compilation independent of
> the isolate.
> 
> Bug: v8:7570
> R=​mstarzinger@chromium.org
> 
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: I14f511fc6acc50ab2d6a6641299f5ddbeabef0da
> Reviewed-on: https://chromium-review.googlesource.com/1018982
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52768}

TBR=mstarzinger@chromium.org,ahaas@chromium.org

Change-Id: I7c0d8d420f815cede23d550dee8942ac4d7791cc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7570
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1026570Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52769}
      7bfed2ad