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}
4e983705e5