Stream: git-wasmtime

Topic: wasmtime / PR #12222 Support for no_std in cranelift_codegen


view this post on Zulip Wasmtime GitHub notifications bot (Jan 01 2026 at 21:21):

the-ssd edited PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 01 2026 at 21:29):

the-ssd edited PR #12222:

Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.

There is already #9007, which stalled.

And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).

What is left to do:

For codegen I also added a prelude file, with all imports, because it was easier this way for now. I put preludes at the bottom, because at the top, some file would break because of ///! doc comments. Should I redo it, and move them to the top, or avoid prelude fully?

Edit: prelude can be added by replacing first use of use with use crate::prelude::*;\n use instead of putting it at the bottom

view this post on Zulip Wasmtime GitHub notifications bot (Jan 01 2026 at 23:05):

the-ssd edited PR #12222:

Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.

There is already #9007, which stalled.

And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).

What is left to do:

For codegen I also added a prelude file, with all imports, because it was easier this way for now. I put preludes at the bottom, because at the top, some file would break because of ///! doc comments. Should I redo it, and move them to the top, or avoid prelude fully?

Edit: prelude can be added by replacing first use of use with use crate::prelude::*;\n use instead of putting it at the bottom

view this post on Zulip Wasmtime GitHub notifications bot (Jan 01 2026 at 23:16):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 01 2026 at 23:18):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 01 2026 at 23:55):

the-ssd edited PR #12222:

Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.

There is already #9007, which stalled.

And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).

What is left to do:

For codegen I also added a prelude file, with all imports, because it was easier this way for now. I put preludes at the bottom, because at the top, some file would break because of ///! doc comments. Should I redo it, and move them to the top, or avoid prelude fully?

Edit: prelude can be added by replacing first use of use with use crate::prelude::*;\n use instead of putting it at the bottom

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 06:43):

the-ssd edited PR #12222:

Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.

There is already #9007, which stalled.

And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).

What is left to do:

For codegen I also added a prelude file, with all imports, because it was easier this way for now. I put preludes at the bottom, because at the top, some file would break because of ///! doc comments. Should I redo it, and move them to the top, or avoid prelude fully?

Edit: prelude can be added by replacing first use of use with use crate::prelude::*;\n use instead of putting it at the bottom

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 06:57):

the-ssd commented on PR #12222:

I found something that might be useful.

https://rust-lang.github.io/rust-clippy/master/#std_instead_of_core
https://rust-lang.github.io/rust-clippy/master/#alloc_instead_of_core
https://rust-lang.github.io/rust-clippy/master/#std_instead_of_alloc

source

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 07:28):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 07:28):

the-ssd edited PR #12222:

Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.

There is already #9007, which stalled.

And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).

What is left to do:

For codegen I also added a prelude file, with all imports, because it was easier this way for now. I put preludes at the bottom, because at the top, some file would break because of ///! doc comments. Should I redo it, and move them to the top, or avoid prelude fully?

Edit: prelude can be added by replacing first use of use with use crate::prelude::*;\n use instead of putting it at the bottom

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 07:56):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 07:58):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 08:47):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 09:05):

the-ssd edited PR #12222:

Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.

There is already #9007, which stalled.

And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).

What is left to do:

For codegen I also added a prelude file, with all imports, because it was easier this way for now. I put preludes at the bottom, because at the top, some file would break because of ///! doc comments. Should I redo it, and move them to the top, or avoid prelude fully?

Edit: prelude can be added by replacing first use of use with use crate::prelude::*;\n use instead of putting it at the bottom

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 09:15):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 09:30):

the-ssd edited PR #12222:

Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.

There is already #9007, which stalled.

And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).

What is left to do:

For codegen I also added a prelude file, with all imports, because it was easier this way for now. I put preludes at the bottom, because at the top, some file would break because of ///! doc comments. Should I redo it, and move them to the top, or avoid prelude fully?

Edit: prelude can be added by replacing first use of use with use crate::prelude::*;\n use instead of putting it at the bottom

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 09:30):

the-ssd edited PR #12222:

Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.

There is already #9007, which stalled.

And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).

What is left to do:

For codegen I also added a prelude file, with all imports, because it was easier this way for now. I put preludes at the bottom, because at the top, some file would break because of ///! doc comments. Should I redo it, and move them to the top, or avoid prelude fully?

Edit: prelude can be added by replacing first use of use with use crate::prelude::*;\n use instead of putting it at the bottom

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 09:30):

the-ssd edited PR #12222:

Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.

There is already #9007, which stalled.

And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).

What is left to do:

For codegen I also added a prelude file, with all imports, because it was easier this way for now. I put preludes at the bottom, because at the top, some file would break because of ///! doc comments. Should I redo it, and move them to the top, or avoid prelude fully?

Edit: prelude can be added by replacing first use of use with use crate::prelude::*;\n use instead of putting it at the bottom

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 10:52):

the-ssd submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 10:52):

the-ssd created PR review comment:

When https://github.com/rust-lang/compiler-builtins/pull/1053 is merged, feature unstable-public-internals can be removed, and this changed to Libm::<$float_ty>::roundeven

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 11:16):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 11:19):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 11:44):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 11:47):

the-ssd commented on PR #12222:

I've removed OnceLock, but MachineEnv is now recomputed each time.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 11:48):

