1. 13 Jul, 2022 1 commit
  2. 05 Jul, 2022 2 commits
    • Maya Lekova's avatar
      Reland "[fastcall] Support EnforceRange annotation" · 8559a04f
      Maya Lekova authored
      This is a reland of commit 84e078c6. It fixes an undefined behaviour and guards against NaNs in d8-test.cc.
      
      Original change's description:
      > [fastcall] Support EnforceRange annotation
      >
      > This CL implements checks in case EnforceRange is requested for a
      > given parameter by using TryTruncate* operators. It implements 2 such
      > truncations on x64 and arm64 - TryTruncateFloat64ToInt32 and
      > TryTruncateFloat64ToUint32.
      >
      > Bug: chromium:1052746
      > Change-Id: I32f34d9dc1265af568cc576663620a8f7f8245f6
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3721618
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Maya Lekova <mslekova@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#81512}
      
      Bug: chromium:1052746, chromium:1341851, chromium:1341891
      Change-Id: I21e0e452c92cc93f8b06985a335f409855be0546
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3743518Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81529}
      8559a04f
    • Manos Koukoutos's avatar
      Revert "[fastcall] Support EnforceRange annotation" · d9b62c16
      Manos Koukoutos authored
      This reverts commit 84e078c6.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/22000/overview
      
      Original change's description:
      > [fastcall] Support EnforceRange annotation
      >
      > This CL implements checks in case EnforceRange is requested for a
      > given parameter by using TryTruncate* operators. It implements 2 such
      > truncations on x64 and arm64 - TryTruncateFloat64ToInt32 and
      > TryTruncateFloat64ToUint32.
      >
      > Bug: chromium:1052746
      > Change-Id: I32f34d9dc1265af568cc576663620a8f7f8245f6
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3721618
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Commit-Queue: Maya Lekova <mslekova@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#81512}
      
      Bug: chromium:1052746
      Change-Id: I2218681c7cb5d05dea6d8ac5347b19bc0070c1a6
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3743514
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Owners-Override: Manos Koukoutos <manoskouk@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#81513}
      d9b62c16
  3. 04 Jul, 2022 1 commit
  4. 01 Jul, 2022 1 commit
  5. 23 Jun, 2022 1 commit
  6. 02 Jun, 2022 1 commit
  7. 17 May, 2022 1 commit
  8. 13 May, 2022 1 commit
  9. 11 May, 2022 1 commit
  10. 05 May, 2022 2 commits
  11. 22 Apr, 2022 1 commit
  12. 20 Apr, 2022 1 commit
  13. 19 Apr, 2022 1 commit
  14. 15 Dec, 2021 1 commit
    • Samuel Groß's avatar
      V8 Sandbox rebranding · 277fdd1d
      Samuel Groß authored
      This CL renames a number of things related to the V8 sandbox.
      Mainly, what used to be under V8_HEAP_SANDBOX is now under
      V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage
      is now simply the V8 Sandbox:
      
      V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX
      V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS
      V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS
      V8VirtualMemoryCage => Sandbox
      CagedPointer => SandboxedPointer
      fake cage => partially reserved sandbox
      src/security => src/sandbox
      
      This naming scheme should simplify things: the sandbox is now the large
      region of virtual address space inside which V8 mainly operates and
      which should be considered untrusted. Mechanisms like sandboxed pointers
      are then used to attempt to prevent escapes from the sandbox (i.e.
      corruption of memory outside of it). Furthermore, the new naming scheme
      avoids the confusion with the various other "cages" in V8, in
      particular, the VirtualMemoryCage class, by dropping that name entirely.
      
      Future sandbox features are developed under their own V8_SANDBOX_X flag,
      and will, once final, be merged into V8_SANDBOX. Current future features
      are sandboxed external pointers (using the external pointer table), and
      sandboxed pointers (pointers guaranteed to point into the sandbox, e.g.
      because they are encoded as offsets). This CL then also introduces a new
      build flag, v8_enable_sandbox_future, which enables all future features.
      
      Bug: v8:10391
      Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78384}
      277fdd1d
  15. 02 Dec, 2021 1 commit
    • Samuel Groß's avatar
      Use CagedPointers for ArrayBuffer backing stores · 42ed4928
      Samuel Groß authored
      This CL turns references to ArrayBuffer backing stores from
      JSArrayBuffers, JSTypedArrays, and JSDataViews into CagedPointers
      when those are enabled.
      
      CagedPointers cannot generally represent nullptr, as NULL usually lies
      outside the cage. As such, nullptr backing stores are replaced with a
      special empty backing store value, which, in the current implementation,
      points to the end of the cage, right in front of the trailing guard
      regions. Due to this, it is no longer correct to compare a backing store
      pointer against nullptr.
      
      Bug: chromium:1218005
      Change-Id: I4a6c7a82aabb4debcb6bb2babe4035ba2da8e79f
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3244419
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78218}
      42ed4928
  16. 22 Nov, 2021 1 commit
  17. 20 Nov, 2021 1 commit
  18. 18 Nov, 2021 1 commit
  19. 29 Oct, 2021 1 commit
    • Samuel Groß's avatar
      Introduce CagedPointer · afd15549
      Samuel Groß authored
      A CagedPointer is guaranteed to point into the Virtual Memory Cage and
      will for example be used for ArrayBuffer backing stores when the heap
      sandbox is enabled. In the current implementation, CagedPointers are
      stored as offsets from the cage base, shifted to the left. Because the
      cage base address is usually available in a register, accessing a
      CagedPointer is very efficient, requiring only an additional shift and
      add operation.
      
      Bug: chromium:1218005
      Change-Id: Ifc8c088e3862400672051a8c52840514dee2911f
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3123417Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77614}
      afd15549
  20. 06 Oct, 2021 1 commit
  21. 30 Sep, 2021 1 commit
  22. 15 Sep, 2021 2 commits
  23. 09 Sep, 2021 1 commit
  24. 08 Sep, 2021 1 commit
    • Ng Zhi An's avatar
      Reland "[wasm-simd][arm64] Fuse add and extmul" · c03354b4
      Ng Zhi An authored
      This is a reland of 65515ddd
      
      Fix is to use AddWithWraparound for signed additions to avoid UB.
      
      Original change's description:
      > [wasm-simd][arm64] Fuse add and extmul
      >
      > We can select a better instruction for add+extmul, using one of the
      > multiply-long-accumulate instruction.
      >
      > Define a helper struct to pattern match Add(x, OP(y, z)) and
      > Add(OP(x, y) z), and ensure that the matched OP is always on the
      > LHS, to simplify checking for matches.
      >
      > Bug: v8:11548
      > Change-Id: I7ab488b262aa9f749785f973549ccd9fad72f4c8
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2826725
      > Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
      > Commit-Queue: Zhi An Ng <zhin@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#76708}
      
      Bug: v8:11548
      Change-Id: I675ab8b78d9c6c30b82a8c96c8e7098a548c6a60
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3144379
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Reviewed-by: 's avatarDeepti Gandluri <gdeepti@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76712}
      c03354b4
  25. 07 Sep, 2021 2 commits
  26. 26 Aug, 2021 1 commit
  27. 23 Aug, 2021 1 commit
  28. 19 Aug, 2021 3 commits
  29. 17 Aug, 2021 1 commit
  30. 13 Aug, 2021 5 commits
    • Shu-yu Guo's avatar
      [compiler] Compress atomic opcode encoding · 36827318
      Shu-yu Guo authored
      To free up some ArchOpcode bits (especially for arm64), encode all
      atomic opcodes that are duplicated between 32bit and 64bit widths with a
      single opcode and encode the width in another field.
      
      Bug: v8:12093
      Change-Id: Ide05e8f0b2aa877ea776851e47df60dd410deae2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3093257Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76289}
      36827318
    • Clemens Backes's avatar
      [wasm][arm64] Fix 16-bit to 32-bit sign extension · 4d073008
      Clemens Backes authored
      This is identical to https://crrev.com/c/3094011, but for 16-bit values.
      We introduce another instruction to differentiate between 16->32 bit
      sign extensions and 16->64 bit sign extensions.
      
      R=ahaas@chromium.org, mslekova@chromium.org
      
      Bug: chromium:1239116
      Change-Id: I2742e9d9c2b4a038fc7a0b1715faf8f25fa20b1f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094012
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76284}
      4d073008
    • Clemens Backes's avatar
      [wasm][arm64] Fix zero-extention of i32.load8_s · 748ae7cb
      Clemens Backes authored
      InstructionSelector::ZeroExtendsWord32ToWord64 assumes that a
      Load[kRepWord8|kTypeInt32] generates a zero-extended value. This
      assumption makes sense, but was not fulfilled by the instruction
      selector which emitted an "ldrsb" instruction which sign-extended to the
      full 64-bit register.
      
      This CL fixes that by introducing a separate "LdrsbW" instruction which
      is selected if we are sign-extending an 8-bit value to 32-bit.
      
      R=ahaas@chromium.org, mslekova@chromium.org
      CC=v8-arm-ports@googlegroups.com
      
      Bug: chromium:1239116
      Change-Id: I2da1ad6062805acf5558f3e66b8db9a50e830302
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094011
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76283}
      748ae7cb
    • Clemens Backes's avatar
      Revert "[arm64][wasm] Use NEON S/Usra for Wasm SIMD add(shr(x, imm), y)" · 55e6a51f
      Clemens Backes authored
      This reverts commit 2261e053.
      
      Reason for revert: No issues with the CL, but it is taking the
      last two available opcodes on arm64 (we use 9 bits to encode it,
      so we are limited to 512 opcodes). We need to land a security fix
      which includes the addition of two opcodes. Before relanding this,
      we need to figure out a strategy to either reduce opcodes, or use
      one more bit to encode them.
      
      Original change's description:
      > [arm64][wasm] Use NEON S/Usra for Wasm SIMD add(shr(x, imm), y)
      >
      > A single AArch64 SIMD signed/unsigned Shift Right and Accumulate can be
      > used to implement Wasm SIMD add(shr(x, imm), y). This gives a 1-1.5%
      > improvement on some compute intensive Wasm benchmarks on Neoverse-N1.
      >
      > Mla and Adalp optimisations were refactored to match the style of the
      > added code.
      >
      > Change-Id: Id5959a31ca267e02b7d60e7ff6f942adb029b41e
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3089157
      > Reviewed-by: Zhi An Ng <zhin@chromium.org>
      > Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
      > Cr-Commit-Position: refs/heads/master@{#76280}
      
      Change-Id: Ifad0625ed8a6b66e7a7a74da11ad7d60941207e5
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094014
      Auto-Submit: Clemens Backes <clemensb@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#76282}
      55e6a51f
    • Ilja Iskovs's avatar
      [arm64][wasm] Use NEON S/Usra for Wasm SIMD add(shr(x, imm), y) · 2261e053
      Ilja Iskovs authored
      A single AArch64 SIMD signed/unsigned Shift Right and Accumulate can be
      used to implement Wasm SIMD add(shr(x, imm), y). This gives a 1-1.5%
      improvement on some compute intensive Wasm benchmarks on Neoverse-N1.
      
      Mla and Adalp optimisations were refactored to match the style of the
      added code.
      
      Change-Id: Id5959a31ca267e02b7d60e7ff6f942adb029b41e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3089157Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
      Cr-Commit-Position: refs/heads/master@{#76280}
      2261e053