1. 14 Jul, 2017 1 commit
  2. 13 Jul, 2017 1 commit
  3. 23 Feb, 2017 1 commit
  4. 16 Feb, 2017 1 commit
    • Andreas Haas's avatar
      [turbofan] For Word32Shl optimizations only consider the last 5 bits of the shift · 5f1661aa
      Andreas Haas authored
      One optimization in the machine-operator-reducer did not consider that
      that word32 shift left instructions only consider the last 5 bits of
      the shift input.
      
      The issue only occurs for WebAssembly because in JavaScript we always
      add a "& 0xf" on the shift value to the TurboFan graph.
      
      For additional background: The JavaScript and WebAssembly spec both
      say that only the last 5 bits of the shift value are used in the
      word32-shift-left operation. This means that an "x << 0x29", in the
      code is actually executed as "x << 0x09". Therefore the changes in
      this CL are okay because they mask the last 5 bit of the shift value.
      
      BUG=chromium:689450
      
      Change-Id: Id92f298ed6d7f1714b109b3f4fbcecd5ac6d30f7
      Reviewed-on: https://chromium-review.googlesource.com/439312Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#43245}
      5f1661aa
  5. 03 Feb, 2017 1 commit
  6. 02 Feb, 2017 1 commit
  7. 01 Feb, 2017 1 commit
  8. 26 Jan, 2017 1 commit
    • ahaas's avatar
      [wasm] Fix constant folding with signalling NaN. · 55aed782
      ahaas authored
      According to the WebAssembly spec no arithmetic operation should ever
      return a signalling NaN. With the constant folding in V8, however, it
      was possible that some arithmetic operations were elided, and if the
      input of the arithmetic operation was a signalling NaN, then also the
      result was the same signalling NaN. This CL removes some constant
      folding optimizations and adjusts others so that even with constant
      folding the result of an arithmetic operation is never a signalling NaN.
      
      R=titzer@chromium.org, rossberg@chromium.org, bmeurer@chromium.org
      
      Review-Url: https://codereview.chromium.org/2647353007
      Cr-Commit-Position: refs/heads/master@{#42694}
      55aed782
  9. 04 Jan, 2017 1 commit
  10. 30 Nov, 2016 1 commit
  11. 27 Sep, 2016 1 commit
  12. 16 Sep, 2016 1 commit
  13. 13 Sep, 2016 1 commit
  14. 10 Aug, 2016 1 commit
  15. 08 Aug, 2016 1 commit
  16. 04 Aug, 2016 1 commit
  17. 03 Aug, 2016 1 commit
  18. 25 Jul, 2016 1 commit
  19. 22 Jul, 2016 1 commit
  20. 14 Jul, 2016 1 commit
  21. 01 Jul, 2016 1 commit
    • bmeurer's avatar
      [builtins] Unify most of the remaining Math builtins. · 0a0fe8fb
      bmeurer authored
      Import fdlibm versions of acos, acosh, asin and asinh, which are more
      precise and produce the same result across platforms (we were using
      libm versions for asin and acos so far, where both speed and precision
      depended on the operating system so far). Introduce appropriate TurboFan
      operators for these functions and use them both for inlining and for the
      generic builtin.
      
      Also migrate the Math.imul and Math.fround builtins to TurboFan builtins
      to ensure that their behavior is always exactly the same as the inlined
      TurboFan version (i.e. C++ truncation semantics for double to float
      don't necessarily meet the JavaScript semantics).
      
      For completeness, also migrate Math.sign, which can even get some nice
      love in TurboFan.
      
      Drive-by-fix: Some alpha-sorting on the Math related functions, and
      cleanup the list of Math intrinsics that we have to export via the
      native context currently.
      
      BUG=v8:3266,v8:3496,v8:3509,v8:3952,v8:5169,v8:5170,v8:5171,v8:5172
      TBR=rossberg@chromium.org
      R=franzih@chromium.org
      
      Review-Url: https://codereview.chromium.org/2116753002
      Cr-Commit-Position: refs/heads/master@{#37476}
      0a0fe8fb
  22. 30 Jun, 2016 1 commit
  23. 28 Jun, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce Float64Pow and NumberPow operators. · e607e12e
      bmeurer authored
      Introduce a new machine operator Float64Pow that for now is backed by
      the existing MathPowStub to start the unification of Math.pow, and at
      the same time address the main performance issue that TurboFan still has
      with the imaging-darkroom benchmark in Kraken.
      
      Also migrate the Math.pow builtin itself to a TurboFan builtin and
      remove a few hundred lines of hand-written platform code for special
      handling of the fullcodegen Math.pow version.
      
      BUG=v8:3599,v8:5086,v8:5157
      
      Review-Url: https://codereview.chromium.org/2103733003
      Cr-Commit-Position: refs/heads/master@{#37323}
      e607e12e
  24. 22 Jun, 2016 1 commit
  25. 20 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Introduce proper Float64Tan operator. · c87168bc
      bmeurer authored
      Import base::ieee754::tan() from fdlibm and introduce Float64Tan TurboFan
      operator based on that, similar to what we do for Float64Cos and Float64Sin.
      Rewrite Math.tan() as TurboFan builtin and use those operators to also
      inline Math.tan() into optimized TurboFan functions.
      
      Drive-by-fix: Kill the %_ConstructDouble intrinsics, and provide only
      the %ConstructDouble runtime entry for writing tests.
      
      BUG=v8:5086,v8:5126
      R=yangguo@chromium.org
      
      Review-Url: https://codereview.chromium.org/2083453002
      Cr-Commit-Position: refs/heads/master@{#37087}
      c87168bc
  26. 17 Jun, 2016 4 commits
  27. 16 Jun, 2016 3 commits
  28. 13 Jun, 2016 2 commits
    • bmeurer's avatar
      [builtins] Introduce proper Float64Atan and Float64Atan2 operators. · 89d8c57b
      bmeurer authored
      Import base::ieee754::atan() and base::ieee754::atan2() from fdlibm and
      introduce Float64Atan and Float64Atan2 TurboFan operators based on those,
      similar to what we already did for Float64Log and Float64Log1p. Rewrite
      Math.atan() and Math.atan2() as TurboFan builtin and use the operators
      to also inline Math.atan() and Math.atan2() into optimized TurboFan functions.
      
      R=yangguo@chromium.org
      BUG=v8:5086,v8:5095
      
      Review-Url: https://codereview.chromium.org/2065503002
      Cr-Commit-Position: refs/heads/master@{#36916}
      89d8c57b
    • bmeurer's avatar
      [builtins] Introduce proper Float64Log1p operator. · 7ceed92a
      bmeurer authored
      Import base::ieee754::log1p() from fdlibm and introduce a Float64Log1p
      TurboFan operator based on that, similar to what we do for Float64Log.
      Rewrite Math.log1p() as TurboFan builtin and use that operator to also
      inline Math.log1p() into optimized TurboFan functions.
      
      Also unify the handling of the special IEEE 754 functions somewhat in
      the TurboFan backends. At some point we can hopefully express this
      completely in the InstructionSelector (once we have an idea what to do
      with the ST(0) return issue on IA-32/X87).
      
      Drive-by-fix: Add some more test coverage for the log function.
      
      R=yangguo@chromium.org
      BUG=v8:5086,v8:5092
      
      Review-Url: https://codereview.chromium.org/2060743002
      Cr-Commit-Position: refs/heads/master@{#36914}
      7ceed92a
  29. 10 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Introduce proper base::ieee754::log. · d0c7775d
      bmeurer authored
      This switches Math.log to use an fdlibm based version of log, imported
      as base::ieee754::log, and use that consistently everywhere, i.e. change
      the Float64Log TurboFan operators on Intel to use the C++ implementation
      as well (same for Crankshaft).
      
      R=yangguo@chromium.org
      BUG=v8:5065,v8:5086
      
      Review-Url: https://codereview.chromium.org/2053893003
      Cr-Commit-Position: refs/heads/master@{#36880}
      d0c7775d
  30. 03 Jun, 2016 1 commit
    • bmeurer's avatar
      [builtins] Migrate Math.log to TurboFan. · f2da19fe
      bmeurer authored
      Introduce a dedicated Float64Log machine operator, that is either
      implemented by a direct C call or by platform specific code, i.e.
      using the FPU on x64 and ia32.
      
      This operator is used to implement Math.log as a proper TurboFan
      builtin on top of the CodeStubAssembler.
      
      Also introduce a NumberLog simplified operator on top of Float64Log
      and use that for the fast inline path of Math.log inside TurboFan
      optimized code.
      
      BUG=v8:5065
      
      Review-Url: https://codereview.chromium.org/2029413005
      Cr-Commit-Position: refs/heads/master@{#36703}
      f2da19fe
  31. 26 Apr, 2016 1 commit
  32. 24 Apr, 2016 1 commit
    • bmeurer's avatar
      [turbofan] Introduce TruncateTaggedToWord32 simplified operator. · 0231a7ef
      bmeurer authored
      This allows us to get rid of the "push TruncateFloat64ToInt32 into Phi"
      trick that was used in the MachineOperatorReducer to combine the
      ChangeTaggedToFloat64 and TruncateFloat64ToInt32 operations. Instead of
      doing that later, we can just introduce the proper operator during the
      representation selection directly.
      
      Also separate the TruncateFloat64ToInt32 machine operator, which had two
      different meanings depending on a flag (either JavaScript truncation or
      C++ style round to zero). Now there's a TruncateFloat64ToWord32 which
      represents the JavaScript truncation (implemented via TruncateDoubleToI
      macro + code stub) and the RoundFloat64ToInt32, which implements the C++
      round towards zero operation (in the same style as the other WebAssembly
      driven Round* machine operators).
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1919513002
      
      Cr-Commit-Position: refs/heads/master@{#35743}
      0231a7ef
  33. 11 Jan, 2016 1 commit
  34. 11 Dec, 2015 1 commit