1. 24 Oct, 2019 1 commit
  2. 23 Oct, 2019 3 commits
  3. 22 Oct, 2019 4 commits
  4. 21 Oct, 2019 2 commits
  5. 17 Oct, 2019 2 commits
  6. 16 Oct, 2019 12 commits
  7. 15 Oct, 2019 5 commits
    • Milad Farazmand's avatar
      PPC/s390: [Liftoff] Improve initialization for many locals · c314cf74
      Milad Farazmand authored
      Port a8cdda99
      
      Original Commit Message:
      
          WebAssembly locals are specified to be zero on function entry. Liftoff
          implements this by just storing the constant 0 in the virtual stack for
          integer types, and using one floating point register initialized to
          zero for all floating point types.
          For big counts of locals this leads to problems (manifesting as huge
          blocks of code being generated) once we hit a merge point: All those
          constants (for int) and all duplicate register uses (for floats) need to
          be fixed up, by using separate registers for the locals or spilling to
          the stack if no more registers are available. All this spilling
          generates a lot of code, and can even happen multiple times within a
          function.
      
          This CL optimizes for such cases by spilling all locals to the stack
          initially. All merges within the function body get much smaller then.
          The spilled values rarely have to be loaded anyway, because the initial
          zero value is usually overwritten before the first use.
      
          To optimize the code size for initializing big numbers of locals on the
          stack, this CL also introduces the platform-specific
          {FillStackSlotsWithZero} method which uses a loop for bigger local
          counts.
      
          This often saves dozens of kilobytes for very big functions, and shows
          an overall code size reduction of 4-5 percent for big modules.
      
      R=clemensb@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I2459080a1f6acfdd212e9a93a868d028980c5554
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863370Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Reviewed-by: 's avatarMilad Farazmand <miladfar@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#64301}
      c314cf74
    • Michael Starzinger's avatar
      [wasm] Remove dead declarations in wasm-module.h file. · 2e44cf7d
      Michael Starzinger authored
      R=clemensb@chromium.org
      
      Change-Id: I9dab61c4260436d08171ac0ff084e05d75c5c5e2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862573Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64298}
      2e44cf7d
    • Clemens Backes's avatar
      [Liftoff] Merge i32.eqz and br_if instructions · 5c20da07
      Clemens Backes authored
      We currently generate code for both separately, resulting in five
      instructions (three for the i32_eqz, two for the br_if):
        test rax,rax
        seteq dl
        movzxb rdx,rdx
        test rdx,rdx
        jz <label>
      
      After this CL, we just generate two instructions:
        test rax, rax
        jnz <label>
      
      This is implemented by a look-ahead in the {kExprI32Eqz} handler. If the
      opcode is followed by {kExprBrIf}, no code is emitted. Instead, a flag in
      the {LiftoffCompiler} is set to signal to the {kExprBrIf} handler that
      the previous instruction was not processed yet.
      Note that this mechanism is designed to be reusable for more similar
      improvements. For the single instance implemented in this CL, it is not
      needed.
      
      Plus some drive-by cleanup.
      
      R=jkummerow@chromium.org
      
      Bug: v8:9831
      Change-Id: I47495fe763b7db7cef41aa207c88a2f1b74bf1a9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862557
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64292}
      5c20da07
    • Michael Starzinger's avatar
      [wasm] Remove deprecated {WasmGraphBuilder::Buffer}. · c01bfb16
      Michael Starzinger authored
      This replaces all left-over uses of {WasmGraphBuilder::Buffer} with
      proper alternatives (e.g. using {base::SmallVector} instead).
      
      R=clemensb@chromium.org
      
      Change-Id: I2607ce7e2638a1bb35daccbb5b38382d5b62a430
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859626Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64285}
      c01bfb16
    • Clemens Backes's avatar
      [Liftoff] Improve initialization for many locals · a8cdda99
      Clemens Backes authored
      WebAssembly locals are specified to be zero on function entry. Liftoff
      implements this by just storing the constant 0 in the virtual stack for
      integer types, and using one floating point register initialized to
      zero for all floating point types.
      For big counts of locals this leads to problems (manifesting as huge
      blocks of code being generated) once we hit a merge point: All those
      constants (for int) and all duplicate register uses (for floats) need to
      be fixed up, by using separate registers for the locals or spilling to
      the stack if no more registers are available. All this spilling
      generates a lot of code, and can even happen multiple times within a
      function.
      
      This CL optimizes for such cases by spilling all locals to the stack
      initially. All merges within the function body get much smaller then.
      The spilled values rarely have to be loaded anyway, because the initial
      zero value is usually overwritten before the first use.
      
      To optimize the code size for initializing big numbers of locals on the
      stack, this CL also introduces the platform-specific
      {FillStackSlotsWithZero} method which uses a loop for bigger local
      counts.
      
      This often saves dozens of kilobytes for very big functions, and shows
      an overall code size reduction of 4-5 percent for big modules.
      
      R=jkummerow@chromium.org
      
      Bug: v8:9830
      Change-Id: I23fa4145847827420f09e043a11e0e7b606e94cc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1856004
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64282}
      a8cdda99
  8. 14 Oct, 2019 4 commits
  9. 11 Oct, 2019 2 commits
  10. 10 Oct, 2019 2 commits
  11. 09 Oct, 2019 3 commits