Stream: git-wasmtime

Topic: wasmtime / PR #3117 cranelift: Move most debug-level logs...

Wasmtime GitHub notifications bot (Jul 26 2021 at 19:02):

fitzgen opened PR #3117 from log-levels to main:

Cranelift crates have historically been much more verbose with debug-level
logging than most other crates in the Rust ecosystem. We log things like how
many parameters a basic block has, the color of virtual registers during
regalloc, etc. Even for Cranelift hackers, these things are largely only useful
when hacking specifically on Cranelift and looking at a particular test case,
not even when using some Cranelift embedding (such as Wasmtime).

Most of the time, when people want logging for their Rust programs, they do
something like:

RUST_LOG=debug cargo run

This means that they get all that mostly not useful debug logging out of
Cranelift. So they might want to disable logging for Cranelift, or change it to
a higher log level:

RUST_LOG=debug,cranelift=info cargo run

The problem is that this is already more annoying to type that RUST_LOG=debug,
and that Cranelift isn't one single crate, so you actually have to play
whack-a-mole with naming all the Cranelift crates off the top of your head,
something more like this:

RUST_LOG=debug,cranelift=info,cranelift_codegen=info,cranelift_wasm=info,...

Therefore, we're changing most of the debug! logs into trace! logs: anything
that is very Cranelift-internal, unlikely to be useful/meaningful to the
"average" Cranelift embedder, or prints a message for each instruction visited
during a pass. On the other hand, things that just report a one line statistic
for a whole pass, for example, are left as debug!. The more verbose the log
messages are, the higher the bar they must clear to be debug! rather than
trace!.

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Jul 26 2021 at 19:02):

fitzgen requested cfallin for a review on PR #3117.

Wasmtime GitHub notifications bot (Jul 26 2021 at 19:13):

bjorn3 created PR review comment:

I think this should remain debug!.

Wasmtime GitHub notifications bot (Jul 26 2021 at 19:13):

bjorn3 submitted PR review.

Wasmtime GitHub notifications bot (Jul 26 2021 at 19:13):

bjorn3 created PR review comment:

And this one.

Wasmtime GitHub notifications bot (Jul 26 2021 at 19:13):

bjorn3 submitted PR review.

Wasmtime GitHub notifications bot (Jul 26 2021 at 19:14):

bjorn3 edited PR review comment.

Wasmtime GitHub notifications bot (Jul 26 2021 at 19:39):

cfallin submitted PR review.

Wasmtime GitHub notifications bot (Jul 26 2021 at 19:39):

cfallin created PR review comment:

I think I actually err the other way on this one: the VCode dump is potentially thousands of lines for large functions; including all of the compiled IR in the debug log is potentially much more verbose than the other sorts of entries that people typically generate.

Wasmtime GitHub notifications bot (Jul 26 2021 at 19:52):

cfallin submitted PR review.

Wasmtime GitHub notifications bot (Jul 26 2021 at 19:52):

cfallin merged PR #3117.

Last updated: Oct 23 2024 at 20:03 UTC