Skip to content

V
V8
Switch branch/tag
  1. 18 Jan, 2022 12 commits
  3. 17 Jan, 2022 20 commits
  5. 16 Jan, 2022 1 commit
    • Dan Clark's avatar
      Don't double-fetch a module specified on the d8 command line · 8ee40cfc
      Dan Clark authored 
      Shell::FetchModuleTree assumes that the module at file_name wasn't
already fetched. Shell::ExecuteModule is calling into
FetchModuleTree without checking if the module is already in the module
map, violating this assumption.

This change fixes this by having Shell::ExecuteModule check for the
existence of the module before calling into Shell::ExecuteModule, the
same way that Shell::DoHostImportModuleDynamically does.

Bug: v8:12530
Change-Id: Ia038cbd1715e85c9c92c4554fd486c657ef952e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3388130Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78636}
      8ee40cfc
  7. 15 Jan, 2022 3 commits
  9. 14 Jan, 2022 4 commits
    • Clemens Backes's avatar
      [compiler] Do not rely on register indexes · 010fcac1
      Clemens Backes authored 
      For getting from one SIMD "sibling" register to the other, the mid tier
register allocator was relying on the indexes of the two registers to be
{2N} and {2N+1}. This is only true for lower SIMD registers; later
registers can be at {2N-1} and {2N} instead, because of holes in the
allocatable double registers (e.g. d13-d15 are not allocatable currently
on ARM).

We can rely on other facts though:
1) The two aliasing registers are always successive.
2) A SIMD register code always maps to the lower register index.
3) We can get from an F32 register code to F64 and from F64 to S128 by
   shifting one bit to the right (this is what
   {RegisterConfiguration::GetAliases} uses).

This bug was uncovered by running the existing
cctest/test-code-generator/FuzzAssemble* tests with either
--turbo-use-mid-tier-regalloc-for-huge-functions or with
--turbo-force-mid-tier-regalloc. Hence it will be covered by these tests
once https://crrev.com/c/3347822 lands.

R=thibaudm@chromium.org
TEST=cctest/test-code-generator/FuzzAssemble*

Bug: v8:12330
Change-Id: I168840fe50b6ba6cdaa6a5462596a5cbf55c87ec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3378782Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78632}
      010fcac1
    • Michael Lippautz's avatar
      Reland "cppgc-js,heap: Implement snapshots for embedder fields" · 804aaa5c
      Michael Lippautz authored 
      This is a reland of 142dd775

Original change's description:
> cppgc-js,heap: Implement snapshots for embedder fields
>
> https://crrev.com/c/3293410 added concurrent processing of C++ objects
> found through V8 embedder fields. The CL missed that those embedder
> fields are not read atomically from JS objects. The problem is that
> embedder fields are only aligned to kTaggedSize on builds with pointer
> compression and are as such mis-aligned for atomic ops. This is not a
> problem for on-heap values as the upper 32bits are anyways computed
> from the cage. Is is a problem for generic C++ values though, as they
> are used with Oilpan.
>
> This CL adds the standard marker snapshot protocol for embedder fields.
>
> Marker:
> 1. Snapshot embedder fields
> 2. Try to mark host object
> 3. On success: process snapshot
>
> Main thread:
> 1. On setting embedder fields mark the object black first
> 2. Emit a write barrier for the embedder fields
>
> This will get simpler with the heap sandbox that uses a separate table
> for embedder fields. Once the sandbox is the default configuration, we
> 	can use it as dependency for the concurrent fast path.
>
> Bug: chromium:1285706
> Change-Id: I6b975ea561be08cda840ef0dd27a11627de93900
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3380983
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#78604}

Bug: chromium:1285706
Change-Id: I024e50fc0757fbcd13cb9ffde027dff55f99d25c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386600Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78631}
      804aaa5c
    • Milad Fa's avatar
      S390 [liftoff]: Implement simd f32x2 unops · 12b7c452
      Milad Fa authored 
      Implementations are added to macro-assembler to be shared between
liftoff and code generator.

Change-Id: I945e312b45d87e021ffd64948bdfd69d0642fb83
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3387608Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78630}
      12b7c452
    • Junliang Yan's avatar
      s390x: [baseline] implement Store functions · 2e147b4f
      Junliang Yan authored 
      Change-Id: If401e5c9d1ab6f293de2d8efed1f885683667408
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386389Reviewed-by: 's avatarMilad Farazmand <mfarazma@redhat.com>
Commit-Queue: Junliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#78629}
      2e147b4f