-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Add logging support for debugging ISLE rules #12233
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Subscribe to Label ActionDetailsThis issue or pull request has been labeled: "cranelift", "isle"Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
cfallin
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Happy to merge with the one question below answered/addressed. This will definitely be helpful tracing rule applications!
cranelift/isle/isle/src/codegen.rs
Outdated
| let pp = pos.pretty_print_line(&self.files); | ||
| writeln!( | ||
| ctx.out, | ||
| "{}#[cfg(feature = \"trace-log\")] log::debug!(\"ISLE {{}} {{}}\", \"{}\", \"{}\");", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need the #[cfg(feature = "trace-log")] here, since we are already conditionalizing this bit of codegen on the trace-log feature via the emit_logging option, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, the feature guard isn't necessary as you pointed out, and the test below demonstrates you can safely remove the guard.
> RUST_LOG=cranelift_codegen::opts::generated_code=trace cargo run -p cranelift-tools --bin clif-util -- co
mpile --target x86_64-unknown-linux-gnu --set opt_level=speed ../../keccak-no-opts.clif 2>&1 | head -n10
...
[2026-01-04T04:52:21Z DEBUG cranelift_codegen::opts::generated_code] ISLE simplify src/opts/remat.isle line 25
[2026-01-04T04:52:21Z DEBUG cranelift_codegen::opts::generated_code] ISLE simplify src/opts/remat.isle line 5
[2026-01-04T04:52:21Z DEBUG cranelift_codegen::opts::generated_code] ISLE simplify src/opts/remat.isle line 25
[2026-01-04T04:52:21Z DEBUG cranelift_codegen::opts::generated_code] ISLE simplify src/opts/remat.isle line 5
[2026-01-04T04:52:21Z DEBUG cranelift_codegen::opts::generated_code] ISLE simplify src/opts/remat.isle line 25
[2026-01-04T04:52:21Z DEBUG cranelift_codegen::opts::generated_code] ISLE simplify src/opts/remat.isle line 5
[2026-01-04T04:52:21Z DEBUG cranelift_codegen::opts::generated_code] ISLE simplify src/opts/remat.isle line 25
[2026-01-04T04:52:21Z DEBUG cranelift_codegen::opts::generated_code] ISLE simplify src/opts/remat.isle line 5
> cargo run -p cranelift-tools --bin clif-util -- compile --target x86_64-unknown-linux-gnu --set opt_level
=speed ../../data/clif/keccak-no-opts.clif 2>&1 | head -n10
[No output]
I didn't catch this. Thanks!
|
@bongjunj it looks like this fails on Windows (see this CI job) because the paths have backslashes, and when embedding those into strings, they become (ill-formed) escapes. Could you address by either replacing |
|
I have changed the string embedding from |
resolves #11971
Run the following command to check:
Should print logs such as: