1. 13 Aug, 2019 1 commit
  2. 12 Aug, 2019 1 commit
    • Milad Farazmand's avatar
      PPC/s390: [compiler] Refactor stack check handling · f7f370d2
      Milad Farazmand authored
      Port 0aa204fe
      
      Original Commit Message:
      
          This CL unifies how stack checks are handled in the Turbofan pipeline
          across architectures, in preparation for properly handling stack
          overflows caused by deoptimization in follow-up work. It will also
          open up possibilities to simplify related logic.
      
          How this used to work: JSStackCheck was lowered to a UintLessThan
          with the stack pointer (sp) and stack limit as inputs. On x64 and ia32,
          this node pattern was later recognized during instruction selection
          and rewritten to dedicated operators. On other platforms, including
          arm and arm64, special logic exists to avoid useless
          register-to-register moves when accessing the sp.
      
          This CL introduces a new StackPointerGreaterThan operator, which takes
          the stack limit as its sole input. This is what JSStackCheck now lowers
          to. This is threaded through to code generation, where we emit the
          appropriate code (in the future, we will apply an additional offset to
          the sp here).
      
          In follow-up CLs, we can remove or replace remaining uses of
          LoadStackPointer in CSA, Wasm, and the interpreter; and then remove
          the LoadStackPointer operator, related node matchers, related register
          constraints, and the pseudo-smi stack limit roots.
      
      R=jgruber@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I175c110d30190bb543001b6fa77cd65cf22e5874
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748002Reviewed-by: 's avatarJunliang Yan <jyan@ca.ibm.com>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#63167}
      f7f370d2
  3. 05 Aug, 2019 1 commit
  4. 01 Aug, 2019 1 commit
  5. 22 Jul, 2019 1 commit
  6. 11 Jul, 2019 2 commits
  7. 08 Jul, 2019 1 commit
  8. 22 May, 2019 1 commit
  9. 29 Mar, 2019 1 commit
  10. 22 Mar, 2019 1 commit
  11. 14 Mar, 2019 1 commit
  12. 13 Mar, 2019 1 commit
  13. 08 Mar, 2019 1 commit
  14. 05 Mar, 2019 1 commit
    • Junliang Yan's avatar
      PPC/s390: [arm][turbofan] Implement on-stack returns. · 7103c194
      Junliang Yan authored
      Port 9c7b6e1e
      
      Original Commit Message:
      
          This is the implementation of crrev.com/c/766371 for arm.
      
          Original description:
      
          Add the ability to return (multiple) return values on the stack:
      
          - Extend stack frames with a new buffer region for return slots.
            This region is located at the end of a caller's frame such that
            its slots can be indexed as caller frame slots in a callee
            (located beyond its parameters) and assigned return values.
          - Adjust stack frame constructon and deconstruction accordingly.
          - Extend linkage computation to support register plus stack returns.
          - Reserve return slots in caller frame when respective calls occur.
          - Introduce and generate architecture instructions ('peek') for
            reading back results from return slots in the caller.
          - Aggressive tests.
          - Some minor clean-up.
      
      R=ahaas@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com, miladfar@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I83df1af8c49f6d6c5b529db599fce61a1da2490d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1496549Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#60032}
      7103c194
  15. 13 Feb, 2019 1 commit
  16. 11 Jan, 2019 1 commit
  17. 07 Dec, 2018 1 commit
  18. 12 Nov, 2018 1 commit
  19. 07 Nov, 2018 1 commit
  20. 30 Oct, 2018 1 commit
    • Junliang Yan's avatar
      PPC/s390: [turbofan] Add support for huge DataViews. · 3d60549e
      Junliang Yan authored
      Port 15c31fe4
      
      Original Commit Message:
      
          This introduces Word64 support for the CheckBounds operator, which now
          lowers to either CheckedUint32Bounds or CheckedUint64Bounds after the
          representation selection. The right hand side of CheckBounds can now
          be any positive safe integer on 64-bit architectures, whereas it remains
          Unsigned31 for 32-bit architectures. We only use the extended Word64
          support when the right hand side is outside the Unsigned31 range, so
          for everything except DataViews this means that the performance should
          remain the same. The typing rule for the CheckBounds operator was
          updated to reflect this new behavior.
      
          The CheckBounds with a right hand side outside the Unsigned31 range will
          pass a new Signed64 feedback kind, which is handled with newly introduced
          CheckedFloat64ToInt64 and CheckedTaggedToInt64 operators in representation
          selection.
      
          The JSCallReducer lowering for DataView getType()/setType() methods was
          updated to not smi-check the [[ByteLength]] and [[ByteOffset]] anymore,
          but instead just use the raw uintptr_t values and operate on any value
          (for 64-bit architectures these fields can hold any positive safe
          integer, for 32-bit architectures it's limited to Unsigned31 range as
          before). This means that V8 can now handle huge DataViews fully, without
          falling off a performance cliff.
      
          This refactoring even gave us some performance improvements, on a simple
          micro-benchmark just exercising different DataView accesses we go from
      
            testDataViewGetUint8: 796 ms.
            testDataViewGetUint16: 997 ms.
            testDataViewGetInt32: 994 ms.
            testDataViewGetFloat64: 997 ms.
      
          to
      
            testDataViewGetUint8: 895 ms.
            testDataViewGetUint16: 889 ms.
            testDataViewGetInt32: 888 ms.
            testDataViewGetFloat64: 890 ms.
      
          meaning we lost around 10% on the single byte case, but gained 10% across
          the board for all the other element sizes.
      
      R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ia86089ca9ccc75405aa13600b031c72bac0279dd
      Reviewed-on: https://chromium-review.googlesource.com/c/1305035Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#57152}
      3d60549e
  21. 10 Oct, 2018 1 commit
  22. 03 Oct, 2018 1 commit
  23. 02 Oct, 2018 1 commit
  24. 01 Oct, 2018 1 commit
  25. 17 Sep, 2018 2 commits
    • Junliang Yan's avatar
      PPC/s390: [turbofan] Initial support to compute NumberAdd/NumberSubtract in Word64. · 32aef42a
      Junliang Yan authored
      Port 0c296cb2
      
      Original Commit Message:
      
          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.
      
      R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: I2119f156c4ddf942ea09ff8ed52e1c6cb32477f2
      Reviewed-on: https://chromium-review.googlesource.com/1228634Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#55971}
      32aef42a
    • Junliang Yan's avatar
      PPC/s390: [turbofan] Initial Word64 support in representation selection. · 89304433
      Junliang Yan authored
      Port 6346cdb6
      
      Original Commit Message:
      
          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.
      
      R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ic7ea30639dea3c5f8a59e7100a15d5ed50073c20
      Reviewed-on: https://chromium-review.googlesource.com/1228416Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#55970}
      89304433
  26. 15 Aug, 2018 1 commit
  27. 14 Aug, 2018 1 commit
    • Junliang Yan's avatar
      PPC/s390: [turbofan] Further optimize DataView accesses. · 14170c67
      Junliang Yan authored
      Port 5fecd146
      
      Original Commit Message:
      
          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.
      
      R=bmeurer@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
      BUG=
      LOG=N
      
      Change-Id: Ia9aad21713a2ad76ce3ef2b816fc20e9a27fe4c9
      Reviewed-on: https://chromium-review.googlesource.com/1174936Reviewed-by: 's avatarJohn Barboza <jbarboza@ca.ibm.com>
      Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#55132}
      14170c67
  28. 27 Jul, 2018 1 commit
  29. 19 Jun, 2018 1 commit
  30. 14 May, 2018 2 commits
  31. 30 Apr, 2018 1 commit
    • Jaroslav Sevcik's avatar
      Replace array index masking with the poisoning approach. · f53dfd93
      Jaroslav Sevcik authored
      The idea is to mark all the branches and loads participating in array
      bounds checks, and let them contribute-to/use the poisoning register.
      In the code, the marks for array indexing operations now contain
      "Critical" in their name. By default (--untrusted-code-mitigations),
      we only instrument the "critical" operations with poisoning.
      
      With that in place, we also remove the array masking approach based
      on arithmetic.
      
      Since we do not propagate the poison through function calls,
      we introduce a node for poisoning an index that is passed through
      function call - the typical example is the bounds-checked index
      that is passed to the CharCodeAt builtin.
      
      Most of the code in this CL is threads through the three levels of
      protection (safe, critical, unsafe) for loads, branches and flags.
      
      Bug: chromium:798964
      
      Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b
      Reviewed-on: https://chromium-review.googlesource.com/995413
      Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52883}
      f53dfd93
  32. 10 Apr, 2018 1 commit
  33. 29 Mar, 2018 1 commit
  34. 28 Mar, 2018 1 commit
  35. 27 Mar, 2018 1 commit
    • Tobias Tebbi's avatar
      [turbofan] unify interpreter and JIT speculation poisoning · 1ef6c437
      Tobias Tebbi authored
      This CL changes the poisoning in the interpreter to use the
      infrastructure used in the JIT.
      
      This does not change the original flag semantics:
      
      --branch-load-poisoning enables JIT mitigations as before.
      
      --untrusted-code-mitigation enables the interpreter mitigations
        (now realized using the compiler back-end), but does not enable
        the back-end based mitigations for the Javascript JIT. So in effect
        --untrusted-code-mitigation makes the CSA pipeline for bytecode handlers
        use the same mechanics (including changed register allocation) that
        --branch-load-poisoning enables for the JIT.
      
      Bug: chromium:798964
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27
      Reviewed-on: https://chromium-review.googlesource.com/928881Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52243}
      1ef6c437
  36. 15 Mar, 2018 1 commit
  37. 05 Mar, 2018 1 commit