Minor cleanups to the wasm inlining budget logic
Categories
(Core :: JavaScript: WebAssembly, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox134 | --- | fixed |
People
(Reporter: jseward, Assigned: jseward)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
Bug 1927061 introduced inlining budgets for functions and for entire modules.
That has unfortunately a couple of rough edges that should be fixed.
-
the situation where a per-function or per-module budget is exactly zero is
ambiguous. As a result the logging machinery (MOZ_LOG=wasmPerf:3) can print
an "Inlining budget for fI=... exceeded" a different number of times from the
number shown in the final "... functions overran inlining budget" message.It also means the "Inlining budget for fI=... exceeded" message is printed
for all functions when we have --wasm-compiler=ion.This patch removes the ambiguity by having a value of zero mean "budget not
exceeded"; hence it is the 0-vs-negative transition that is important. This
fixes the above problems. -
two JS_LOGs were not protected by
#ifdef JS_JITSPEW
as they should have
been.
Assignee | ||
Comment 1•29 days ago
|
||
Bug 1927061 introduced inlining budgets for functions and for entire modules.
That has unfortunately a couple of rough edges that this patch fixes.
-
The situation where a per-function or per-module budget is exactly zero is
ambiguous. As a result the logging machinery (MOZ_LOG=wasmPerf:3) can print
the "Inlining budget for fI=... exceeded" message a different number of
times from the number shown in the final "... functions overran inlining
budget" message.It also causes the "Inlining budget for fI=... exceeded" message to be
printed for all functions when we have --wasm-compiler=ion.This patch removes the ambiguity and fixes the above by having a value of
zero mean "budget not exceeded"; hence it is the zero-to-negative transition
that is important. -
two JS_LOGs were not protected by #ifdef JS_JITSPEW as they should have
been.
Description
•