the-ssd edited PR #12222:

Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.

There is already #9007, which stalled.

And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).

What is left to do:

For codegen I also added a prelude file, with all imports, because it was easier this way for now. I put preludes at the bottom, because at the top, some file would break because of ///! doc comments. Should I redo it, and move them to the top, or avoid prelude fully?

Edit: prelude can be added by replacing first use of use with use crate::prelude::*;\n use instead of putting it at the bottom

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 11:48):

the-ssd edited PR #12222:

Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.

There is already #9007, which stalled.

And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).

What is left to do:

For codegen I also added a prelude file, with all imports, because it was easier this way for now. I put preludes at the bottom, because at the top, some file would break because of ///! doc comments. Should I redo it, and move them to the top, or avoid prelude fully?

Edit: prelude can be added by replacing first use of use with use crate::prelude::*;\n use instead of putting it at the bottom

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 11:49):

the-ssd edited PR #12222:

Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.

There is already #9007, which stalled.

And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).

What is left to do:

view this post on Zulip Wasmtime GitHub notifications bot (Jan 02 2026 at 11:53):

the-ssd commented on PR #12222:

core feature can be removed

view this post on Zulip Wasmtime GitHub notifications bot (Jan 03 2026 at 07:06):

the-ssd has marked PR #12222 as ready for review.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 03 2026 at 07:06):

the-ssd requested abrown for a review on PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 03 2026 at 07:06):

the-ssd requested wasmtime-compiler-reviewers for a review on PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 03 2026 at 07:06):

the-ssd requested wasmtime-default-reviewers for a review on PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 03 2026 at 07:06):

the-ssd edited PR #12222:

Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.

There is already #9007, which stalled.

And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).

What is left to do:

view this post on Zulip Wasmtime GitHub notifications bot (Jan 03 2026 at 07:28):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 03 2026 at 11:01):

the-ssd commented on PR #12222:

Diff is a bit weird, it thinks there are more changes than there should be, should I squash the commits myself?

view this post on Zulip Wasmtime GitHub notifications bot (Jan 03 2026 at 12:17):

the-ssd commented on PR #12222:

https://github.com/gimli-rs/gimli/pull/855
maybe even unwind can be supported on no_std.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 16:32):

the-ssd edited PR #12222:

Closes #1158, allows for cranelift to be used in a no_std environment, like a kernel.

There is already #9007, which stalled.

And I am at a point I think it makes sense to ask someone what do you want to be done about FxHashMap and OnceLock. There are alternative crates that implement it, like this one (also has a comparison chart).

What is left to do:

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 17:05):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 21:42):

alexcrichton submitted PR review:

Ah I just indeed saw this was merged. Feel free to rebase this as well @the-ssd since when we merge PRs it's always a squash-and-push strategy so it'll all become one commit anyway.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 21:42):

alexcrichton created PR review comment:

This is a pretty small prelude module so ideally we wouldn't need it. I think that a #[macro_use] on the extern crate alloc in this crate might remove the need for these?

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 21:42):

alexcrichton created PR review comment:

Given the name of this feature, this doesn't seem like something we should be relying on?

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 21:42):

alexcrichton created PR review comment:

Would you be ok splitting this out to a separate PR? For example landing everything else in this PR except the CI changes + this get_machine_env change? This is something we'll need to fix one way or another I believe since IIRC historical benchmarking showed that is needs to be not-created-every-time-on-use.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 21:42):

alexcrichton created PR review comment:

Mind backing out formatting-related changes in this file to make it easier to see what's actually changing?

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 21:45):

the-ssd submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 21:45):

the-ssd created PR review comment:

Yes, it's temporary, until next version of libm is released. Because of a typo a function is call roundeven for f32 and roundevem for f64. I wasn't sure how to work around it with the macro without changing inputs. PR that fixes the typo was already merged

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 21:46):

the-ssd submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 21:46):

the-ssd created PR review comment:

Oh, ok let me check

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 21:51):

the-ssd submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 21:51):

the-ssd created PR review comment:

I actually only started it becase of this https://github.com/bytecodealliance/wasmtime/pull/8489#issuecomment-2105129901. Either way moving it to a separate PR makes sense

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:04):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:04):

alexcrichton created PR review comment:

While we're waiting for that to merge, could Cranelift be updated to avoid using the Libm trait? That would enable being able to land this and use it sooner

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:05):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:09):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:10):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:29):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:32):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:33):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:35):

the-ssd submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:35):

the-ssd created PR review comment:

Unsure if this is correct

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:35):

the-ssd submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:35):

the-ssd created PR review comment:

Done

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:41):

the-ssd submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:41):

the-ssd created PR review comment:

Libm trait is stable, and it simplifies it, because libm has separate functions for f32, and f64.
Since it is already merged, git version can be used, or round_ties_even can be left unchanged, and fixed in a later PR, when new libm version is published.

Basically unstable-public-internals is only needed for round_ties_even

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:42):

the-ssd edited PR review comment.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:44):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:51):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:52):

the-ssd submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:52):

the-ssd created PR review comment:

reverted

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:58):

the-ssd updated PR #12222.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:59):

the-ssd submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 05 2026 at 22:59):

the-ssd created PR review comment:

I updated it and added a comment explaining why it wasn't changed


Last updated: Jan 09 2026 at 13:15 UTC