1. 17 Oct, 2016 1 commit
  2. 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
  3. 29 Jun, 2016 2 commits
  4. 22 Jun, 2016 1 commit
  5. 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
  6. 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
  7. 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
  8. 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
  9. 17 Dec, 2015 1 commit
  10. 19 Oct, 2015 1 commit
  11. 25 Jun, 2015 1 commit
  12. 05 Jun, 2015 1 commit
  13. 20 Apr, 2015 1 commit
  14. 13 Mar, 2015 1 commit
  15. 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
  16. 12 Dec, 2014 1 commit
  17. 30 Oct, 2014 1 commit
  18. 26 Sep, 2014 1 commit
  19. 24 Sep, 2014 2 commits
  20. 23 Sep, 2014 1 commit
  21. 19 Sep, 2014 1 commit