the-ssd edited PR #12222.
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:
- [x] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [x] separate PRs for: cranelift_assembler_x86 (#12235), moving large parts to core and alloc (this one), and isle (#12236)
- [ ] floating point issues
- [ ] FxHashMap and OnceLock
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
usewithuse crate::prelude::*;\n useinstead of putting it at the bottom
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:
- [x] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [x] separate PRs for: cranelift_assembler_x86 (#12235), moving large parts to core and alloc (todo), and isle (#12236)
- [ ] floating point issues
- [ ] FxHashMap and OnceLock
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
usewithuse crate::prelude::*;\n useinstead of putting it at the bottom
the-ssd updated PR #12222.
the-ssd updated PR #12222.
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:
- [x] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [x] separate PRs for: cranelift_assembler_x86 (#12235), moving large parts to core and alloc (#12237), and isle (#12236)
- [ ] floating point issues
- [ ] FxHashMap and OnceLock
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
usewithuse crate::prelude::*;\n useinstead of putting it at the bottom
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:
- [x] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [x] separate PRs for: cranelift_assembler_x86 (#12235), moving large parts to core and alloc (#12237), and isle (#12236)
- [ ] floating point issues
- [ ] FxHashMap and OnceLock
- [ ] test for codegen compilation, with std, but without unwind
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
usewithuse crate::prelude::*;\n useinstead of putting it at the bottom
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
the-ssd updated PR #12222.
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:
- [x] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [x] separate PRs for: cranelift_assembler_x86 (#12235), moving large parts to core and alloc (#12237), and isle (#12236)
- [ ] floating point issues
- [x] FxHashMap
- [ ] OnceLock
- [ ] test for codegen compilation, with std, but without unwind
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
usewithuse crate::prelude::*;\n useinstead of putting it at the bottom
the-ssd updated PR #12222.
the-ssd updated PR #12222.
the-ssd updated PR #12222.
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:
- [x] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [x] separate PRs for: cranelift_assembler_x86 (#12235), moving large parts to core and alloc (#12237), and isle (#12236)
- [ ] floating point issues
- [x] FxHashMap
- [ ] OnceLock
- [ ] test for codegen compilation, with std, but without unwind
- [ ] libm: roundeven has a typo in it's implementation https://github.com/rust-lang/compiler-builtins/pull/1053, so a hack is used
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
usewithuse crate::prelude::*;\n useinstead of putting it at the bottom
the-ssd updated PR #12222.
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:
- [x] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [x] separate PRs for: cranelift_assembler_x86 (#12235), moving large parts to core and alloc (#12237), and isle (#12236)
- [x] FxHashMap
- [ ] OnceLock
- [ ] floating point issues
- [ ] test for codegen compilation, with std, but without unwind
- [ ] libm: roundeven has a typo in it's implementation https://github.com/rust-lang/compiler-builtins/pull/1053, so a hack is used
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
usewithuse crate::prelude::*;\n useinstead of putting it at the bottom
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:
- [x] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [x] separate PRs for: cranelift_assembler_x86 (#12235), moving large parts to core and alloc (#12237), and isle (#12236)
- [ ] floating point issues
- [x] FxHashMap
- [ ] OnceLock
- [ ] test for codegen compilation, with std, but without unwind
- [ ] libm: roundeven has a typo in it's implementation https://github.com/rust-lang/compiler-builtins/pull/1053, so a hack is used
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
usewithuse crate::prelude::*;\n useinstead of putting it at the bottom
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:
- [x] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [x] separate PRs for: cranelift_assembler_x86 (#12235), moving large parts to core and alloc (#12237), and isle (#12236)
- [x] floating point issues
- [x] FxHashMap
- [ ] OnceLock
- [ ] test for codegen compilation, with std, but without unwind
- [ ] libm: roundeven has a typo in it's implementation https://github.com/rust-lang/compiler-builtins/pull/1053, so a hack is used
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
usewithuse crate::prelude::*;\n useinstead of putting it at the bottom
the-ssd submitted PR review.
the-ssd created PR review comment:
When https://github.com/rust-lang/compiler-builtins/pull/1053 is merged, feature
unstable-public-internalscan be removed, and this changed toLibm::<$float_ty>::roundeven
the-ssd updated PR #12222.
the-ssd updated PR #12222.
the-ssd updated PR #12222.
the-ssd commented on PR #12222:
I've removed OnceLock, but MachineEnv is now recomputed each time.
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:
- [x] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [x] separate PRs for: cranelift_assembler_x86 (#12235), moving large parts to core and alloc (#12237), and isle (#12236)
- [x] floating point issues
- [x] FxHashMap
- [ ] OnceLock
- [x] test for codegen compilation, with std, but without unwind
- [ ] libm: roundeven has a typo in it's implementation https://github.com/rust-lang/compiler-builtins/pull/1053, so a hack is used
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
usewithuse crate::prelude::*;\n useinstead of putting it at the bottom
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:
- [x] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [x] separate PRs for: cranelift_assembler_x86 (#12235), moving large parts to core and alloc (#12237), and isle (#12236)
- [x] floating point issues
- [x] FxHashMap
- [ ] OnceLock
- [x] CI
- [ ] libm: roundeven has a typo in it's implementation https://github.com/rust-lang/compiler-builtins/pull/1053, so a hack is used
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
usewithuse crate::prelude::*;\n useinstead of putting it at the bottom
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:
- [x] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [x] separate PRs for: cranelift_assembler_x86 (#12235), moving large parts to core and alloc (#12237), and isle (#12236)
- [x] floating point issues
- [x] FxHashMap
- [ ] OnceLock
- [x] CI
- [ ] libm: roundeven has a typo in it's implementation https://github.com/rust-lang/compiler-builtins/pull/1053, so a hack is used
the-ssd commented on PR #12222:
corefeature can be removed
the-ssd has marked PR #12222 as ready for review.
the-ssd requested abrown for a review on PR #12222.
the-ssd requested wasmtime-compiler-reviewers for a review on PR #12222.
the-ssd requested wasmtime-default-reviewers for a review on PR #12222.
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:
- [x] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [x] separate PRs for: cranelift_assembler_x86 (#12235), moving large parts to core and alloc (#12237), and isle (#12236)
- [x] floating point issues
- [x] FxHashMap
- [ ] OnceLock (sort of)
- [x] CI
- [ ] libm: roundeven has a typo in it's implementation https://github.com/rust-lang/compiler-builtins/pull/1053, so a hack is used
the-ssd updated PR #12222.
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?
the-ssd commented on PR #12222:
https://github.com/gimli-rs/gimli/pull/855
maybe evenunwindcan be supported on no_std.
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:
- [x] isle codegen generates code that depends on no_std, solved in the previous PR (https://github.com/bytecodealliance/wasmtime/pull/9007/files#diff-0496ab91e0634653bd3d4295c7aa90e3f06b0c5f462332db0997a22f294cbf94)
- [x] separate PRs for: cranelift_assembler_x86 (#12235), moving large parts to core and alloc (#12237), and isle (#12236)
- [x] floating point issues
- [x] FxHashMap
- [ ] OnceLock (sort of)
- [x] CI
- [ ] libm: roundeven has a typo in it's implementation https://github.com/rust-lang/compiler-builtins/pull/1053, so a hack is used, waiting for libm to be published to crates.io
the-ssd updated PR #12222.
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.
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 theextern crate allocin this crate might remove the need for these?
alexcrichton created PR review comment:
Given the name of this feature, this doesn't seem like something we should be relying on?
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_envchange? 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.
alexcrichton created PR review comment:
Mind backing out formatting-related changes in this file to make it easier to see what's actually changing?
the-ssd submitted PR review.
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
the-ssd submitted PR review.
the-ssd created PR review comment:
Oh, ok let me check
the-ssd submitted PR review.
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
alexcrichton submitted PR review.
alexcrichton created PR review comment:
While we're waiting for that to merge, could Cranelift be updated to avoid using the
Libmtrait? That would enable being able to land this and use it sooner
the-ssd updated PR #12222.
the-ssd updated PR #12222.
the-ssd updated PR #12222.
the-ssd updated PR #12222.
the-ssd updated PR #12222.
the-ssd updated PR #12222.
the-ssd submitted PR review.
the-ssd created PR review comment:
Unsure if this is correct
the-ssd submitted PR review.
the-ssd created PR review comment:
Done
the-ssd submitted PR review.
the-ssd created PR review comment:
Libmtrait 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-internalsis only needed for round_ties_even
the-ssd edited PR review comment.
the-ssd updated PR #12222.
the-ssd updated PR #12222.
the-ssd submitted PR review.
the-ssd created PR review comment:
reverted
the-ssd updated PR #12222.
the-ssd submitted PR review.
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