bc0de464bc
In [this comment](https://github.com/bytecodealliance/wasmtime/pull/3545#discussion_r756284757) I noted a potential subtle issue with the way that a few rules were written that is fine now but could cause some unexpected pain when we get around to verification. Specifically, a set of rules of the form ``` (rule (A (B _)) (C)) (rule (A _) (D)) ``` should, under any reasonable "default" rule ordering scheme, fire the more specific rule `(A (B _))` when applicable, in preference to the second "fallback" rule. However, for future verification-specific applications of ISLE, we want to ensure the property that a rule's meaning/validity is not dependent on being overridden by more specific rules. In other words, if a rule specifies a rewrite, that rewrite should always be correct; and choosing a more specific rule can give a *better* compilation (better generated code) but should not be necessary for correctness. This is an admittedly under-documented part of the language, though in the pending #3560 I added a note about rule ordering being a heuristic that should hopefully make this slightly clearer. Ultimately I want to have tests that choose non-default rule orderings and differentially fuzz in order to be sure that we're following this principle; and of course once we're actually doing verification, we'll catch issues like this upfront. Apologies for the subtle footgun here and hopefully the reasoning is clear enough :-)
This crate contains the core Cranelift code generator. It translates code from an intermediate representation into executable machine code.