v8/tools/wasm
Clemens Backes 4e983705e5 [wasm] Tweak constants for estimating code space size
It turned out that on arm and arm64 we over-estimated the code size of a
Wasm module quite a bit. This CL adds some more output for the
--trace-wasm-compilation-times flag, and adds a script to compute the
factors we use for code size estimates from that output.
I ran the script on a few benchmarks (an older Epic module, the current
Photoshop module, and the benchmark from the linked bug), and adjusted
the constants accordingly.

Also, simplify the API of {ReservationSize} to only return a single
number, and fail internally if we need to allocate more than the engine
supports (which would only fail for artificially large modules).

R=jkummerow@chromium.org

Bug: chromium:1302310
Change-Id: I5b2c27ff3e360fb6738cf5dd697bcee09e106b6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3522067
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79482}
2022-03-15 14:41:13 +00:00
..
code-size-factors.py [wasm] Tweak constants for estimating code space size 2022-03-15 14:41:13 +00:00
update-wasm-fuzzers.sh [wasm] Update and run script to generate fuzzer corpus 2020-12-01 16:21:51 +00:00
update-wasm-spec-tests.sh [wasm] Add wasm wpt tests to the V8 tests 2021-09-14 19:10:27 +00:00
wasm-import-profiler-end.js [wasm/tools] Add import profiler 2018-11-22 15:36:21 +00:00
wasm-import-profiler.js [wasm/tools] Add import profiler 2018-11-22 15:36:21 +00:00