6b2fa4c12b
Posting compile tasks from the parser has several issues: 1. We don't know how many functions there will be total, so we can't yet allocate shared_function_infos array on the Script 2. Without this array, inner function compiles can't look up their own inner functions during bytecode finalization, so we can't run that finalization before script parse completes 3. Scope analysis can't have run yet, so we can only post top-level function tasks and if we allocate SharedFunctionInfos early they are forced into a bit of a limbo state without an outer ScopeInfo. Instead, we can post compile tasks during bytecode generation. Then, the script parse is guaranteed to have completed, so we'll have a shared_function_infos array and we will have allocated ScopeInfos already. This also opens the door for posting tasks for compiling more inner functions than just top-level, as well as generating better code for functions/methods that reference same-script top-level let/const/class. Bug: chromium:1267680 Change-Id: Ie1a3a3c6f1b264c4ef28cd4763bfc6dc08f45d4d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277884 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#77894} |
||
---|---|---|
.. | ||
api | ||
asmjs | ||
assembler | ||
base | ||
codegen | ||
compiler | ||
compiler-dispatcher | ||
date | ||
debug | ||
diagnostics | ||
execution | ||
heap | ||
interpreter | ||
libplatform | ||
logging | ||
numbers | ||
objects | ||
parser | ||
profiler | ||
regexp | ||
regress | ||
runtime | ||
security | ||
strings | ||
tasks | ||
torque | ||
utils | ||
wasm | ||
zone | ||
avoid-windows-h-includes.cc | ||
BUILD.gn | ||
DEPS | ||
run-all-unittests.cc | ||
test-helpers.cc | ||
test-helpers.h | ||
test-utils.cc | ||
test-utils.h | ||
testcfg.py | ||
unittests.status |