1. 09 Apr, 2019 1 commit
  2. 21 Mar, 2019 1 commit
  3. 14 Feb, 2019 1 commit
  4. 11 Feb, 2019 1 commit
  5. 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
  6. 28 Jan, 2019 2 commits
  7. 11 Jan, 2019 1 commit
  8. 10 Jan, 2019 1 commit
  9. 26 Dec, 2018 1 commit
  10. 27 Nov, 2018 1 commit
  11. 17 Sep, 2018 1 commit
    • 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
  12. 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
  13. 14 Aug, 2018 2 commits
    • Benedikt Meurer's avatar
      [turbofan] Further optimize DataView accesses. · 5fecd146
      Benedikt Meurer authored
      This adds support for unaligned load/store access to the DataView
      backing store and uses byteswap operations to fix up the endianess
      when necessary. This changes the Word32ReverseBytes operator to be
      a required operator and adds the missing support on the Intel and
      ARM platforms (on 64-bit platforms the Word64ReverseBytes operator
      is also mandatory now).
      
      This further improves the performance on the dataviewperf.js test
      mentioned in the tracking bug by up to 40%, and at the same time
      reduces the code complexity in the EffectControlLinearizer.
      
      Bug: chromium:225811
      Change-Id: I7c1ec826faf46a144a5a9068f8f815a5fd040997
      Reviewed-on: https://chromium-review.googlesource.com/1174252Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55111}
      5fecd146
    • Leszek Swirski's avatar
      Revert "[turbofan] Further optimize DataView accesses." · 6a62d88e
      Leszek Swirski authored
      This reverts commit c46915b9.
      
      Reason for revert: Disasm failures https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20debug/21727 
      
      Original change's description:
      > [turbofan] Further optimize DataView accesses.
      > 
      > This adds support for unaligned load/store access to the DataView
      > backing store and uses byteswap operations to fix up the endianess
      > when necessary. This changes the Word32ReverseBytes operator to be
      > a required operator and adds the missing support on the Intel and
      > ARM platforms (on 64-bit platforms the Word64ReverseBytes operator
      > is also mandatory now).
      > 
      > This further improves the performance on the dataviewperf.js test
      > mentioned in the tracking bug by up to 40%, and at the same time
      > reduces the code complexity in the EffectControlLinearizer.
      > 
      > Bug: chromium:225811
      > Change-Id: I296170b828c2ccc1c317ed37840b564aa14cdec2
      > Reviewed-on: https://chromium-review.googlesource.com/1172777
      > Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#55099}
      
      TBR=sigurds@chromium.org,bmeurer@chromium.org
      
      Change-Id: If7a62e3a1a4ad26823fcbd2ab6eb4c053ad11c49
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:225811
      Reviewed-on: https://chromium-review.googlesource.com/1174171Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#55107}
      6a62d88e
  14. 13 Aug, 2018 2 commits
  15. 15 May, 2018 1 commit
  16. 17 Apr, 2018 1 commit
  17. 14 Mar, 2018 1 commit
  18. 13 Feb, 2018 1 commit
  19. 09 Feb, 2018 1 commit
  20. 16 Jan, 2018 1 commit
  21. 08 Jan, 2018 1 commit
    • Clemens Hammacher's avatar
      [simulator] Make Call variadic · a3baa353
      Clemens Hammacher authored
      In order to remove the CALL_GENERATED_CODE macro, it helps a lot to
      unify the interfaces of the simulators and make the Call method variadic
      in the number of arguments.
      This CL does that for each simulator. A follow-up CL will then
      completely remove the CALL_GENERATED_CODE macro and replace uses with
      the (new) GeneratedCode wrapper.
      
      R=mstarzinger@chromium.org
      
      Bug: v8:7182
      Change-Id: I1f81445ec2faba30f0bd233b022ae1f0fae4e96f
      Reviewed-on: https://chromium-review.googlesource.com/850873
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#50413}
      a3baa353
  22. 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
  23. 01 Dec, 2017 2 commits
  24. 07 Nov, 2017 1 commit
  25. 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
  26. 19 Oct, 2017 1 commit
  27. 13 Oct, 2017 1 commit
  28. 28 Sep, 2017 1 commit
    • Enrico Bacis's avatar
      [wasm] Introduce the WasmContext · 6cd7a5a7
      Enrico Bacis authored
      The WasmContext struct introduced in this CL is used to store the
      mem_size and mem_start address of the wasm memory. These variables can
      be accessed at C++ level at graph build time (e.g., initialized during
      instance building). When the GrowMemory runtime is invoked, the context
      variables can be changed in the WasmContext at C++ level so that the
      generated code will load the correct values.
      
      This requires to insert a relocatable pointer only in the
      JSToWasmWrapper (and in the other wasm entry points), the value is then
      passed from function to function as an automatically added additional
      parameter. The WasmContext is then dropped when creating an Interpreter
      Entry or when invoking a JavaScript function. This removes the need of
      patching the generated code at runtime (i.e., when the memory grows)
      with respect to WASM_MEMORY_REFERENCE and WASM_MEMORY_SIZE_REFERENCE.
      However, we still need to patch the code at instance build time to patch
      the JSToWasmWrappers; in fact the address of the WasmContext is not
      known during compilation, but only when the instance is built.
      
      The WasmContext address is passed as the first parameter. This has the
      advantage of not having to move the WasmContext around if the function
      does not use many registers. This CL also changes the wasm calling
      convention so that the first parameter register is different from the
      return value register. The WasmContext is attached to every
      WasmMemoryObject, to share the same context with multiple instances
      sharing the same memory. Moreover, the nodes representing the
      WasmContext variables are cached in the SSA environment, similarly to
      other local variables that might change during execution.  The nodes are
      created when initializing the SSA environment and refreshed every time a
      grow_memory or a function call happens, so that we are sure that they
      always represent the correct mem_size and mem_start variables.
      
      This CL also removes the WasmMemorySize runtime (since it's now possible
      to directly retrieve mem_size from the context) and simplifies the
      GrowMemory runtime (since every instance now has a memory_object).
      
      R=ahaas@chromium.org,clemensh@chromium.org
      CC=gdeepti@chromium.org
      
      Change-Id: I3f058e641284f5a1bbbfc35a64c88da6ff08e240
      Reviewed-on: https://chromium-review.googlesource.com/671008
      Commit-Queue: Enrico Bacis <enricobacis@google.com>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48209}
      6cd7a5a7
  29. 14 Aug, 2017 1 commit
  30. 01 Aug, 2017 1 commit
  31. 06 Jul, 2017 1 commit
  32. 18 May, 2017 1 commit
  33. 16 May, 2017 1 commit
  34. 09 May, 2017 2 commits
  35. 21 Apr, 2017 1 commit