commit 610c1976fe17b5bfb12eefe1e6dc7c3a5bd5141a
author Darius M <dmercadier@chromium.org> Thu Aug 10 14:33:36 2023
committer V8 LUCI CQ <v8-scoped@luci-project-accounts.iam.gserviceaccount.com> Fri Aug 11 08:04:57 2023
tree 41c76c0756ddaa95fa737f36dad965508fee44a1
parent d7548f2f109479a78f216c27c7032dc230925f8d

[turboshaft] Fix LoadElimination bug with Typed Arrays

Turboshaft's LateLoadElimination assumed that Loads and Store at
different offsets couldn't overlap. However, this doesn't hold for
TypedArrays:

    function f(u32s, u8s) {
      u32s[0] = 0xffffffff;
      u8s[1] = 0;
      return u32s[0];
    }

In this example, the 2 stores could overlap despite having different
offsets.

In practice, it was already safe before this CL, because Loads/Stores
from/to TypedArrays always require some computation of the base, which
prevents Load Elimination (GVN would have to run in parallel of Load
Elimination for this to work). Still, relying on the fact that GVN
never runs during Load Elimination sounds like bugs waiting to happen.

This CL fixes this issue by invalidating more offsets when a Store in
a TypedArray is performed. TypedArray stores/loads can only overlap
with other TypedArray stores/loads, which will all have a
tagged_base=false (unlike regular stores/loads). So, we keep 2
separate MemoryContentTable: one for tagged_base and one for
untagged_base. When invalidating at offset `x` in the untagged_base
one, we actually invalidate from offset `x-7` up to `x+7`.

Bug: v8:12783
Change-Id: I8c2959e770e18c8d176c47a7a90505eb60df8ae5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4712107
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#89487}