cranelift-codegen: no_std support

[marceline-cramer]

trafficstars

Closes #1158, previous context and discussion can be found there. This is a major milestone towards allowing Cranelift to compile code while in embedded or kernel environments.

I do still have a handful of pinch points to work through before this is ready to merge.

First of all, the most major overhaul I've made to the codegen crate is to replace rustc-hash with hashbrown and ahash. I'm not a cryptography expert but as far as I can tell, ahash does have a security improvement over FxHash in terms of improved DOS resistance. More importantly though, hashbrown has a feature to use ahash by default, which means that replacing FxHashMap and FxHashSet was as easy as a few invocations of sed. However, I believe that this switch in hashing function has caused some of the codegen expected output tests in CI to fail, and the semantics of the codegen have been slightly changed. I could experiment with swapping rustc-hash back into hashbrown as its hasher implementation locally but I wanted to know if preserving these semantics was important before I undertook another major type substitution throughout the code. Please take a look at the output of the failing CI for more info.

Second of all, on no_std, floating-point arithmetic is not available. To resolve this, I brought in the core_math crate, which implements floating-point arithmetic traits for core primitives using libm's implementation of softfloat. However, the function rounding_ties_even() is not available in libm, and I'm not sure how to go about replacing it. Input would be appreciated. I do know that if the failing codegen output unit tests I discussed are updated to pass with the new output, other tests catch the change in arithmetic semantics and fail.

Finally, there's this else block in src/machinst/vcode.rs that has some arithmetic with a hard dependency on the unwind feature, which is unsupported on no_std. I'm not sure what to do with that.

Thank you so much for the help with all of this, I appreciate your time immensely. I'm really happy to answer any questions and update my code as needed.

[github-actions[bot]]

Subscribe to Label Action

cc @cfallin, @fitzgen

This issue or pull request has been labeled: "cranelift", "cranelift:area:aarch64", "isle"

Thus the following users have been cc'd because of the following labels:

• cfallin: isle
• fitzgen: isle

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[bjorn3]

rustc-hash is no_std compatible. You just need to disable the std feature.

[tschneidereit]

@marceline-cramer is there anything we can to do help you get the review comments addressed? Getting this in would be excellent, and you've already put in the major part of the work, after all :)

[marceline-cramer]

@marceline-cramer is there anything we can to do help you get the review comments addressed? Getting this in would be excellent, and you've already put in the major part of the work, after all :)

Apologies for putting this off for so long. I've been capital-B Busy the last couple months. I'll try to provide an answer to that question over the weekend when I can refresh my memory on what precisely is happening here and process the comments.

[tschneidereit]

@marceline-cramer no worries at all—life happens to all of us! I really meant the question in the way I worded it: as an offer to help get things unblocked :)

[DrewRidley]

Is there any update on this PR? I am very interested in using Cranelift in a no-std environment. Happy to help address the concerns or get this PR up to date if needed.

[cfallin]

@DrewRidley I'm not sure about this PR in particular but one of the sticking points here was the OnceCell usage, which has another pending PR to refactor away in #9992. That one seems to have stalled as well (waiting for updates from the author) but if you want to contribute efforts, you might be able to help move that forward.