1. 11 Sep, 2019 6 commits
  2. 10 Sep, 2019 5 commits
  3. 09 Sep, 2019 5 commits
  4. 06 Sep, 2019 2 commits
    • Swapnil Gaikwad's avatar
      Reland "Update GetIterator bytecode to load and call object[Symbol.iterator]" · ffa9f163
      Swapnil Gaikwad authored
      This is a reland of 8b89a7c3
      
      Reland after disabling the test getting deadlocked with '--gc_stress' flag.
      The CL was reverted because of the 'wasm/grow-shared-memory' test from
      the mjsunit test suite deadlocked for the 'gc_stress' variant. This is
      the known issue (v8:9221) and the deadlocking test is now disabled (
      https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788).
      
      
      Original change's description:
      > Update GetIterator bytecode to load and call object[Symbol.iterator]
      >
      > The functionality of the GetIterator bytecode introduced previously is
      > now extended from loading the @@iterator property to calling the property
      > as well. This change basically absorbs the functionality of additional
      > two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
      > Importantly, this change handles the cases of eager and lazy deoptimization
      > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
      > eager deopt of the CallProperty0 bytecode, using the continuation builtins.
      > This mechanism can work as a template for the future bytecode that require
      > handling such inter-bytecode deopt scenario. The tests evaluating the eager
      > and lazy deopt scenarios are also included.
      >
      > Bug: v8:9489
      > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
      > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63528}
      
      Bug: v8:9489,v8:9221
      Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      Cr-Commit-Position: refs/heads/master@{#63599}
      ffa9f163
    • Clemens Hammacher's avatar
      [wasm][arm64] Optimize runtime stub slots · 6cf9cb49
      Clemens Hammacher authored
      This reduces the size per runtime stub slot by using the same sequence
      we plan to use for far jumps.
      Note that alignment is not an issue here, since runtime stub slots are
      never patched.
      
      R=mstarzinger@chromium.org
      CC=joey.gouly@arm.com
      
      Bug: v8:9477
      Change-Id: I38666c8fce93a977bc5b9ca5fafc54f6ae739f12
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784293
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63591}
      6cf9cb49
  5. 05 Sep, 2019 4 commits
  6. 04 Sep, 2019 5 commits
    • Tobias Tebbi's avatar
      Revert "[compiler] improve inlining heuristics: call frequency per executed bytecodes" · eb443e1f
      Tobias Tebbi authored
      This reverts commit 352a154e.
      
      Reason for revert: https://crbug.com/999972
      
      Original change's description:
      > [compiler] improve inlining heuristics: call frequency per executed bytecodes
      > 
      > TLDR: Inline less, but more where it matters. ~10% decrease in Turbofan
      > compile time including off-thread, while improving Octane scores by ~2%.
      > 
      > How things used to work:
      > 
      > There is a flag FLAG_min_inlining_frequency that limits inlining by
      > the callsite being sufficiently frequently executed. This call frequency
      > was measured relative to invocations of the parent (= the function we
      > originally optimize). At the same time, the limit was very low (0.15),
      > meaning we mostly relied on the total amount of inlined code
      > (FLAG_max_inlined_bytecode_size_cumulative) to limit inlining.
      > 
      > How things work now:
      > 
      > Instead of measuring call frequency relative to parent invocations, we
      > should have a measure that predicts how often the callsite in question
      > will be executed in the future. An obvious attempt at that would be to
      > measure how often the callsite was executed in absolute numbers in the
      > past. But depending on how fast feedback stabilizes, it can take more
      > or less time until we optimize a function. If we just take the absolute
      > call frequency up to the point in time when we optimize, we would
      > inline more for functions that stabilize slowly, which doesn't make
      > sense. So instead, we measure absolute call count per KB of executed
      > bytecodes of the parent function.
      > Since inlining big functions is more expensive, this threshold is
      > additionally scaled linearly with the bytecode-size of the inlinee.
      > The resulting formula is:
      > call_frequency >
      > FLAG_min_inlining_frequency *
      >   (bytecode.length() - FLAG_max_inlined_bytecode_size_small) /
      >   (FLAG_max_inlined_bytecode_size - FLAG_max_inlined_bytecode_size_small)
      > 
      > The new threshold is chosen in a way that it effectively limits
      > inlining, which allows us to increase
      > FLAG_max_inlined_bytecode_size_cumulative without increasing inlining
      > in general.
      > 
      > The reduction in compile time (x64 build) of ~10% was observed in Octane,
      > ARES-6, web-tooling-benchmark, and the standalone TypeScript benchmark.
      > The hope is that this will reduce CPU-time in real-world situations
      > too.
      > The Octane improvements come from inlining more in places where it
      > matters.
      > 
      > Bug: v8:6682
      > 
      > Change-Id: I99baa17dec85b71616a3ab3414d7e055beca39a0
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768366
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63449}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org,jgruber@chromium.org,tebbi@chromium.org,mslekova@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:6682 chromium:999972
      Change-Id: Iffca63d4bef81afa0f66e34d35fb72f3b5baf517
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784281Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63554}
      eb443e1f
    • Leszek Swirski's avatar
      Revert "Reland "[ic] In-place Double -> Tagged transitions"" · b293533e
      Leszek Swirski authored
      This reverts commit 981aafaf.
      
      Reason for revert: Still crashing on Canary.
      
      Original change's description:
      > Reland "[ic] In-place Double -> Tagged transitions"
      >
      > This is a reland of 0736599a.
      > This is a reland of 7e1fbe8f.
      >
      > Original change description:
      > > [ic] In-place Double -> Tagged transitions
      > >
      > > With no more MutableHeapNumber, we can make Double -> Tagged transitions
      > > in-place, at the cost of an extra map check when accessing double fields
      > > to make sure they are still doubles.
      > >
      > > Bug: v8:9606
      > > Change-Id: I74ff39ed6fba62ee223cd37dfe761f7d73020e1c
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743973
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#63374}
      >
      > TBR=verwaest@chromium.org, tebbi@chromium.org
      >
      > Bug: v8:9606
      > Change-Id: I2d1b7416064d743582f4983fb868316b7e8a4cf2
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1777661
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63499}
      
      TBR=leszeks@chromium.org, verwaest@chromium.org, tebbi@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:9606
      Bug: chromium:997989
      Change-Id: Ic95166e67df68e84a524dffd8155121c3ff6aa13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784283
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63550}
      b293533e
    • Patrick Thier's avatar
      [regexp] Minor performance improvements and cleanups · 019fa2b5
      Patrick Thier authored
      Instead of checking code flags to decide if the irregexp code object is
      an off-heap trampoline, we now directly load the builtin index offset
      and treat the code as on-heap if the offset is -1.
      
      In addition the regexp stack now has its own external reference for top
      of stack address. This prevents calculating the top of stack address
      using the base address and size at every invocation.
      
      Bug: chromium:999993
      Change-Id: I23649e8b410a56276f26846b0b12ad29310c3db7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782565Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Patrick Thier <pthier@google.com>
      Cr-Commit-Position: refs/heads/master@{#63548}
      019fa2b5
    • Georg Neis's avatar
      Reland "[turbofan] Prepare for moving part of CreateGraph into the background" · 086efd87
      Georg Neis authored
      This is a reland of ab089c78, after
      making a flaky test more robust.
      
      Original change's description:
      > [turbofan] Prepare for moving part of CreateGraph into the background
      >
      > - Pass Refs, not Handles, to graph builder, and drop bytecode array argument
      >   (get it from SFI instead).
      > - Add some fields to FeedbackVectorRef that are needed to avoid heap access
      >   in BytecodeGraphBuilderPhase.
      > - Rename FeedbackVectorRef's SerializeSlots to Serialize, since it's more
      >   than just the feedback slots.
      > - Rearrange the last steps in PipelineCompilationJob::PrepareJobImpl such
      >   that CreateGraph is last.
      >
      > Bug: v8:7790
      > Change-Id: I4b17790d1d74da41ba63ee68e3a33968662fc398
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781682
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63515}
      
      Bug: v8:7790
      Change-Id: Ia6f4c1ebd82dea93c14437514d0e25b730523f75
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781694Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63545}
      086efd87
    • Georg Neis's avatar
      Make more use of NativeContext type in CSA and Torque · 72946aa8
      Georg Neis authored
      Change-Id: I29a4d20656727e6ec1e1fd052a840bd5aefe3cd4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781052
      Commit-Queue: Georg Neis <neis@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63544}
      72946aa8
  7. 03 Sep, 2019 6 commits
    • Francis McCabe's avatar
      Revert "Update GetIterator bytecode to load and call object[Symbol.iterator]" · af04a51e
      Francis McCabe authored
      This reverts commit 8b89a7c3.
      
      Reason for revert: GC Stress tests timing out.
      See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24272
      
      Original change's description:
      > Update GetIterator bytecode to load and call object[Symbol.iterator]
      > 
      > The functionality of the GetIterator bytecode introduced previously is
      > now extended from loading the @@iterator property to calling the property
      > as well. This change basically absorbs the functionality of additional
      > two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
      > Importantly, this change handles the cases of eager and lazy deoptimization
      > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
      > eager deopt of the CallProperty0 bytecode, using the continuation builtins.
      > This mechanism can work as a template for the future bytecode that require
      > handling such inter-bytecode deopt scenario. The tests evaluating the eager
      > and lazy deopt scenarios are also included.
      > 
      > Bug: v8:9489
      > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
      > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63528}
      
      TBR=rmcilroy@chromium.org,neis@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com
      
      Change-Id: I9ae475f71275f71f1b9e60b8bf0578e21ce2704b
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9489
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783736Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63536}
      af04a51e
    • Swapnil Gaikwad's avatar
      Update GetIterator bytecode to load and call object[Symbol.iterator] · 8b89a7c3
      Swapnil Gaikwad authored
      The functionality of the GetIterator bytecode introduced previously is
      now extended from loading the @@iterator property to calling the property
      as well. This change basically absorbs the functionality of additional
      two bytecodes - Star, CallProperty0 in the GetIterator bytecode.
      Importantly, this change handles the cases of eager and lazy deoptimization
      in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and
      eager deopt of the CallProperty0 bytecode, using the continuation builtins.
      This mechanism can work as a template for the future bytecode that require
      handling such inter-bytecode deopt scenario. The tests evaluating the eager
      and lazy deopt scenarios are also included.
      
      Bug: v8:9489
      Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313
      Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63528}
      8b89a7c3
    • Santiago Aboy Solanes's avatar
      [CSA] Update MachineType to TaggedSigned for Smi's load and stores · c04b27fb
      Santiago Aboy Solanes authored
      The important bit is using MachineType::TaggedSigned instead of AnyTagged
      in CSA. Everything else, it's just the result of adding types to variables.
      
      SloppyTNode-ify LoadAndUntagToWord32ObjectField.
      
      Both LoadAndUntagSmi and StoreAndTagSmi were only used once, and their
      names were not clear. Inline those where they were used.
      
      TNodify:
      * ReloadBytecodeOffset
      * LoadAndUntagRegister
      * GetInterpretedFramePointer
      * Advance (the three variants)
      * SaveBytecodeOffset
      * BytecodeOffset
      
      Type variables:
      * interpreted_frame_pointer_
      * bytecode_offset_
      
      Create macros:
      * TYPED_VARIABLE_CONSTRUCTOR
      * TVARIABLE_CONSTRUCTOR
      which are similar to their non-typed counterparts.
      
      Bug: v8:7703, v8:6949
      Change-Id: I776e3fe16ca642f868bb635b8bcd5b8b78ca6fea
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758308Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63522}
      c04b27fb
    • Pierre Langlois's avatar
      [arm64] Fix backwards branch ranges. · ffffed90
      Pierre Langlois authored
      The `Instruction::IsValidImmPCOffset()` method was taking an `offset` argument
      in numbers of *instructions* while we were passing it numbers of *bytes*. See
      `Instruction::IsTargetInImmPCOffsetRange()` and
      `MacroAssembler::NeedExtraInstructionsOrRegisterBranch()`.
      
      As a result, we were 4 times too conservative when computing branch ranges going
      backwards, forcing us to generate the following sequence for TBZ more often than
      needed:
      
      ```
        TBNZ <skip>
        B <target>
      skip:
      ```
      
      This happened rarely for loops, but a lot when doing an early return from
      out-of-line calls to write barriers. Since out-of-line code is easily out of
      range of 8K, although the real range of TBZ is 32K.
      
      This fixes it by changing this method to take a byte offset instead of
      instructions, as this is more intuitive and in line with similar methods. For
      instance, `Instruction::ImmPcOffset()` returns an offset in bytes.
      
      The tests are adapted so that they would have caught such a bug:
      
      * TEST(far_branch_backward):
      
        This test used to only check the code worked if the branch was very far away,
        but it didn't test the range was correct. So this test was changed to check
        each branch type separately, and test in-range and out-of-range cases
        separately too.
      
      * TEST(far_branch_veneer_broken_link_chain):
      
        Because of the backwards range bug, this test wasn't actually testing what it
        should. The idea of the test is to make sure the MacroAssembler can still cope
        when the chain of links is broken after a veneer was emitted. But no veneers
        were ever emitted.
      
      Change-Id: Iddb5c683a71147455175f38fa7ae57da0a3e7337
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781058Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63518}
      ffffed90
    • Leszek Swirski's avatar
      Revert "[turbofan] Prepare for moving part of CreateGraph into the background" · f3796bbc
      Leszek Swirski authored
      This reverts commit ab089c78.
      
      Reason for revert: Breaking GC stress (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/27523)
      
      Original change's description:
      > [turbofan] Prepare for moving part of CreateGraph into the background
      > 
      > - Pass Refs, not Handles, to graph builder, and drop bytecode array argument
      >   (get it from SFI instead).
      > - Add some fields to FeedbackVectorRef that are needed to avoid heap access
      >   in BytecodeGraphBuilderPhase.
      > - Rename FeedbackVectorRef's SerializeSlots to Serialize, since it's more
      >   than just the feedback slots.
      > - Rearrange the last steps in PipelineCompilationJob::PrepareJobImpl such
      >   that CreateGraph is last.
      > 
      > Bug: v8:7790
      > Change-Id: I4b17790d1d74da41ba63ee68e3a33968662fc398
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781682
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Commit-Queue: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63515}
      
      TBR=neis@chromium.org,mslekova@chromium.org
      
      Change-Id: I4dc95907657597d12cbe1ce6a8ebb694ef44e915
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7790
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781687Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63517}
      f3796bbc
    • Georg Neis's avatar
      [turbofan] Prepare for moving part of CreateGraph into the background · ab089c78
      Georg Neis authored
      - Pass Refs, not Handles, to graph builder, and drop bytecode array argument
        (get it from SFI instead).
      - Add some fields to FeedbackVectorRef that are needed to avoid heap access
        in BytecodeGraphBuilderPhase.
      - Rename FeedbackVectorRef's SerializeSlots to Serialize, since it's more
        than just the feedback slots.
      - Rearrange the last steps in PipelineCompilationJob::PrepareJobImpl such
        that CreateGraph is last.
      
      Bug: v8:7790
      Change-Id: I4b17790d1d74da41ba63ee68e3a33968662fc398
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781682Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63515}
      ab089c78
  8. 02 Sep, 2019 3 commits
  9. 30 Aug, 2019 2 commits
  10. 29 Aug, 2019 2 commits