Stream: git-wasmtime

Topic: wasmtime / PR #10538 asm: fix trace logging of XMM registers

Wasmtime GitHub notifications bot (Apr 07 2025 at 16:42):

abrown requested cfallin for a review on PR #10538.

Wasmtime GitHub notifications bot (Apr 07 2025 at 16:42):

abrown requested wasmtime-compiler-reviewers for a review on PR #10538.

Wasmtime GitHub notifications bot (Apr 07 2025 at 16:42):

abrown opened PR #10538 from abrown:fix-10529 to bytecodealliance:main:

Along the lines of #10389 and #10478, this change fixes the case where an XMM register is pretty-printed during logging, which may happen before register allocation has provided a true HW register.

Fixes #10529.

<!--
Please make sure you include the following information:

• If this work has been discussed elsewhere, please include a link to that
  conversation. If it was discussed in an issue, just mention "issue #...".

• Explain why this change is needed. If the details are in an issue already,
  this can be brief.

Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Apr 07 2025 at 16:45):

alexcrichton commented on PR #10538:

Could the test added in https://github.com/bytecodealliance/wasmtime/pull/10478 be expanded to cover this too?

Wasmtime GitHub notifications bot (Apr 07 2025 at 17:37):

abrown commented on PR #10538:

Could the test added in #10478 be expanded to cover this too?

Yeah, we need a few more SSE lowerings plumbed through to really trigger this; I can't seem to find one that actually goes all the way from WAT to the assembler that will use an XMM register and trigger this.

Wasmtime GitHub notifications bot (Apr 07 2025 at 23:48):

cfallin submitted PR review:

Thanks!

An idle thought about testing: would it be possible to run the filetests in CI with RUST_LOG=trace? That would certainly give us coverage of almost all or all lowerings (we expect them all to be tested); only uncertainty is what it would do to test time, but probably OK?

Wasmtime GitHub notifications bot (Apr 08 2025 at 21:22):

abrown commented on PR #10538:

Thanks!

An idle thought about testing: would it be possible to run the filetests in CI with RUST_LOG=trace? That would certainly give us coverage of almost all or all lowerings (we expect them all to be tested); only uncertainty is what it would do to test time, but probably OK?

I think that makes sense. Here's a slowdown comparison:

$ cd cranelift
$ RUST_LOG=cranelift_codegen=trace /usr/bin/time cargo test
...
24.65user 0.57system 0:04.66elapsed 540%CPU

$ cd cranelift
$ /usr/bin/time cargo test
...
17.79user 0.12system 0:04.18elapsed 427%CPU

Slower, but perhaps worth it. Where does this fit in main.yml, though? A whole new test_* job?

Wasmtime GitHub notifications bot (Apr 08 2025 at 21:33):

alexcrichton commented on PR #10538:

This won't fit easily into main.yml unfortunately. The cranelift-tools crate is tested in a "soup" with a bunch of other crates which are partitioned automatically. As global state (RUST_LOG) this also isn't workable as a sibling #[test]. What I might recommend is a sibling cranelift/tests/filetests_with_trace.rs which is mostly the same but configures env_logger or similar. That keeps it isolated into a single process at least.

Wasmtime GitHub notifications bot (Apr 09 2025 at 23:49):

abrown updated PR #10538.

Wasmtime GitHub notifications bot (Apr 09 2025 at 23:55):

abrown commented on PR #10538:

This seems a bit like overkill but, hey, this virtual-vs-HW register panic keeps popping up. ea36958 adds a test to run all the filetests with logging enabled, which I confirmed catches the bug. When everything goes well, this is what I see time-wise:

$ /usr/bin/time cargo test --package cranelift-tools --test filetests
...
14.87user 0.13system 0:01.15elapsed 1304%CPU

$ /usr/bin/time cargo test --package cranelift-tools --test logged-filetests
...
20.41user 0.29system 0:01.42elapsed 1451%CPU

Of course, if anything goes poorly, then one can expect an afternoon-long wait while the test runner prints every log it has captured. I guess that is incentive to keep the pretty-printing working!

Wasmtime GitHub notifications bot (Apr 10 2025 at 00:41):

abrown merged PR #10538.

Last updated: Jan 09 2026 at 13:15 UTC