Skip to content

V
V8
Switch branch/tag
  1. 23 Aug, 2019 1 commit
    • Dan Elphick's avatar
      [compiler] Skip creating unneeded objects for lazy source positions · 735f3a68
      Dan Elphick authored 
      This changes Compiler::CollectSourcePositions to skip finalization of
the BytecodeArray, constant table, handler table, ScopeInfos as well as
internalization of Ast values since only the source position table is
used and the others will be collected soon after by the GC.

It will also now avoid recompiling inner functions that would otherwise
be eagerly compiled.

BytecodeArrayWriter::ToBytecodeArray has been changed to never populate
the source_position_table.

Bug: v8:8510
Change-Id: I2db2f2da6b48fde11f17a20d017c1a54c0a34fc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1763538
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63365}
      735f3a68
  3. 05 Aug, 2019 1 commit
  5. 30 Jul, 2019 1 commit
    • Georgia Kouveli's avatar
      [arm64] Reduce code size of deoptimization exits · 207d6b35
      Georgia Kouveli authored 
      Do not pass the deoptimization index in a register, instead infer it
from the address we made the deoptimization call from. This makes the
deoptimization exit sequence one instruction long instead of two.

This requires emitting all deoptimization exits at the end of the
function in a contiguous block, making sure no constant or veneer
pools are emitted in between. This means that soft deoptimizations
require an additional branch to the end of the function, which
counteracts the removal of the move instruction, however soft
deoptimizations are rare compared to eager and lazy ones.

This reduces the code size of optimised functions for benchmarks like
Octane and ARES-6 by about 4%.

Change-Id: I771f9104a07de7931a4bb9c5836e25fb55b1a2a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1714876
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62991}
      207d6b35
  7. 29 Jul, 2019 4 commits
    • Clemens Hammacher's avatar
      Reland "[utils] Make BitField final" · 0cabc6a0
      Clemens Hammacher authored 
      This is a reland of 658ff200

Original change's description:
> [utils] Make BitField final
> 
> We have hundreds of classes that derive from {BitField} without adding
> any functionality. This CL switches all such occurrences to 'using'
> declarations instead.
> 
> Before:
>   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
> After:
>   using MyBitField = BitField<int, 6, 4, MyEnum>;
> 
> This might reduce compilation time by reducing the number of existing
> classes.
> 
> The old pattern is forbidden now by making {BitField} final.
> 
> R=yangguo@chromium.org
> 
> Bug: v8:9396, v8:7629
> Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62956}

Bug: v8:9396, v8:7629
Change-Id: Ic68541af9d1e8d0340691970922f282b24a9767f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724379Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62959}
      0cabc6a0
    • Clemens Hammacher's avatar
      Revert "[utils] Make BitField final" · 753a07db
      Clemens Hammacher authored 
      This reverts commit 658ff200.

Reason for revert: Fails no-i18n bot: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20noi18n%20-%20debug/27826

Original change's description:
> [utils] Make BitField final
> 
> We have hundreds of classes that derive from {BitField} without adding
> any functionality. This CL switches all such occurrences to 'using'
> declarations instead.
> 
> Before:
>   class MyBitField : public BitField<int, 6, 4, MyEnum> {};
> After:
>   using MyBitField = BitField<int, 6, 4, MyEnum>;
> 
> This might reduce compilation time by reducing the number of existing
> classes.
> 
> The old pattern is forbidden now by making {BitField} final.
> 
> R=​yangguo@chromium.org
> 
> Bug: v8:9396, v8:7629
> Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#62956}

TBR=yangguo@chromium.org,clemensh@chromium.org

Change-Id: I50234a09c77aa89fdcf1e01c2497cc08d3ac79a8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9396, v8:7629
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724377Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62958}
      753a07db
    • Clemens Hammacher's avatar
      [utils] Make BitField final · 658ff200
      Clemens Hammacher authored 
      We have hundreds of classes that derive from {BitField} without adding
any functionality. This CL switches all such occurrences to 'using'
declarations instead.

Before:
  class MyBitField : public BitField<int, 6, 4, MyEnum> {};
