b49cea5506
When TurboFan generates code for TypedArray access for which we have seen different ElementsKinds, we might end up accessing the TypedArray's length directly when we are inlining into a call site where the TypedArray is known. This access could also happen for ElementsKind cases that are different from the actual TypedArray, which caused a DCHECK failure for cases where length access is prohibited (e.g. for rab/gsab backed TAs). Since these cases are not reachable at runtime, this CL removes the incorrect length access and generates an Unreachable node in the graph instead. Bug: chromium:1393942 Change-Id: I1171531210bf6d1f14a58c4beefb0a3b70a646cc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061314 Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Darius Mercadier <dmercadier@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#84524}
27 lines
623 B
JavaScript
27 lines
623 B
JavaScript
// Copyright 2022 the V8 project authors. All rights reserved.
|
|
// Use of this source code is governed by a BSD-style license that can be
|
|
// found in the LICENSE file.
|
|
//
|
|
// Flags: --harmony-rab-gsab --allow-natives-syntax
|
|
|
|
const gsab = new SharedArrayBuffer(4,{"maxByteLength":8});
|
|
const u16arr = new Uint16Array(gsab);
|
|
|
|
function foo(obj) {
|
|
obj[1] = 0;
|
|
}
|
|
|
|
function test() {
|
|
const u32arr = new Uint32Array();
|
|
foo(u32arr);
|
|
foo(u16arr);
|
|
}
|
|
|
|
%PrepareFunctionForOptimization(test);
|
|
%PrepareFunctionForOptimization(foo);
|
|
test();
|
|
%OptimizeFunctionOnNextCall(foo);
|
|
test();
|
|
%OptimizeFunctionOnNextCall(test);
|
|
test();
|