1. 06 Apr, 2022 1 commit
  2. 22 Mar, 2022 1 commit
    • Darius M's avatar
      Reland^2 [compiler] Simplify "==0" branches in MachineOperatorReducer · 0719ace6
      Darius M authored
      This is a reland of 6b690a6b.
      
      The previous version of this CL was a bit too aggressive in the
      duplication of branch conditions. This caused an increase in
      register pressure in some cases, thus reducing performance.
      
      In fact, duplicating branch conditions that require an "== 0" to be
      added provides no benefits. We are thus now a bit less aggressive, and
      only duplicate comparisons.
      
      Original change's description:
      > Reland [compiler] Simplify "==0" branches in MachineOperatorReducer
      >
      > This is a reland of 48b443f6.
      >
      > While fixing the initial CL, we stumbled upon a few bugs that
      > we had to fix:
      >
      >  - CommonOperatorReducer and SimplifiedOperatorReducer were applied
      >    before and after SimplifiedLowering, but always assumed that it
      >    was before SimplifiedLowering, and thus had the wrong semantics
      >    for branches in some cases. They now have an added parameter to
      >    know which semantics of branch they should use.
      >
      >  - The lowering of StaticAssert was wrong and could leave kHeapConstant
      >    in the assert (instead of machine Booleans).
      >
      > Original change's description:
      > > [compiler] Simplify "==0" branches in MachineOperatorReducer
      > >
      > > Bug: v8:12484
      > > Change-Id: I0667c7464c0dd71338bc199a24a69248a7a0a525
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497303
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Owners-Override: Tobias Tebbi <tebbi@chromium.org>
      > > Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      > > Cr-Commit-Position: refs/heads/main@{#79379}
      >
      > Bug: v8:12484
      > Change-Id: Ibbf5df96fce5ccb04868dc517539479bf69f5703
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516869
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79528}
      
      Bug: v8:12484
      Change-Id: I31f575a59811a83c7c1acb4c14bf5ded63a8f536
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540102Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79560}
      0719ace6
  3. 21 Mar, 2022 1 commit
    • Darius Mercadier's avatar
      Revert "Reland [compiler] Simplify "==0" branches in MachineOperatorReducer" · b3a91634
      Darius Mercadier authored
      This reverts commit 6b690a6b.
      
      Reason for revert: causes a few regressions here https://chromeperf.appspot.com/group_report?rev=79528
      
      Original change's description:
      > Reland [compiler] Simplify "==0" branches in MachineOperatorReducer
      >
      > This is a reland of 48b443f6.
      >
      > While fixing the initial CL, we stumbled upon a few bugs that
      > we had to fix:
      >
      >  - CommonOperatorReducer and SimplifiedOperatorReducer were applied
      >    before and after SimplifiedLowering, but always assumed that it
      >    was before SimplifiedLowering, and thus had the wrong semantics
      >    for branches in some cases. They now have an added parameter to
      >    know which semantics of branch they should use.
      >
      >  - The lowering of StaticAssert was wrong and could leave kHeapConstant
      >    in the assert (instead of machine Booleans).
      >
      > Original change's description:
      > > [compiler] Simplify "==0" branches in MachineOperatorReducer
      > >
      > > Bug: v8:12484
      > > Change-Id: I0667c7464c0dd71338bc199a24a69248a7a0a525
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497303
      > > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > > Owners-Override: Tobias Tebbi <tebbi@chromium.org>
      > > Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      > > Cr-Commit-Position: refs/heads/main@{#79379}
      >
      > Bug: v8:12484
      > Change-Id: Ibbf5df96fce5ccb04868dc517539479bf69f5703
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516869
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79528}
      
      Bug: v8:12484
      Change-Id: I457464d793e9c5af8448564aa3b46be863b96fbb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3540148
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79552}
      b3a91634
  4. 18 Mar, 2022 1 commit
    • Darius M's avatar
      Reland [compiler] Simplify "==0" branches in MachineOperatorReducer · 6b690a6b
      Darius M authored
      This is a reland of 48b443f6.
      
      While fixing the initial CL, we stumbled upon a few bugs that
      we had to fix:
      
       - CommonOperatorReducer and SimplifiedOperatorReducer were applied
         before and after SimplifiedLowering, but always assumed that it
         was before SimplifiedLowering, and thus had the wrong semantics
         for branches in some cases. They now have an added parameter to
         know which semantics of branch they should use.
      
       - The lowering of StaticAssert was wrong and could leave kHeapConstant
         in the assert (instead of machine Booleans).
      
      Original change's description:
      > [compiler] Simplify "==0" branches in MachineOperatorReducer
      >
      > Bug: v8:12484
      > Change-Id: I0667c7464c0dd71338bc199a24a69248a7a0a525
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497303
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Owners-Override: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#79379}
      
      Bug: v8:12484
      Change-Id: Ibbf5df96fce5ccb04868dc517539479bf69f5703
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516869Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#79528}
      6b690a6b
  5. 25 Jun, 2021 1 commit
  6. 26 Apr, 2021 2 commits
    • Jakob Gruber's avatar
      [compiler] Remove --turbo-direct-heap-access · 4f2f14f8
      Jakob Gruber authored
      On a per-job basis, --turbo-direct-heap-access should be equal to
      whether concurrent inlining is enabled. We simplify involved logic by
      removing the flag, and replacing all access to
      
      - FLAG_turbo_direct_heap_access, and
      - FLAG_concurrent_inlining
      
      inside compiler/ with
      OptimizedCompilationInfo::is_concurrent_inlining() (or derived values).
      
      Bug: v8:7790
      Change-Id: I64818e0e1004dded08c784ef1c4bdfd2af990a59
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2843345
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74166}
      4f2f14f8
    • Jakob Gruber's avatar
      [compiler] Refactor HeapObjectRef::BooleanValue paths · 0bc71bc9
      Jakob Gruber authored
      .. which used to be implemented by calling BooleanValue eagerly on all
      seen heap objects during serialization. 1) it's wasteful to call this
      on every object, 2) this was blocking conversion of HeapObjectRefs to
      not require main-thread serialization.
      
      This CL replaces the old pattern by a thread-safe TryGetBooleanValue
      method, which may fail in some cases (e.g. when trying to read into a
      HeapNumber).
      
      Bug: v8:7790
      Change-Id: I9d4ab7725231adce0b488c4c08c1f4bac78ce3c5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2839557
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74165}
      0bc71bc9
  7. 19 Mar, 2021 1 commit
  8. 18 Mar, 2021 1 commit
    • Manos Koukoutos's avatar
      Revert "[turbofan] Optimize TrapIf/Unless in BranchElim. and CommonOp-Reducer" · f4473d98
      Manos Koukoutos authored
      This reverts commit a3b1233e.
      
      Reason for revert: This approach has multiple issues and we have to reconsider it.
      
      Original change's description:
      > [turbofan] Optimize TrapIf/Unless in BranchElim. and CommonOp-Reducer
      >
      > Bug: v8:11510
      > Change-Id: I1e8fcb54444e494c7d765ad556d09d954441361f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752876
      > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73468}
      
      Bug: v8:11510
      Change-Id: Id35bc4ebcb45a617f61993d857ad2291b0287ad6
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2772600
      Auto-Submit: Manos Koukoutos <manoskouk@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@{#73502}
      f4473d98
  9. 17 Mar, 2021 1 commit
  10. 03 Dec, 2020 1 commit
    • Leszek Swirski's avatar
      [compiler] Remove disallow scopes · a6f465d4
      Leszek Swirski authored
      TurboFan creates DisallowHeapAccess scopes, to prevent heap access in
      the concurrent parts of the compiler. Then, for parts of the compiler
      that do want to access the heap, it either creates Allow* scopes (which
      should be avoided since they "punch a hole" in the Disallow* scopes), or
      relies on a weakening of Handle::IsDereferenceAllowed which allows
      handles owned by a LocalHeap to be dereferenced even if there is a
      DisallowHeapDereference scope.
      
      This patch:
      
        a) Strengthens the implicit requirements around handle dereferencing
           to require a running heap on this thread (either main-thread heap
           or an un-parked, un-safepointed LocalHeap).
        b) Removes the overly strict Disallow scopes in TurboFan, relying
           instead on implicit requirements for allocation/handle
           dereferencing in off-thread code.
        c) Cleans up the "should_disallow_heap_access" predicate to be more
           explicit about what should be disallowed (e.g. property accesses
           can't be computed concurrently)
      
      Change-Id: Icb56b7764913ac17e2db197a70bb189af88a6978
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2554617
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71600}
      a6f465d4
  11. 28 Oct, 2020 1 commit
  12. 20 Apr, 2020 1 commit
  13. 25 Mar, 2020 1 commit
    • Seth Brenith's avatar
      Revert "Move branch inversion on ==0 into platform-agnostic reducer" · 252acd7f
      Seth Brenith authored
      This reverts commit 0c72c719.
      
      Reason for revert: Wasm code size increase because not all pipelines use CommonOperatorReducer
      
      Original change's description:
      > Move branch inversion on ==0 into platform-agnostic reducer
      > 
      > This change is based on a discussion from
      > https://crrev.com/c/v8/v8/+/2053769/4/src/compiler/machine-operator-reducer.cc#1696
      > wherein Tobias suggested moving the folding away of ==0 operations out
      > of the platform-specific instruction selectors and into the
      > MachineOperatorReducer. I noticed that CommonOperatorReducer already
      > handles some very similar cases, so I have tried putting the ==0 folding
      > into CommonOperatorReducer instead. I'm happy to move it into
      > MachineOperatorReducer if that's better; I still don't have a very good
      > understanding of how roles are separated among reducers.
      > 
      > Change-Id: Ia0285bd9fafeef29d87cc88654bd6d355d467e8f
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2076498
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66688}
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: chromium:1061767
      Change-Id: Id1fdfb38357eb514d92ed3be0a683f077202faa4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2117789
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66862}
      252acd7f
  14. 17 Mar, 2020 1 commit
  15. 12 Mar, 2020 1 commit
  16. 25 Jun, 2019 1 commit
  17. 06 May, 2019 1 commit
  18. 15 Oct, 2018 1 commit
  19. 23 Jul, 2018 1 commit
  20. 17 Jul, 2018 1 commit
  21. 10 Jul, 2018 2 commits
  22. 25 May, 2018 1 commit
  23. 02 Mar, 2018 1 commit
  24. 01 Feb, 2018 1 commit
  25. 23 Jan, 2018 1 commit
  26. 11 Dec, 2017 1 commit
  27. 10 Feb, 2017 1 commit
  28. 09 Feb, 2017 2 commits
  29. 01 Feb, 2017 1 commit
    • bmeurer's avatar
      [turbofan] Also push Return into Merge even if there's no EffectPhi. · 44cac16f
      bmeurer authored
      We already had an optimization in the CommonOperatorReducer that would
      duplicate a Return with Phi, EffectPhi and Merge inputs into the
      respective branches. But we can also do the same if the effect input of
      the Return dominates all branches, i.e. if the Return and Phi nodes are
      the only users of the Merge node.
      
      This helps with the awkward code generation that we currently observe
      for || and && in return position.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2668903002
      Cr-Commit-Position: refs/heads/master@{#42839}
      44cac16f
  30. 17 Jan, 2017 1 commit
  31. 10 Jan, 2017 1 commit
    • leszeks's avatar
      [turbofan] Allow indexed access to node inputs/input_edges · 6873f14b
      leszeks authored
      Node::InputCount() and ::InputAt() have to check for inline/out-of-line
      inputs every time they are called. The compiler doesn't seem to be very
      good at caching the result of this check, meaning that it (and all its
      jumps) would happen for every node access.
      
      Previously we would get around this sometimes, by using Node::inputs(),
      which returned a Node::Inputs iterable over node inputs. However,
      sometimes node access is more convenient using an index, or we also
      want to access the count. This patch adds an index accessor and 'count'
      method to Node::Inputs, and replaces several uses of InputCount and
      InputAt with this accessor.
      
      Review-Url: https://codereview.chromium.org/2617123002
      Cr-Commit-Position: refs/heads/master@{#42179}
      6873f14b
  32. 03 Jan, 2017 1 commit
  33. 02 Nov, 2016 2 commits
    • danno's avatar
      [turbofan] Support variable size argument removal in TF-generated functions · fe552636
      danno authored
      This is preparation for using TF to create builtins that handle variable number of
      arguments and have to remove these arguments dynamically from the stack upon
      return.
      
      The gist of the changes:
      - Added a second argument to the Return node which specifies the number of stack
        slots to pop upon return in addition to those specified by the Linkage of the
        compiled function.
      - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
        handles all tail-call cases except where the return value type differs, this fallback
        was not really useful and in fact caused unexpected behavior with variable
        sized argument popping, since it wasn't possible to materialize a Return node
        with the right pop count from the TailCall without additional context.
      - Modified existing Return generation to pass a constant zero as the additional
        pop argument since the variable pop functionality
      
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2446543002
      Cr-Commit-Position: refs/heads/master@{#40699}
      fe552636
    • machenbach's avatar
      Revert of [turbofan] Support variable size argument popping in TF-generated... · c61902e0
      machenbach authored
      Revert of [turbofan] Support variable size argument popping in TF-generated functions (patchset #13 id:240001 of https://codereview.chromium.org/2446543002/ )
      
      Reason for revert:
      Seems to break arm64 sim debug and blocks roll:
      https://build.chromium.org/p/client.v8.ports/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/builds/3294
      
      Original issue's description:
      > [turbofan] Support variable size argument removal in TF-generated functions
      >
      > This is preparation for using TF to create builtins that handle variable number of
      > arguments and have to remove these arguments dynamically from the stack upon
      > return.
      >
      > The gist of the changes:
      > - Added a second argument to the Return node which specifies the number of stack
      >   slots to pop upon return in addition to those specified by the Linkage of the
      >   compiled function.
      > - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
      >   handles all tail-call cases except where the return value type differs, this fallback
      >   was not really useful and in fact caused unexpected behavior with variable
      >   sized argument popping, since it wasn't possible to materialize a Return node
      >   with the right pop count from the TailCall without additional context.
      > - Modified existing Return generation to pass a constant zero as the additional
      >   pop argument since the variable pop functionality
      >
      > LOG=N
      
      TBR=bmeurer@chromium.org,mstarzinger@chromium.org,epertoso@chromium.org,danno@chromium.org
      # Not skipping CQ checks because original CL landed more than 1 days ago.
      NOPRESUBMIT=true
      
      Review-Url: https://codereview.chromium.org/2473643002
      Cr-Commit-Position: refs/heads/master@{#40691}
      c61902e0
  34. 31 Oct, 2016 1 commit
    • danno's avatar
      [turbofan] Support variable size argument removal in TF-generated functions · 5319b50c
      danno authored
      This is preparation for using TF to create builtins that handle variable number of
      arguments and have to remove these arguments dynamically from the stack upon
      return.
      
      The gist of the changes:
      - Added a second argument to the Return node which specifies the number of stack
        slots to pop upon return in addition to those specified by the Linkage of the
        compiled function.
      - Removed Tail -> Non-Tail fallback in the instruction selector. Since TF now should
        handles all tail-call cases except where the return value type differs, this fallback
        was not really useful and in fact caused unexpected behavior with variable
        sized argument popping, since it wasn't possible to materialize a Return node
        with the right pop count from the TailCall without additional context.
      - Modified existing Return generation to pass a constant zero as the additional
        pop argument since the variable pop functionality
      
      LOG=N
      
      Review-Url: https://codereview.chromium.org/2446543002
      Cr-Commit-Position: refs/heads/master@{#40678}
      5319b50c
  35. 05 Sep, 2016 1 commit
  36. 22 Jul, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Change Float64Max/Float64Min to JavaScript semantics. · ba092fb0
      bmeurer authored
      So far we don't have a useful way to inline Math.max or Math.min in
      TurboFan optimized code. This adds new operators NumberMax and NumberMin
      and changes the Float64Max/Float64Min operators to have JavaScript
      semantics instead of the C++ semantics that it had previously.
      
      This also removes support for recognizing the tenary case in the
      CommonOperatorReducer, since that doesn't seem to have any positive
      impact (and actually doesn't show up in regular JavaScript, where
      people use Math.max/Math.min instead).
      
      Drive-by-fix: Also nuke the unused Float32Max/Float32Min operators.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2170343002
      Cr-Commit-Position: refs/heads/master@{#37971}
      ba092fb0