1. 06 Sep, 2019 3 commits
  2. 05 Sep, 2019 26 commits
  3. 04 Sep, 2019 11 commits
    • Tom Tan's avatar
      Renaming variables which conflict with macro definition in Windows SDK · 61d6db07
      Tom Tan authored
      Windows SDK defines `near` and `far` as macro in minwindef.h, so they cannot be
      used as variable name if Windows SDK header file is included for Windows build.
      
      Bug: chromium:893460
      Change-Id: I5ed1076b965979b8e4e09958c1b6f0a698ec8d4f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783839Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Tom Tan <Tom.Tan@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63559}
      61d6db07
    • Joey Gouly's avatar
      [arm64][wasm] Implement I64x2 multiply · b7ade853
      Joey Gouly authored
      Implement I64x2 multiply using 32-bit multiplies.
      
      This approach uses two fewer cycles (0.88x) on Cortex-A53 and three fewer cycles (0.86x)
      on Cortex-A72, compared to moving to general purpose registers and doing two 64-bit multiplies.
      
      Based on a patch by Zhi An Ng.
      
      Bug: v8:8460
      Change-Id: I9c8d3bb77f0d751eec2d85823522558b7f173628
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781696
      Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
      Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63558}
      b7ade853
    • Dominik Inführ's avatar
      [heap] Reduce old-to-new invalidations · a14e2f12
      Dominik Inführ authored
      Reduce number of old-to-new invalidations. MigrateFastToFast,
      MigrateFastToSlow and DeleteObjectPropertyFast only need to invalidate
      objects in some cases but not in all.
      
      Bug: v8:9454
      Change-Id: I901eecb9409c6dfa30cf6b4ee0bdd597862fc229
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781042Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63557}
      a14e2f12
    • Seth Brenith's avatar
      Convert UncompiledData class to Torque · e4e86b53
      Seth Brenith authored
      I removed the padding field because I couldn't see a reason why we would
      want to pad to system pointer size. I'm guessing that the intent was to
      pad to tagged pointer size, which was once relevant but isn't anymore
      since one of the int32 fields got removed.
      
      Bug: v8:8952
      Change-Id: Ic191d783efd8d686f6920e6e7ce2d3dacba883c5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776847Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63556}
      e4e86b53
    • Clemens Hammacher's avatar
      [cleanup] Remove dead {AllocatePage} function · 2314928b
      Clemens Hammacher authored
      R=mlippautz@chromium.org
      
      Bug: v8:9396
      Change-Id: If197687b6208257be18f91b4b172ec41600c21b4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784287Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63555}
      2314928b
    • 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
    • Joshua Litt's avatar
      [protectors] Migrate ArraySpeciesProtector to Protectors · abf8e579
      Joshua Litt authored
      Bug: v8:9463
      Change-Id: I4d9d35222597925a289a6c3055ef0ca0aaa43a2f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1775926
      Commit-Queue: Joshua Litt <joshualitt@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63553}
      abf8e579
    • Maya Lekova's avatar
      [turbofan] Turn a never executing condition into a CHECK · 0502ae33
      Maya Lekova authored
      Graph creation used to handle exception throwing gracefully, but this
      seems to never happen, so turned it into a CHECK instead.
      
      Change-Id: I90f8471fe77eb66402fd8abe0d5b15dcffee49bf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784286
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63552}
      0502ae33
    • Georg Neis's avatar
      [turbofan] Ignore deprecated maps for named accesses · 64bf0705
      Georg Neis authored
      We already do this (if we can't migrate them) when processing the
      feedback but it could still happen that we find a deprecated map in the
      graph later on.
      
      Bug: chromium:996819, v8:7790
      Change-Id: I3b9acc8bc21b5a9812235145b726ba3e53cc8957
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784284Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63551}
      64bf0705
    • 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
    • Clemens Hammacher's avatar
      Rename some "address" to "hint" · e6cc1fc0
      Clemens Hammacher authored
      The "address" pointer we pass to {Allocate} and {AllocatePages}
      functions is actually just a hint. The actual address of the
      reservation is returned by the function.
      This CL renames the {address} argument of those functions to {hint} to
      make this semantic more clear.
      
      R=mlippautz@chromium.org
      
      Bug: v8:9396
      Change-Id: I9ff3785ea4e6f9b7d77f26f224445f3f92e11f22
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784280Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63549}
      e6cc1fc0