1. 08 Feb, 2019 1 commit
    • Gus Caplan's avatar
      Reland^2 "[builtins] [turbofan] Refactor Float64Pow to use single implementation" · 98453126
      Gus Caplan authored
      This is a reland of d7def900
      
      Original change's description:
      > Reland "[builtins] [turbofan] Refactor Float64Pow to use single implementation"
      >
      > This is a reland of I968a08cef6a6d49350aa79185b2c6fb856d15f23
      >
      > Original change's description:
      > > [builtins] [turbofan] Refactor Float64Pow to use single implementation
      > >
      > > Remove platform-specific Float64Pow implementations and utils Pow in
      > > favor of a base::ieee754::pow implementation.
      > >
      > > This unifies the implementation of pow for the compiler, wasm, and
      > > runtime.
      > >
      > > Bug: v8:5848, v8:5086
      > > Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
      > > Reviewed-on: https://chromium-review.googlesource.com/c/1403018
      > > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Georg Neis <neis@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#59229}
      >
      > Bug: v8:5848, v8:5086
      > Change-Id: I92f22ae03adafd9ad042e8d4bb406cbd5b5fb51e
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
      > Reviewed-on: https://chromium-review.googlesource.com/c/1447854
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59411}
      
      Tbr: neis@chromium.org, bmeurer@chromium.org, jkummerow@chromium.org
      Bug: v8:5848, v8:5086
      Change-Id: I42972b29b8830ed47a00b2b1d408d3005a810c0e
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/1456302Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59454}
      98453126
  2. 06 Feb, 2019 2 commits
    • Sigurd Schneider's avatar
      Revert "Reland "[builtins] [turbofan] Refactor Float64Pow to use single implementation"" · d691fde3
      Sigurd Schneider authored
      This reverts commit d7def900.
      
      Reason for revert: Breaks UBSan:
      https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux64%20UBSan/4542
      
      Besides undefined behavior, things were looking good!
      
      
      Original change's description:
      > Reland "[builtins] [turbofan] Refactor Float64Pow to use single implementation"
      > 
      > This is a reland of I968a08cef6a6d49350aa79185b2c6fb856d15f23
      > 
      > Original change's description:
      > > [builtins] [turbofan] Refactor Float64Pow to use single implementation
      > >
      > > Remove platform-specific Float64Pow implementations and utils Pow in
      > > favor of a base::ieee754::pow implementation.
      > >
      > > This unifies the implementation of pow for the compiler, wasm, and
      > > runtime.
      > >
      > > Bug: v8:5848, v8:5086
      > > Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
      > > Reviewed-on: https://chromium-review.googlesource.com/c/1403018
      > > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > > Reviewed-by: Georg Neis <neis@chromium.org>
      > > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#59229}
      > 
      > Bug: v8:5848, v8:5086
      > Change-Id: I92f22ae03adafd9ad042e8d4bb406cbd5b5fb51e
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
      > Reviewed-on: https://chromium-review.googlesource.com/c/1447854
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59411}
      
      TBR=jkummerow@chromium.org,jarin@chromium.org,neis@chromium.org,jgruber@chromium.org,clemensh@chromium.org,bmeurer@chromium.org,me@gus.host
      
      Change-Id: I65c4bbd3ab7aaa1c396d182467c5a1fe6a639df5
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:5848, v8:5086
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/1456107Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59419}
      d691fde3
    • Gus Caplan's avatar
      Reland "[builtins] [turbofan] Refactor Float64Pow to use single implementation" · d7def900
      Gus Caplan authored
      This is a reland of I968a08cef6a6d49350aa79185b2c6fb856d15f23
      
      Original change's description:
      > [builtins] [turbofan] Refactor Float64Pow to use single implementation
      >
      > Remove platform-specific Float64Pow implementations and utils Pow in
      > favor of a base::ieee754::pow implementation.
      >
      > This unifies the implementation of pow for the compiler, wasm, and
      > runtime.
      >
      > Bug: v8:5848, v8:5086
      > Change-Id: I968a08cef6a6d49350aa79185b2c6fb856d15f23
      > Reviewed-on: https://chromium-review.googlesource.com/c/1403018
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#59229}
      
      Bug: v8:5848, v8:5086
      Change-Id: I92f22ae03adafd9ad042e8d4bb406cbd5b5fb51e
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_ubsan_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/1447854
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#59411}
      d7def900
  3. 31 Jan, 2019 2 commits
  4. 28 Jan, 2019 1 commit
  5. 11 Jan, 2019 1 commit
  6. 10 Jan, 2019 1 commit
  7. 13 Dec, 2018 1 commit
  8. 17 Sep, 2018 3 commits
    • Florian Sattler's avatar
      [cleanup] Refactor compiler to use default members. · 2c97e145
      Florian Sattler authored
      Fixing clang-tidy warning.
      
      Bug: v8:8015
      Change-Id: I7d885f0e2ba3cdf97de190166dc4cdd24dc0c11e
      Reviewed-on: https://chromium-review.googlesource.com/1224091
      Commit-Queue: Florian Sattler <sattlerf@google.com>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55956}
      2c97e145
    • Benedikt Meurer's avatar
      [turbofan] Initial support to compute NumberAdd/NumberSubtract in Word64. · 0c296cb2
      Benedikt Meurer authored
      This change introduces the necessary conversion operators to convert
      from Word64 to other representations (Tagged, Word32, Float64, etc.),
      and plugs in the Word64 representation for NumberAdd/NumberSubtract,
      such that TurboFan will go to Int64Add/Sub on 64-bit architectures
      when the inputs and the output of the operation is in safe integer
      range. This includes the necessary changes to the Deoptimizer to be
      able to rematerialize Int64 values as Smi/HeapNumber when going back
      to Ignition later.
      
      This change might affect performance, although measurements indicate
      that there should be no noticable performance impact.
      
      The goal is to have TurboFan support Word64 representation to a degree
      that changing the TypedArray length to an uint64_t (for 64-bit archs)
      becomes viable and doesn't have any negative performance implications.
      Independent of that we might get performance improvements in other areas
      such as for crypto code later.
      
      Bug: v8:4153, v8:7881, v8:8171, v8:8178
      Design-Document: bit.ly/turbofan-word64
      Change-Id: I29d56e2a31c1bae61d04a89d29ea73f21fd49c59
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
      Reviewed-on: https://chromium-review.googlesource.com/1225709
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55937}
      0c296cb2
    • Benedikt Meurer's avatar
      [turbofan] Properly constant-fold Float64 comparisons. · b8e554d5
      Benedikt Meurer authored
      While investigating crbug.com/878742 I found that somehow the
      MachineOperatorReducer lacks the ability to constant-fold
      comparisons of Float64 constants, which obviously leads to
      pretty weird code.
      
      Bug: v8:8015
      Change-Id: I7e18ce10e9d5c87f131fb083ccd3e1e336189dae
      Reviewed-on: https://chromium-review.googlesource.com/1226132Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55935}
      b8e554d5
  9. 14 Sep, 2018 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Initial Word64 support in representation selection. · 6346cdb6
      Benedikt Meurer authored
      This adds support to TurboFan's representation selection for the Word64
      representation, and makes use of that to handle indices for memory access
      and allocation instructions (i.e. LoadElement, StoreElement, Allocate,
      etc.). These instructions had previously used Word32 as representation
      for the indices / sizes, and then internally converted it to the correct
      representation (aka Word64 on 64-bit architectures) later on, but that
      was kind of brittle, and sometimes led to weird generated code.
      
      The change thus only adds support to convert integer values in the safe
      integer range from all kinds of representations to Word64 (on 64-bit
      architectures). We don't yet handle the opposite direction and none of
      the representation selection heuristics for the numeric operations were
      changed so far. This will be done in follow-up CLs.
      
      This CL itself is supposed to be neutral wrt. functionality, and only
      serves as a starting point, and a cleanup for the (weird) implicit
      Word64 index/size handling.
      
      Bug: v8:7881, v8:8015, v8:8171
      Design-Document: http://bit.ly/turbofan-word64
      Change-Id: I3c6961a0e96cbc3fb8ac9d3e1be8f2e5c89bfd25
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel
      Reviewed-on: https://chromium-review.googlesource.com/1224932
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55886}
      6346cdb6
  10. 07 May, 2018 1 commit
  11. 17 Apr, 2018 1 commit
  12. 02 Mar, 2018 1 commit
  13. 12 Dec, 2017 1 commit
  14. 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
  15. 01 Dec, 2017 1 commit
  16. 06 Nov, 2017 1 commit
    • Clemens Hammacher's avatar
      Reland "[bits] Consolidate Count{Leading,Trailing}Zeros" · 27ffc624
      Clemens Hammacher authored
      This is a reland of 7d231e57, fixed to
      avoid instantiating CountLeadingZeros for bits==0.
      
      Original change's description:
      > [bits] Consolidate Count{Leading,Trailing}Zeros
      > 
      > Instead of having one method for 32 bit integers and one for 64 bit,
      > plus a templatized version to choose from those two, just implement one
      > version which handles unsigned integers of any size. Also, make them
      > constexpr.
      > The Count{Leading,Trailing}Zeros{32,64} methods are kept for now in
      > order to keep the amount of code changes small. Also, sometimes it
      > improves readability by stating exactly the size of the argument,
      > especially for leading zeros (where zero-extending would add more
      > leading zeros).
      > 
      > CountLeadingZeros now uses a binary search inspired implementation
      > as proposed in Hacker's Delight. It's more than 20% faster on x64 if
      > the builtins are disabled.
      > CountTrailingZeros falls back to CountPopulation instead of counting in
      > a naive loop. This is ~50% faster.
      > 
      > R=mstarzinger@chromium.org
      > 
      > Change-Id: I1d8bf1d7295b930724163248150444bd17fbb34e
      > Reviewed-on: https://chromium-review.googlesource.com/741231
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49106}
      
      Change-Id: Icdff2510ec66d1c96a1912cef29d77d8550994ee
      Reviewed-on: https://chromium-review.googlesource.com/753903Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49138}
      27ffc624
  17. 04 Nov, 2017 1 commit
    • Michael Achenbach's avatar
      Revert "[bits] Consolidate Count{Leading,Trailing}Zeros" · 1a1968fe
      Michael Achenbach authored
      This reverts commit 7d231e57.
      
      Reason for revert: Breaks revert for win-clang:
      https://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/342755
      
      Original change's description:
      > [bits] Consolidate Count{Leading,Trailing}Zeros
      > 
      > Instead of having one method for 32 bit integers and one for 64 bit,
      > plus a templatized version to choose from those two, just implement one
      > version which handles unsigned integers of any size. Also, make them
      > constexpr.
      > The Count{Leading,Trailing}Zeros{32,64} methods are kept for now in
      > order to keep the amount of code changes small. Also, sometimes it
      > improves readability by stating exactly the size of the argument,
      > especially for leading zeros (where zero-extending would add more
      > leading zeros).
      > 
      > CountLeadingZeros now uses a binary search inspired implementation
      > as proposed in Hacker's Delight. It's more than 20% faster on x64 if
      > the builtins are disabled.
      > CountTrailingZeros falls back to CountPopulation instead of counting in
      > a naive loop. This is ~50% faster.
      > 
      > R=​mstarzinger@chromium.org
      > 
      > Change-Id: I1d8bf1d7295b930724163248150444bd17fbb34e
      > Reviewed-on: https://chromium-review.googlesource.com/741231
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#49106}
      
      TBR=mstarzinger@chromium.org,clemensh@chromium.org
      
      Change-Id: Iceeb35bf9c7539a1013c9bdbc47118008611bef2
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/753463Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49123}
      1a1968fe
  18. 03 Nov, 2017 1 commit
    • Clemens Hammacher's avatar
      [bits] Consolidate Count{Leading,Trailing}Zeros · 7d231e57
      Clemens Hammacher authored
      Instead of having one method for 32 bit integers and one for 64 bit,
      plus a templatized version to choose from those two, just implement one
      version which handles unsigned integers of any size. Also, make them
      constexpr.
      The Count{Leading,Trailing}Zeros{32,64} methods are kept for now in
      order to keep the amount of code changes small. Also, sometimes it
      improves readability by stating exactly the size of the argument,
      especially for leading zeros (where zero-extending would add more
      leading zeros).
      
      CountLeadingZeros now uses a binary search inspired implementation
      as proposed in Hacker's Delight. It's more than 20% faster on x64 if
      the builtins are disabled.
      CountTrailingZeros falls back to CountPopulation instead of counting in
      a naive loop. This is ~50% faster.
      
      R=mstarzinger@chromium.org
      
      Change-Id: I1d8bf1d7295b930724163248150444bd17fbb34e
      Reviewed-on: https://chromium-review.googlesource.com/741231Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#49106}
      7d231e57
  19. 20 Oct, 2017 1 commit
  20. 19 Oct, 2017 1 commit
  21. 13 Sep, 2017 1 commit
  22. 07 Sep, 2017 1 commit
  23. 14 Jul, 2017 1 commit
  24. 13 Jul, 2017 1 commit
  25. 23 Feb, 2017 1 commit
  26. 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
  27. 03 Feb, 2017 1 commit
  28. 02 Feb, 2017 1 commit
  29. 01 Feb, 2017 1 commit
  30. 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
  31. 04 Jan, 2017 1 commit
  32. 30 Nov, 2016 1 commit
  33. 27 Sep, 2016 1 commit
  34. 16 Sep, 2016 1 commit
  35. 13 Sep, 2016 1 commit
  36. 10 Aug, 2016 1 commit