Charly Castes (Jul 03 2022 at 20:29): Charly Castes (Jul 03 2022 at 20:29):I have been experimenting with Cranelift on bare-metal environments, and as documented #![no_std] is not supported but unfortunately building a custom standard library doesn't work either (because of e.g. passes timing which require support for thread local storage and cause runtime failures if not supported).
However, it appears that the #[cfg(not(feature = "std"))] annotations are still present throughout Cranelift and that they disable the code requiring advanced std features. I successfully managed to run Cranelift on bare-metal by using both a custom std and the core feature without #![no_std].
The current state is not ideal, the core feature is still there but doesn't work. I was wondering if you would be open to replacing it with a restricted-std feature that would allow building Cranelift using a custom std, while not suffering from the limitations described here. The patch basically consists in renaming the feature, removing #![no-std] but keeping the #[cfg(not(feature = "std"))] already present.
For my use case (research) it's fine to maintain a fork, but I'd be happy to submit a PR if you're interested. I would also be able to help maintaining compatibility with restricted-std in case anything breaks in future versions.
(note that removing core would be a breaking change, but the feature doesn't compile anyway...)
Chris Fallin (Jul 04 2022 at 01:04):Hi @Charly Castes -- thanks for the interest in this!
In general Cranelift has aligned with Wasmtime's no_std policy which you linked, and I think the reasoning there would generally extend to any feature-flag variant that supports an alternative environment (restricted-std or otherwise).
From my point of view the main factor is cost and complexity, as seen by the developers: it's another thing we have to keep in mind when making changes, it's another configuration to learn how to locally build and debug when CI fails, it's more complexity in the code itself to keep in mind (a sort of faint shadow of "ifdef hell" from C/C++), etc. I'd also worry about how the requirements propagate downstream to our dependencies (regalloc2, wasmparser, ...). I'll also say that accepting "just a little feature/patch" can be a slippery slope, in my experience, in that it then creates expectations of "just a little more" and continued expansion of scope. It's often better to say "no" upfront, and even err a little bit on the side of too-limited, if one is resource-constrained (because maintenance of what we do have will always take more time than we expect).
If we had infinite developer time I think we'd be happy to take a "big tent" approach to all sorts of needs like this: more feature variants, more platform support, more compiler features of all sorts. But unfortunately we've been really squeezed thin, and time we spent on more niche needs like this (not to say it's not interesting!) carries an opportunity cost, in that we can't spend time on the many many TODO items we have in building a faster, more reliable, more secure compiler.
On that note we should probably rip out the last remaining bits of the historical no_std support; we just haven't gotten around to that yet... (see above re: stretched thin!).
Hopefully that clarifies things -- and best of luck with your project / research!
Charly Castes (Jul 04 2022 at 05:04):Thanks for the detailed answer!
I have read about Cranelift policy regarding #![no-std] in a few places and I understand the rationale, I still asked regarding support for custom std as it seems easier to maintain, but you're right that it's never zero cost.
Thanks for all the work that went into Cranelift by the way!
Last updated: Nov 22 2024 at 17:03 UTC