1. 01 Feb, 2019 1 commit
    • Clemens Hammacher's avatar
      [test] Modernize value helpers · f0d69fc9
      Clemens Hammacher authored
      This CL changes the usage pattern from
      FOR_XXX_VALUES(i) { Use(*i); }
      to
      FOR_XXX_VALUES(i) { Use(i); }
      which is way more intuitive.
      
      Note that the replacement in the uses was done via regular expression,
      so it's purely mechanical. In two locations I removed unneeded braces
      around the macro, because they confused clang-format.
      I plan to do more cleanups (remove redundant assignments within the
      FOR_XXX_VALUES body) in a follow-up CL.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:8562
      Change-Id: I4329bfcf34e5b077d19b50f4204ceb3b4340fe61
      Reviewed-on: https://chromium-review.googlesource.com/c/1449615
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59287}
      f0d69fc9
  2. 20 Dec, 2018 1 commit
  3. 27 Sep, 2018 1 commit
  4. 11 Sep, 2018 1 commit
  5. 27 Jun, 2018 1 commit
  6. 27 Apr, 2018 1 commit
    • Clemens Hammacher's avatar
      [test] Fix CHECK_DOUBLE_EQ and CHECK_FLOAT_EQ · fa0e55e2
      Clemens Hammacher authored
      Both macros currently call a function with individual CHECKs, which
      makes error messages only show that one part of the equality check (and
      not the the actual float values), and hides the actual location of the
      check.
      This CL refactors this such that the actual value is shown (just as
      with other CHECK_EQ macros) and it shows the right file name and line
      number.
      
      R=ahaas@chromium.org
      
      Bug: v8:7570
      Change-Id: I198e73c053178a09f14330a18069463760693f81
      Reviewed-on: https://chromium-review.googlesource.com/1027879Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52832}
      fa0e55e2
  7. 05 Mar, 2018 2 commits
  8. 02 Dec, 2017 1 commit
    • Mathias Bynens's avatar
      Normalize casing of hexadecimal digits · 822be9b2
      Mathias Bynens authored
      This patch normalizes the casing of hexadecimal digits in escape
      sequences of the form `\xNN` and integer literals of the form
      `0xNNNN`.
      
      Previously, the V8 code base used an inconsistent mixture of uppercase
      and lowercase.
      
      Google’s C++ style guide uses uppercase in its examples:
      https://google.github.io/styleguide/cppguide.html#Non-ASCII_Characters
      
      Moreover, uppercase letters more clearly stand out from the lowercase
      `x` (or `u`) characters at the start, as well as lowercase letters
      elsewhere in strings.
      
      BUG=v8:7109
      TBR=marja@chromium.org,titzer@chromium.org,mtrofin@chromium.org,mstarzinger@chromium.org,rossberg@chromium.org,yangguo@chromium.org,mlippautz@chromium.org
      NOPRESUBMIT=true
      
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I790e21c25d96ad5d95c8229724eb45d2aa9e22d6
      Reviewed-on: https://chromium-review.googlesource.com/804294
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49810}
      822be9b2
  9. 20 Oct, 2017 1 commit
    • Clemens Hammacher's avatar
      Reland "[test] Add nan bit patterns to uint{32,64}_vector" · bd19ea4a
      Clemens Hammacher authored
      This is a reland of 6f93d59d.
      One more test had to be disabled (tracked by bug 6954), and
      two machops tests needed to be changed to use boxed floats
      and doubles.
      
      Original change's description:
      > [test] Add nan bit patterns to uint{32,64}_vector
      > 
      > If you just cast those patterns to float or double and pass them
      > around, the quiet/signaling NaN bit might change. We had several bugs
      > around this, so add these patterns to the general input vectors.
      > 
      > This uncovers a bug in the wasm interpreter, which will be fixed in a
      > separate CL.
      > 
      > R=ahaas@chromium.org
      > 
      > Bug: v8:6947, v8:6954
      > Change-Id: I205b8ab784b087b1e4988190fa725df0b90e7ee0
      > Reviewed-on: https://chromium-review.googlesource.com/725345
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Andreas Haas <ahaas@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48731}
      
      Bug: v8:6947, v8:6954
      Change-Id: I9a38b5d9324131c3950c537910371a73c93d2c13
      Reviewed-on: https://chromium-review.googlesource.com/728439Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48780}
      bd19ea4a
  10. 19 Oct, 2017 3 commits
  11. 18 Oct, 2017 2 commits
    • Clemens Hammacher's avatar
      Revert "[test] Avoid unnecessary std::vector allocations" · ab639e4a
      Clemens Hammacher authored
      This reverts commit e737b4ce.
      
      Reason for revert: On windows, V8_INFINITY is not constexpr
      
      Original change's description:
      > [test] Avoid unnecessary std::vector allocations
      > 
      > Instead of copying an array of fixed values into an std::vector for
      > each usage of the FOR_INPUTS macro, just iterate the constant data
      > directly.
      > This also makes the <type>_vector() functions return {constexpr Vector}
      > instead of {std::vector}.
      > 
      > R=​tebbi@chromium.org
      > 
      > Change-Id: Ifc3e5509b2fbf5e383c967c2f46acf2b07f7b5b4
      > Reviewed-on: https://chromium-review.googlesource.com/725427
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#48688}
      
      TBR=clemensh@chromium.org,tebbi@chromium.org
      
      Change-Id: Iccb52941d4efe71b49b41572c3d922a5d78bdfd2
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/725899Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48691}
      ab639e4a
    • Clemens Hammacher's avatar
      [test] Avoid unnecessary std::vector allocations · e737b4ce
      Clemens Hammacher authored
      Instead of copying an array of fixed values into an std::vector for
      each usage of the FOR_INPUTS macro, just iterate the constant data
      directly.
      This also makes the <type>_vector() functions return {constexpr Vector}
      instead of {std::vector}.
      
      R=tebbi@chromium.org
      
      Change-Id: Ifc3e5509b2fbf5e383c967c2f46acf2b07f7b5b4
      Reviewed-on: https://chromium-review.googlesource.com/725427Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48688}
      e737b4ce
  12. 01 Sep, 2017 1 commit
  13. 02 Aug, 2017 1 commit
  14. 26 Jan, 2017 1 commit
  15. 22 Aug, 2016 1 commit
  16. 12 Jul, 2016 1 commit
  17. 30 Jun, 2016 1 commit
    • ahaas's avatar
      [wasm] Detect unrepresentability in the float32-to-int32 conversion correctly on arm. · de369129
      ahaas authored
      In the current implementation of wasm an unrepresentable input of the
      float32-to-int32 conversion is detected by first truncating the input, then
      converting the truncated input to int32 and back to float32, and then checking
      whether the result is the same as the truncated input.
      
      This input check does not work on arm and arm64 for an input of (INT32_MAX + 1)
      because on these platforms the float32-to-int32 conversion results in INT32_MAX
      if the input is greater than INT32_MAX.  When INT32_MAX is converted back to
      float32, then the result is (INT32_MAX + 1) again because INT32_MAX cannot be
      represented precisely as float32, and rounding-to-nearest results in (INT32_MAX
      + 1). Since (INT32_MAX + 1) equals the truncated input value, the input appears
      to be representable.
      
      With the changes in this CL, the result of the float32-to-int32 conversion is
      incremented by 1 if the original result was INT32_MAX. Thereby the detection of
      unrepresenable inputs in wasm works. Note that since INT32_MAX cannot be
      represented precisely in float32, it can also never be a valid result of the
      float32-to-int32 conversion.
      
      @v8-mips-ports, can you do a similar implementation for mips?
      
      R=titzer@chromium.org, Rodolph.Perfetta@arm.com
      
      Review-Url: https://codereview.chromium.org/2105313002
      Cr-Commit-Position: refs/heads/master@{#37448}
      de369129
  18. 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
  19. 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
  20. 31 Mar, 2016 1 commit
  21. 07 Mar, 2016 1 commit
    • ahaas's avatar
      x87: fix the use of CheckFloatEq and CheckDoubleEq in test. · a5d41888
      ahaas authored
      Instead of using CheckFloatEq and CheckDoubleEq directly, I introduced
      a macro which first stores the expected result in a volatile variable.
      
      Here are some comments of previous CLs:
      
      The reason is same as the CL #31808 (issue 1430943002, X87: Change the test case for X87 float operations), please refer: https://codereview.chromium.org/1430943002/.
      
        Here is the key comments from CL #31808
        Some new test cases use CheckFloatEq(...) and CheckDoubleEq(...) function for result check. When GCC compiling the CheckFloatEq() and CheckDoubleEq() function,
        those inlined functions has different behavior comparing with GCC ia32 build and x87 build.
        The major difference is sse float register still has single precision rounding semantic. While X87 register has no such rounding precsion semantic when directly use register value.
        The V8 turbofan JITTed has exactly same result in both X87 and IA32 port.
      
        So we add the following sentence to do type cast to keep the same precision for RunCallInt64ToFloat32/RunCallInt64ToFloat64. Such as: volatile double expect = static_cast<float>(*i).
      
      R=titzer@chromium.org, weiliang.lin@intel.com
      
      Review URL: https://codereview.chromium.org/1773513002
      
      Cr-Commit-Position: refs/heads/master@{#34534}
      a5d41888
  22. 18 Feb, 2016 1 commit
  23. 18 Jan, 2016 2 commits
    • ahaas's avatar
      Revert of [turbofan] Implement rounding of floats on x64 and ia32 without... · 900b2933
      ahaas authored
      Revert of [turbofan] Implement rounding of floats on x64 and ia32 without sse4.1. (patchset #2 id:20001 of https://codereview.chromium.org/1584663007/ )
      
      Reason for revert:
      Code is incorrect for -0.
      
      Original issue's description:
      > [turbofan] Implement rounding of floats on x64 and ia32 without sse4.1.
      >
      > The implementation sets the rounding mode flag and then uses the
      > cvtsd2si and cvtsi2sd instructions (convert between float and int) to do
      > the rounding. Input values outside int range either don't have to be
      > rounded anyways, or are rounded by calculating input + 2^52 - 2^52 for
      > positive inputs, or input -2^52 + 2^52 for negative inputs. The original
      > rounding mode is restored afterwards.
      >
      > R=titzer@chromium.org
      >
      > B=575379
      >
      > Committed: https://crrev.com/fa5d09e547abe79a8c82f780deb980c53ad78beb
      > Cr-Commit-Position: refs/heads/master@{#33367}
      
      TBR=titzer@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      
      Review URL: https://codereview.chromium.org/1593313010
      
      Cr-Commit-Position: refs/heads/master@{#33369}
      900b2933
    • ahaas's avatar
      [turbofan] Implement rounding of floats on x64 and ia32 without sse4.1. · fa5d09e5
      ahaas authored
      The implementation sets the rounding mode flag and then uses the
      cvtsd2si and cvtsi2sd instructions (convert between float and int) to do
      the rounding. Input values outside int range either don't have to be
      rounded anyways, or are rounded by calculating input + 2^52 - 2^52 for
      positive inputs, or input -2^52 + 2^52 for negative inputs. The original
      rounding mode is restored afterwards.
      
      R=titzer@chromium.org
      
      B=575379
      
      Review URL: https://codereview.chromium.org/1584663007
      
      Cr-Commit-Position: refs/heads/master@{#33367}
      fa5d09e5
  24. 17 Dec, 2015 1 commit
  25. 16 Dec, 2015 1 commit
  26. 11 Dec, 2015 1 commit
    • ahaas's avatar
      [turbofan] Change TruncateFloat32ToUint64 to TryTruncateFloat32ToUint64. · 97161a29
      ahaas authored
      TryTruncateFloat32ToUint64 converts a float32 to a uint64. Additionally it
      provides an optional second return value which indicates whether the conversion
      succeeded (i.e. float32 value was within uint64 range) or not.
      
      I implemented the new operator on x64, arm64, and mips64. @v8-ppc-ports, can you
      please take care of the ppc64 implementation of the second output?
      
      Additionally I fixed a bug on x64 and mips64 in the implementation of
      TryTruncateFloat64ToUint64. Cases where the input value was between -1 and 0
      were handled incorrectly.
      
      R=titzer@chromium.org, v8-arm-ports@googlegroups.com, v8-mips-ports@googlegroups.com
      
      Review URL: https://codereview.chromium.org/1512023002
      
      Cr-Commit-Position: refs/heads/master@{#32796}
      97161a29
  27. 09 Dec, 2015 1 commit
    • ahaas's avatar
      [turbofan] Change TruncateFloat64ToUint64 to TryTruncateFloatToUint64. · c343f309
      ahaas authored
      This operator now provides a second output which indicates whether the conversion from float64 to uint64 was successful or not. The second output returns 0 if the conversion fails, or something else if the conversion succeeds.
      
      The second output can be ignored, which means that the operator can be used the same as the original operator.
      
      I implement the new operator on x64 and arm64. @v8-mips-ports and @v8-ppc-ports, can you please take care of the mips64 and ppc64 implementation of the second output?
      
      R=titzer@chromium.org, v8-arm-ports@googlegroups.com
      
      Review URL: https://codereview.chromium.org/1507703002
      
      Cr-Commit-Position: refs/heads/master@{#32705}
      c343f309
  28. 12 Nov, 2015 1 commit
  29. 28 Oct, 2015 1 commit
  30. 23 Sep, 2015 1 commit
  31. 31 Aug, 2015 1 commit
    • mstarzinger's avatar
      [turbofan] Remove usage of Unique<T> from graph. · 6e65e6db
      mstarzinger authored
      The usage of Unique<T> throughout the TurboFan IR does not have any
      advantage. There is no single point in time when they are initialized
      and most use-sites looked through to the underlying Handle<T> anyways.
      Also there already was a mixture of Handle<T> versus Unique<T> in the
      graph and this unifies the situation to use Handle<T> everywhere.
      
      R=bmeurer@chromium.org,titzer@chromium.org
      
      Review URL: https://codereview.chromium.org/1314473007
      
      Cr-Commit-Position: refs/heads/master@{#30458}
      6e65e6db
  32. 08 Apr, 2015 1 commit
  33. 30 Jan, 2015 2 commits