1. 18 Oct, 2018 1 commit
  2. 15 Oct, 2018 1 commit
  3. 23 Jul, 2018 1 commit
  4. 10 Jul, 2018 1 commit
  5. 11 Jul, 2017 1 commit
    • Alexandre Talon's avatar
      [Turbofan] Enable reducers to report their name to make reducer tracing clearer · 7a75da34
      Alexandre Talon authored
      Each reducer now has a virtual reducer_name function, returning its name
      (the name of the class containing this reducer). This gets displayed when
      using the --trace_turbo_reduction flag. Also when using this flags more
      messages are displayed.
      
      Actually when a node is replaced in-place (which is called an update
      of the node), other reducers can still update it right after the
      in-place replacement. When a node is really replaced (not in-place),
      then we stop trying to apply reducers to it before we propagate the
      reduction through the relevant nodes.
      
      Before a message got printed only for the last reduction it went
      through. So in case a node was reduced in-place several times
      in a row, only the last update was printed, or none at all if after
      being reduced in-place it got reduced by being replaced by another
      node: only the non-in-place replacement was showed. 
      
      Now each time an in-place reduction is applied to a node, a message
      gets printed.
      
      Bug: 
      Change-Id: Id0f816fecd44c01d0253966c6decc4861be0c2fa
      Reviewed-on: https://chromium-review.googlesource.com/563365Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Alexandre Talon <alexandret@google.com>
      Cr-Commit-Position: refs/heads/master@{#46552}
      7a75da34
  6. 17 Oct, 2016 1 commit
  7. 30 Jun, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce CheckIf simplified operator. · 483291d2
      bmeurer authored
      This adds a new CheckIf operator and changes all direct uses of
      DeoptimizeIf and DeoptimizeUnless on the JavaScript level to use
      CheckIf (or one of the more concrete check operators) instead.
      This way we do not depend on particular frame states, but the
      effect/control linearizer will assign an appropriate frame
      state instead.
      
      R=jarin@chromium.org
      BUG=v8:5141
      
      Review-Url: https://codereview.chromium.org/2115513002
      Cr-Commit-Position: refs/heads/master@{#37423}
      483291d2
  8. 29 Jun, 2016 2 commits
  9. 22 Jun, 2016 1 commit
  10. 08 Jun, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Do strength reduction for ObjectIsSmi based on inputs. · c91c3961
      bmeurer authored
      Ideally we would have a dedicated MachineRepresentation for Smis during
      representation selection and use that to properly optimize ObjectIsSmi
      (and other ObjectIs<Type> predicates), but that will take some time to
      get that done. So in the meantime we can just do simple (local) strength
      reduction on ObjectIsSmi to avoid Smi checks in the simplest cases at
      least.
      
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/2047213002
      Cr-Commit-Position: refs/heads/master@{#36809}
      c91c3961
  11. 18 May, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Turn common Guard operator into simplified TypeGuard. · c5a71f02
      bmeurer authored
      The type guard should never be used after the effect/control
      linearization pass, so making it a simplified operator better
      expresses the intended use. Also this way none of the common
      operators actually has any dependency on the type system.
      
      Drive-by-fix: Properly print the type parameter to a TypeGuard operator.
      
      BUG=chromium:612142
      R=jarin@chromium.org
      
      Review-Url: https://codereview.chromium.org/1994503002
      Cr-Commit-Position: refs/heads/master@{#36304}
      c5a71f02
  12. 30 Mar, 2016 1 commit
    • bmeurer's avatar
      [builtins] Make Math.ceil, Math.trunc and Math.round optimizable. · 8d20f2fe
      bmeurer authored
      Migrate Math.ceil, Math.round and Math.trunc to TurboFan code stubs,
      similar to what we did with Math.floor, and make these builtins properly
      optimizable in TurboFan via appropriate simplified operators NumberCeil,
      NumberRound and NumberTrunc, which are intended to be reusable for
      ToInteger and ToLength optimizations that will be done in a followup CL.
      
      Also allows us to kill the funky %RoundNumber runtime function, which
      was quite heavy.
      
      Improve test coverage for Math.ceil and Math.trunc a lot, especially
      making sure that we also properly trigger the TurboFan builtin reducer
      case.
      
      R=jarin@chromium.org
      BUG=v8:4059
      LOG=n
      
      Review URL: https://codereview.chromium.org/1841993002
      
      Cr-Commit-Position: refs/heads/master@{#35135}
      8d20f2fe
  13. 29 Mar, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce NumberFloor simplified operator. · 43216574
      bmeurer authored
      The NumberFloor operator matches exactly the semantics of the Math.floor
      builtin on Numbers. It uses hardware rounding instructions if available,
      but provides a full fallback solution that is compatible with Math.floor.
      The lowering is optimizable based on types if needed later, i.e. we
      already optimize it for the case that the input is already an Integer
      (in the EcmaScript sense, including NaN and -0), but we could add more
      optimizations, like combining NumberFloor and NumberDivide in the
      future, if necessary.
      
      R=jarin@chromium.org
      BUG=v8:2890,v8:4059
      LOG=n
      
      Review URL: https://codereview.chromium.org/1843533003
      
      Cr-Commit-Position: refs/heads/master@{#35090}
      43216574
  14. 17 Dec, 2015 1 commit
  15. 19 Oct, 2015 1 commit
  16. 25 Jun, 2015 1 commit
  17. 05 Jun, 2015 1 commit
  18. 20 Apr, 2015 1 commit
  19. 13 Mar, 2015 1 commit
  20. 10 Mar, 2015 2 commits
    • bmeurer's avatar
      [turbofan] Use builtin inlining mechanism for Math.floor. · 1982186b
      bmeurer authored
      BUG=v8:3952
      LOG=n
      R=yangguo@chromium.org
      
      Review URL: https://codereview.chromium.org/997513002
      
      Cr-Commit-Position: refs/heads/master@{#27098}
      1982186b
    • bmeurer's avatar
      [turbofan] Unify Math.floor / Math.ceil optimization. · 022ea7e0
      bmeurer authored
      Provide an intrinsic %MathFloor / %_MathFloor that is used to optimize
      both Math.ceil and Math.floor, and use the JS inlining mechanism to
      inline Math.ceil into TurboFan code. Although we need to touch code
      outside of TurboFan to make this work, this does not affect the way we
      handle Math.ceil and/or Math.floor in CrankShaft, because for CrankShaft
      the old-style builtin function id based inlining still kicks in first.
      
      Once this solution is stabilized, we can use it for Math.floor as well.
      And once that is settled, we can establish it as the unified way to
      inline builtins, and get rid of the specialized builtin function id
      based inlining at some point.
      
      Note that "builtin" applies to basically every piece of internal
      JavaScript/intrinsics based code, so this also applies to the yet to be
      defined JavaScript based code stubs and handlers.
      
      BUG=v8:3953
      LOG=n
      R=yangguo@chromium.org,svenpanne@chromium.org
      
      Review URL: https://codereview.chromium.org/990963003
      
      Cr-Commit-Position: refs/heads/master@{#27086}
      022ea7e0
  21. 12 Dec, 2014 1 commit
  22. 30 Oct, 2014 1 commit
  23. 26 Sep, 2014 1 commit
  24. 24 Sep, 2014 2 commits
  25. 23 Sep, 2014 1 commit
  26. 19 Sep, 2014 1 commit