1. 08 Apr, 2020 1 commit
  2. 19 Mar, 2020 1 commit
  3. 26 Feb, 2020 1 commit
  4. 28 Jan, 2020 1 commit
  5. 13 Jan, 2020 1 commit
  6. 08 Jan, 2020 1 commit
  7. 19 Dec, 2019 1 commit
  8. 03 Dec, 2019 1 commit
  9. 29 Nov, 2019 1 commit
  10. 26 Nov, 2019 1 commit
  11. 18 Nov, 2019 1 commit
  12. 11 Nov, 2019 1 commit
  13. 08 Nov, 2019 1 commit
  14. 06 Nov, 2019 1 commit
  15. 30 Oct, 2019 1 commit
    • Jakob Gruber's avatar
      Reland "[compiler] Optionally apply an offset to stack checks" · b875f466
      Jakob Gruber authored
      This is a reland of 4a16305b
      
      The original CL adjust only one part of the stack check, namely the
      comparison of the stack pointer against the stack limit in generated code.
      There is a second part: Runtime::kStackGuard repeats this check to
      distinguish between a stack overflow and an interrupt request.
      
      This second part in runtime must apply the offset just like in generated
      code. It is implemented in this reland by the StackCheckOffset operator
      and a new StackGuardWithGap runtime function.
      
      Original change's description:
      > [compiler] Optionally apply an offset to stack checks
      >
      > The motivation behind this change is that the frame size of an optimized
      > function and its unoptimized version may differ, and deoptimization
      > may thus trigger a stack overflow. The solution implemented in this CL
      > is to optionally apply an offset to the stack check s.t. the check
      > becomes 'sp - offset > limit'. The offset is applied to stack checks at
      > function-entry, and is set to the difference between the optimized and
      > unoptimized frame size.
      >
      > A caveat: OSR may not be fully handled by this fix since we've already
      > passed the function-entry stack check. A possible solution would be to
      > *not* skip creation of function-entry stack checks for inlinees.
      >
      > This CL: 1. annotates stack check nodes with the stack check kind, where
      > kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      > allocates a temporary register to store the result of the 'sp - offset'
      > in instruction selection (and switches input registers to 'unique'
      > mode). 3. Applies the offset in code generation.
      >
      > Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      >
      > Bug: v8:9534,chromium:1000887
      > Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63701}
      
      Bug: v8:9534, chromium:1000887
      Change-Id: I71771c281afd7d57c09aa48ea1b182d01e6dee2a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1822037Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64634}
      b875f466
  16. 17 Oct, 2019 1 commit
  17. 16 Oct, 2019 1 commit
  18. 09 Oct, 2019 1 commit
  19. 18 Sep, 2019 2 commits
    • Ng Zhi An's avatar
      [wasm-simd] Implement QFMA and QFMS on x64 · 2cf821cc
      Ng Zhi An authored
      Quasi Fused Multiply-Add and Quasi Fused Multiply-Subtract performs, on floats, a + b * c and a - b * c respectively.
      When there is only a single rounding, it is a fused operation. Quasi in this case means that the result can either be fused or not fused (two roundings), depending on hardware support.
      
      It is tricky to write the test because we need to calculate the expected value, and there is no easy way to express fused or unfused operation in C++, i.e.
      we cannot confirm that float expected = a + b * c will perform a fused or unfused operation (unless we use intrinsics).
      Thus in the test we have a list of simple checks, plus interesting values that we know will produce different results depending on whether it was fused or not.
      
      The difference between 32x4 and 64x2 qfma/qfms is the type, and also the values of b and c that will cause an overflow, and thus the intermediate rounding will affect the final result.
      The same array can be copy pasted for both types, but with a bit of templating we can avoid that duplication.
      
      Change-Id: I0973a3d28468d25f310b593c72f21bff54d809a7
      Bug: v8:9415
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1779325
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63878}
      2cf821cc
    • Milad Farazmand's avatar
      [wasm-simd] Adding Simd128ReverseBytes to all supported architectures · 1225709e
      Milad Farazmand authored
      WASM only supports Little-endian byte ordering and we need a mechanism to
      reverse the ordering efficiently on Big-endian machines.
      Up until now this was done using TF graphs within wasm-compiler.
      The new approach allows for having more machine level optimizations
      by introducing the new "kSimd128ReverseBytes" opcode which gets executed
      only on Big-endian machines.
      
      Change-Id: I63c6c3c42ca9ff9d9b2af2d45070a70cf1b3cefc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803494Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
      Cr-Commit-Position: refs/heads/master@{#63875}
      1225709e
  20. 12 Sep, 2019 2 commits
    • Jakob Gruber's avatar
      Revert "[compiler] Optionally apply an offset to stack checks" · ba72dc08
      Jakob Gruber authored
      This reverts commit 4a16305b.
      
      Reason for revert: Need to revalidate assumptions behind the CHECK.
      
      Original change's description:
      > [compiler] Optionally apply an offset to stack checks
      > 
      > The motivation behind this change is that the frame size of an optimized
      > function and its unoptimized version may differ, and deoptimization
      > may thus trigger a stack overflow. The solution implemented in this CL
      > is to optionally apply an offset to the stack check s.t. the check
      > becomes 'sp - offset > limit'. The offset is applied to stack checks at
      > function-entry, and is set to the difference between the optimized and
      > unoptimized frame size.
      > 
      > A caveat: OSR may not be fully handled by this fix since we've already
      > passed the function-entry stack check. A possible solution would be to
      > *not* skip creation of function-entry stack checks for inlinees.
      > 
      > This CL: 1. annotates stack check nodes with the stack check kind, where
      > kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      > allocates a temporary register to store the result of the 'sp - offset'
      > in instruction selection (and switches input registers to 'unique'
      > mode). 3. Applies the offset in code generation.
      > 
      > Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      > 
      > Bug: v8:9534,chromium:1000887
      > Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      > Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63701}
      
      TBR=neis@chromium.org,sigurds@chromium.org,jgruber@chromium.org
      
      Change-Id: Iebf46d5256b6dee13451741781ef85a5fe9b1628
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9534, chromium:1000887
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1800565Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63706}
      ba72dc08
    • Jakob Gruber's avatar
      [compiler] Optionally apply an offset to stack checks · 4a16305b
      Jakob Gruber authored
      The motivation behind this change is that the frame size of an optimized
      function and its unoptimized version may differ, and deoptimization
      may thus trigger a stack overflow. The solution implemented in this CL
      is to optionally apply an offset to the stack check s.t. the check
      becomes 'sp - offset > limit'. The offset is applied to stack checks at
      function-entry, and is set to the difference between the optimized and
      unoptimized frame size.
      
      A caveat: OSR may not be fully handled by this fix since we've already
      passed the function-entry stack check. A possible solution would be to
      *not* skip creation of function-entry stack checks for inlinees.
      
      This CL: 1. annotates stack check nodes with the stack check kind, where
      kind is one of {function-entry,iteration-body,unknown}. 2. potentially
      allocates a temporary register to store the result of the 'sp - offset'
      in instruction selection (and switches input registers to 'unique'
      mode). 3. Applies the offset in code generation.
      
      Drive-by: Add src/compiler/globals.h for compiler-specific globals.
      
      Bug: v8:9534,chromium:1000887
      Change-Id: I257191c4a4978ccb60cfa5805ef421f30f0e9826
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1762521
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63701}
      4a16305b
  21. 11 Sep, 2019 2 commits
  22. 09 Sep, 2019 2 commits
  23. 13 Aug, 2019 2 commits
  24. 12 Aug, 2019 4 commits
    • Zhi An Ng's avatar
      Revert "Implement F64x2Div for x64" · 10a1ad25
      Zhi An Ng authored
      This reverts commit 7cefcded.
      
      Reason for revert: ubsan failures, see https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/7465
      
      Original change's description:
      > Implement F64x2Div for x64
      > 
      > Bug: v8:8460
      > Change-Id: I78cb2badab3f28621f91d6ff5f455967fdcbee44
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731782
      > Reviewed-by: Bill Budge <bbudge@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Commit-Queue: Zhi An Ng <zhin@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63171}
      
      TBR=bbudge@chromium.org,mstarzinger@chromium.org,gdeepti@chromium.org,zhin@chromium.org
      
      Change-Id: I17db933763ba966a2d3f8be58e586b6a61f7995e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:8460
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1749712Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63172}
      10a1ad25
    • Ng Zhi An's avatar
      Implement F64x2Div for x64 · 7cefcded
      Ng Zhi An authored
      Bug: v8:8460
      Change-Id: I78cb2badab3f28621f91d6ff5f455967fdcbee44
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731782Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63171}
      7cefcded
    • Jakob Gruber's avatar
      [compiler] Remove LoadStackPointer and related machinery · 5b2ab2f6
      Jakob Gruber authored
      Now that all uses of LoadStackPointer have been removed, this CL cleans
      up related code:
      
      - Removed LoadStackPointer.
      - Removed ArchStackPointer.
      - Removed IA32StackCheck.
      - Removed X64StackCheck.
      - Removed StackCheckMatcher.
      
      All stack checks now follow a simple path without matchers or special
      register constraints: they load the limit and pass it to
      StackPointerGreaterThan, which is finally handled by code generation.
      
      Bug: v8:9534
      Change-Id: Ib1d7be1502a471541d6441f3261aac0c949525fb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1748737
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63166}
      5b2ab2f6
    • Jakob Gruber's avatar
      [compiler] Refactor stack check handling · 0aa204fe
      Jakob Gruber authored
      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.
      
      Bug: v8:9534
      Change-Id: I0e3f1beeed65b163c4ee5787600bed8c3cc671e1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1738863Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63156}
      0aa204fe
  25. 02 Aug, 2019 1 commit
  26. 30 Jul, 2019 1 commit
  27. 25 Jul, 2019 2 commits
  28. 19 Jul, 2019 3 commits
  29. 16 Jul, 2019 1 commit