1. 18 Mar, 2020 1 commit
  2. 13 Mar, 2020 1 commit
  3. 12 Mar, 2020 1 commit
  4. 11 Mar, 2020 1 commit
  5. 06 Mar, 2020 1 commit
  6. 04 Mar, 2020 1 commit
  7. 03 Mar, 2020 1 commit
  8. 02 Mar, 2020 1 commit
  9. 28 Feb, 2020 1 commit
  10. 27 Feb, 2020 1 commit
  11. 25 Feb, 2020 1 commit
  12. 18 Feb, 2020 1 commit
  13. 10 Feb, 2020 1 commit
  14. 30 Jan, 2020 1 commit
  15. 28 Jan, 2020 1 commit
  16. 24 Jan, 2020 1 commit
    • Milad Farazmand's avatar
      PPC/s390: Reland "[liftoff][wasm-simd] Implement f32x4.splat" · 3fa75eca
      Milad Farazmand authored
      Port b110d480
      
      Original Commit Message:
      
          This relands commit 009993ad.
      
          The fix is in liftoff-assembler-ia32.h, the codegen was incorrect.
      
          Original change's description:
          > Implement f32x4.splat and enable handling this in Liftoff.
          >
          > We add a new macro for defining test cases to run on TurboFan, Liftoff,
          > interpreter, and scalar lowering.
          >
          > Also add an assertion that the execution tier used is what we expected
          > it to be. This is useful for Liftoff, because by default it falls back
          > to TurboFan when it encounters an unimplemented opcode.
          >
          > Bug: v8:9909
      
      R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I0fc54cd04379a6c65aa2bee64bf4cf9dad5b9636
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2019582Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#65977}
      3fa75eca
  17. 22 Jan, 2020 1 commit
  18. 17 Jan, 2020 1 commit
  19. 16 Jan, 2020 1 commit
  20. 14 Jan, 2020 2 commits
  21. 13 Jan, 2020 1 commit
    • Clemens Backes's avatar
      [Liftoff] Use {int} for stack offsets · 8e2cfc89
      Clemens Backes authored
      To follow the style guide, and potentially improve performance, we
      switch to {int} for all stack offsets. The size of the stack cannot grow
      anywhere near {kMaxInt} anyway, and we have limits in place (for number
      of locals, number of parameters, and function body size) which also
      prevent this number from ever growing near that limit.
      
      R=jkummerow@chromium.org
      
      Change-Id: I05ca9124d2def79edd212464739bc12315f7b813
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1997445Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65740}
      8e2cfc89
  22. 10 Jan, 2020 1 commit
    • Milad Farazmand's avatar
      PPC/s390: [liftoff][wasm-simd] Specify alignment requirements · 2806dd78
      Milad Farazmand authored
      Port 57168634
      
      Original Commit Message:
      
          Declare an inline method for the various backends to define based on
          alignment requirements. That way backends that might take a performance
          hit when data is not naturally aligned can specify the requirements.
      
          With this requirement defined, we can then specify that SIMD values
          require 16 bytes on the stack.
      
          This also opens up the possibility of storing 32-bit values in 32-bits,
          rather than the fixed kStackSlotSize.
      
      R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ic61ba7508d37971a04fddad9e25025d038fdc3bd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1994181Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#65706}
      2806dd78
  23. 16 Dec, 2019 1 commit
    • Ng Zhi An's avatar
      [liftoff] Allocate stack slot sizes based on type · 0c9805d0
      Ng Zhi An authored
      Liftoff supports unfixed stack slot sizes now, so we can have
      SlotSizeForType return different values based on the value type it is
      spilling. We make the change for architectures that support unaligned
      access, x64, ia32, arm64.
      
      Note for ppc/s390/mips/mips64 ports: SlotSizeForType remains as 8 byte
      (old behavior), but can be changed.
      
      This patch also makes adjustments to PatchPrepareStackFrame to align sp
      to appropriate values (pointer size).
      
      Bug: v8:9909
      Change-Id: Iddd2dcd652b162a04a02ed704c5b06f6af8a186d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1956165
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65467}
      0c9805d0
  24. 04 Dec, 2019 2 commits
  25. 03 Dec, 2019 1 commit
    • Ng Zhi An's avatar
      [liftoff] Change PatchPrepareStackFrame to use bytes · 45ee6f40
      Ng Zhi An authored
      Calculate the number of bytes of the stack frame used in
      PatchPrepareStackFrame using the size of the spill instead of the number
      of slots.
      
      We only need the number of bytes spilled (without adding the number of
      locals) because whenever we spill, we already track the largest offset,
      with RecordUsedSpillSlot. GetTotalFrameSlotCount can also be changed to
      remove the num_locals, in a future patch.
      
      Change-Id: I08fe3e81eaebf5f2cf1e11292645663474483447
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1945944
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65303}
      45ee6f40
  26. 02 Dec, 2019 1 commit
  27. 21 Nov, 2019 2 commits
    • Ng Zhi An's avatar
      [liftoff] Convert callers to use offset · aaf5c124
      Ng Zhi An authored
      This patch changes many callers of GetStackOffsetFromIndex to directly
      use the offset that is stored in the VarState (and other structures).
      
      The tricky part here is that in all archs, GetStackSlotOffset no longer
      relies on kFirstStackSlotOffset, because the offset stored in VarState
      is relative to the constant space (instance offset), and not offset of
      the first stack slot.
      
      For example, for slot 0, the offset was also 0, because it was relative
      to the first stack slot offset (which in x64 is fp-24). With this
      change, the offset of slot 0 is now 8, but since GetStackSlotOffset is
      relative to fp-16, it ends up being fp-24 still.
      
      Because of this change, callers of GetStackOffsetFromIndex need to add
      1 to whatever index they were passing. Instead of doing that, we change
      GetStackOffsetFromIndex to add 1 inside the body.
      
      After this change, the only callers of GetStackOffsetFromIndex will be
      inside of FillStackSlotsWithZero, because they still rely on index to
      keep track of how many params were processed, and also how many locals
      there are in order to zero those slots, and these is relied on by
      RecordUsedSpillSlot to allocate sufficient stack space.
      
      Bug: v8:9909
      Change-Id: I52aa4572950565a39e9395192706a9934ac296d4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925524
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65109}
      aaf5c124
    • Ng Zhi An's avatar
      Reland "[liftoff] Use stack slot offsets instead of indices" · d3cd2702
      Ng Zhi An authored
      This is a reland of 20727725
      
      The fix is in liftoff-assembler-arm64.h in FillStackSlotsWithZero,
      in the else case for bigger counts to fill, the argument passed to Sub
      was incorrect. We were passing offset relative to first slot, but it
      should be offset relative to instance, so there is an off by 1 slot error
      when zeroing, and ended up zeroing the stack slot holding instance.
      
      Original change's description:
      > [liftoff] Use stack slot offsets instead of indices
      >
      > Spill/fill now take offsets instead of indices. We provide a
      > helper, GetStackOffsetFromIndex, for callers. This is currently only
      > useful while slot sizes are still fixed to 8 bytes.
      >
      > StackTransferRecipe's RegisterLoad now works in terms of offset.
      >
      > LiftoffStackSlots work in terms of offset as well.
      >
      > TransferStackSlot currently still works in terms of indicies, but can be
      > converted to use offsets in a subsequent change.
      >
      > Bug: v8:9909
      > Change-Id: If54fb844309bdfd641720d063135dd59551813e0
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1922489
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Commit-Queue: Zhi An Ng <zhin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#65049}
      
      Bug: v8:9909
      Change-Id: I311da9d3bb1db8faf8693079177c77a7b3754243
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1925131Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65107}
      d3cd2702
  28. 20 Nov, 2019 1 commit
  29. 19 Nov, 2019 1 commit
    • Ng Zhi An's avatar
      [liftoff] Use stack slot offsets instead of indices · 20727725
      Ng Zhi An authored
      Spill/fill now take offsets instead of indices. We provide a
      helper, GetStackOffsetFromIndex, for callers. This is currently only
      useful while slot sizes are still fixed to 8 bytes.
      
      StackTransferRecipe's RegisterLoad now works in terms of offset.
      
      LiftoffStackSlots work in terms of offset as well.
      
      TransferStackSlot currently still works in terms of indicies, but can be
      converted to use offsets in a subsequent change.
      
      Bug: v8:9909
      Change-Id: If54fb844309bdfd641720d063135dd59551813e0
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1922489Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65049}
      20727725
  30. 05 Nov, 2019 5 commits
  31. 31 Oct, 2019 1 commit
  32. 17 Oct, 2019 1 commit
  33. 15 Oct, 2019 1 commit
    • 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