Closed Bug 1442540 Opened 2 years ago Closed 9 months ago
Compute true values of arm64Baseline
Bytes Per Bytecode and related definitions
In wasm/WasmCompile.cpp we have some constants that we use to estimate the size of the output of the compiler from the size of the bytecode we're compiling, so that we can pre-size the output buffers and not incur a lot of copying overhead. For ARM64 the current values are guesses that are not even used until the ARM64 baseline compiler lands. We need to compute the true values here. Also in that file are guesses about how fast compilation is. We need to provide actual measurements for ARM64 here as well. This is tricky because it depends to some extent on the system class, but anything's better than what we have now. While we're in there we should document the exact methodology used for obtaining the measurements.
Summary: Compute true value of arm64BaselineBytesPerBytecode and related definitions → Compute true values of arm64BaselineBytesPerBytecode and related definitions
Priority: P3 → P1
Target Milestone: --- → mozilla61
Lars, what is the status of this issue? It would not be backported to 61 now, should we track firefox 62?
We need this for 63, but it is not a requirement for 62. Updating flags.
Lars, this bug will probably not make it for 63, do you know when you would be able to look at this bug?
Not until after TPAC, for sure... I'm lowering to P2 because ARM64 is not tremendously important to us yet, and having the "right" value here is not important for correctness. Also, there's some mumbling about maybe using telemtry to gather data here, so it'll happen, but not right now.
Priority: P1 → P2
[arm64:m3] because correctly sizing the compiler's output buffer doesn't need to block publishing ARM64 Fennec Nightly builds. It probably should block ARM64 Fennec riding to Beta.
Agreed. Hope to do this before long as part of bug 1496325.
Also, in ClassifySystem() in WasmCompile.cpp we should worry about what kind of system Windows-on-ARM64 is. Right now it's classified as a mobile system because it's ARM64.
WIP: Compute, retain, and log (when possible) compilation resource use. This is OK as far as it goes, but does not handle second-tier compilation when we tier up, it only reports on the first tier. For the purposes of this particular bug that's probably good enough but we ought to do better.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/16819308720e Empirical ARM64 policy values for wasm tiering. r=luke
You need to log in before you can comment on or make changes to this bug.