After:
  using MyBitField = BitField<int, 6, 4, MyEnum>;

This might reduce compilation time by reducing the number of existing
classes.

The old pattern is forbidden now by making {BitField} final.

R=yangguo@chromium.org

Bug: v8:9396, v8:7629
Change-Id: I8a8364707e8eae0bb522af2459c160e3293eecbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1722565Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62956}
      658ff200
    • Michael Starzinger's avatar
      [wasm] Make constructed {WebAssembly.Function} callable. · ba77172b
      Michael Starzinger authored 
      This makes function objects constructed via the {WebAssembly.Function}
constructor callable directly from JavaScript (not just from within
WebAssembly modules). Semantics are as if the function performed the
transition JS-to-Wasm and then Wasm-to-JS in sequence.

R=clemensh@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742

Change-Id: Ic7dcf36ccfda1b473f2541e49419f4d2ee38bc2c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1720809
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62953}
      ba77172b
  9. 15 Jul, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Use @generateCppClass in some simple cases · 14274bb1
      Seth Brenith authored 
      This change is mostly mechanical, but it's worth mentioning a few
slightly interesting cases:
- A couple of field definitions didn't match the signedness of their
  corresponding accessors.
- The generated accessors for Smi data use Smi values directly, but
  usually we want C++ accessors to use ints instead. I added a macro
  that hides the generated Smi accessors and exposes int accessors,
  but we might consider generating int accessors directly.
- The data held in some fields is described in comments next to the
  accessor definition for those fields. With automatically generated
  accessors, those comments need a new home. In this change I put them
  in the Torque object definition, but I'm open to other suggestions.
- gen-postmortem-metadata couldn't find updated class definitions after
  they got split across multiple lines, so I changed its matching
  logic. (Ideally debug-support.cc should be a Torque compiler output
  rather than something that involves parsing C++ with regexes, but
  this makes it correctly report subclass relationships for now.)
- The end offsets generated by Torque were off by one from the values
  that would be generated by DEFINE_FIELD_OFFSET_CONSTANTS.

Change-Id: I3df4fcd27997b46c41ca879065b9d97f6c939f07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1692192Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#62719}
      14274bb1
  11. 08 Jul, 2019 1 commit
  13. 30 May, 2019 1 commit
  15. 23 May, 2019 1 commit
  17. 21 May, 2019 1 commit
  19. 09 May, 2019 1 commit
  21. 08 May, 2019 1 commit
  23. 25 Apr, 2019 1 commit
  25. 10 Apr, 2019 4 commits
  27. 09 Apr, 2019 1 commit
  29. 08 Apr, 2019 2 commits
  31. 04 Apr, 2019 1 commit
  33. 29 Mar, 2019 1 commit
  35. 28 Mar, 2019 1 commit
  37. 25 Mar, 2019 1 commit
    • Mythri's avatar
      [lite] Allocate feedback vectors lazily · 7629afdb
      Mythri authored 
      Allocate feedback vectors lazily when the function's interrupt budget has
reached a specified threshold. This cl introduces a new field in the
ClosureFeedbackCellArray to track the interrupt budget for allocating
feedback vectors. Using the interrupt budget on the bytecode array could
cause problems when there are closures across native contexts and we may
delay allocating feedback vectors in one of them causing unexpected
performance cliffs. In the long term we may want to remove interrupt budget
from bytecode array and use context specific budget for tiering up decisions
as well.

Bug: v8:8394
Change-Id: Ia8fbb71f5e8543a92f14c44aa762973da82d445c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520719
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60450}
      7629afdb
  39. 12 Mar, 2019 1 commit
  41. 06 Mar, 2019 1 commit
  43. 04 Mar, 2019 1 commit
  45. 27 Feb, 2019 2 commits
  47. 14 Feb, 2019 1 commit
  49. 13 Feb, 2019 1 commit
  51. 05 Feb, 2019 2 commits
  53. 30 Jan, 2019 1 commit
  55. 09 Jan, 2019 1 commit
  57. 07 Jan, 2019 1 commit
  59. 26 Dec, 2018 1 commit
  61. 20 Dec, 2018 1 commit