Scaling Instruction-Selection Verification against Authoritative ISA Semantics

2.1 Cranelift’s Instruction Lowering and the ISLE Language

Cranelift handles the complexity of instruction selection with a custom domain-specific language, ISLE (Instruction Selection Lowering Expressions) [21]. ISLE programs replace hand-written instruction selectors, which are typically thousands of lines of unwieldy nested conditional code. ISLE expresses instruction lowering with term-rewriting rules that eventually map terms representing IR instructions to machine-instruction terms, often via a series of intermediate terms. ISLE’s meta-compiler translates ISLE terms and rules into Rust functions and optimized decision trees, which are integrated into the Cranelift compiler backend.

Rules consist of a left-hand-side pattern match describing when a rule applies, and a right-hand-side result expression. ISLE lowers IR terms to machine code through a series—or chain—of several rule applications via intermediate steps, visualized in Figure 1. Consider the initial rules for lowering iabs (an node), Cranelift’s integer absolute value instructions, to AArch64 machine code:

	1   (rule 1 (lower (has_type (fits_in_32 ty) (iabs x)))
	2     (abs (OperandSize.Size32) (put_in_reg_sext32 x)))
	3   (rule 2 (lower (has_type $I64 (iabs x)))
	4     (abs (OperandSize.Size64) x))
	

The lower outermost term is the entry-point to instruction lowering. Terms in the rule’s pattern (iabs, fits_in_32, ...) are extractors which conditionally match and bind additional values when successful. Extractors are often predicate terms (? nodes) that bridge to external Rust code to perform conditional pattern matching logic. The rules above match CLIF iabs instructions on bitwidths 32-bits-or-smaller, or exactly 64-bits, respectively. The integers 1 and 2 indicate the priority between the rules, i.e., the specific 64-bit case takes higher priority if it applies to a given CLIF subtree. In the narrow case, the input x is signextended to 64 bits. Both rules delegate to a helper, intermediate term abs (an node), which has its own rule:

	1   (rule (abs size rn) (with_flags (cmp_imm size rn (u8_into_imm12 0))
	2                                   (csneg (Cond.Gt) rn rn)))
	

This rule lowers the abs intermediate helper term into a comparison with zero (cmp_imm) followed by conditional negation (csneg). ISLE has a static type system that is used to enforce instruction lowering requirements, such as the constraint that an instruction that consumes flags must be directly after an instruction that produces flags. In this ISLE rule, this logic is encapsulated in the with_flags combinator, which expresses the transfer of implicit CPU flags between instructions.

Terms cmp_imm and csneg have one more level of rules to rewrite into Cranelift’s lowest-level representation of AArch64 machine-instructions called MInst ( nodes). For instance, for cmp_imm:

	1   (rule (cmp_imm size src1 src2)
	2     (ProducesFlags.ProducesFlagsSideEffect
	3       (MInst.AluRRImm12 (ALUOp.SubS) size (writable_zero_reg) src1 src2)))
	

This rule implements comparison to an immediate value using a subtraction that sets flags (SubS opcode), and discards its result (writable_zero_reg destination). The ProducesFlagsSideEffect wrapper communicates the flag-producing behavior of the instruction to the with_flags combinator. Similarly, the csneg rule lowers to an MInst. CSNeg instruction. These rules complete the lowering phase within ISLE, after which the final compilation stages operate on produced MInst instructions.

Thus, ISLE lowers iabs instructions from IR term to machine code via a chain of rule applications. Notably, intermediate terms such as abs are never materialized in the resulting MInst IR or the eventual AArch64 instructions—they only exist during compilation, as helpers that enable compiler engineers to abstract over common logic.

ISLE is strongly typed at the term level. Types representing the IR program being compiled (i.e., Inst, Value, and value types Type), and the machine instructions targeted (an MInst), are statically known and checked. However, ISLE rules are polymorphic with respect to the value types the input IR program might have (e.g., integer bitwidths).

2.2 ISLE’s Specification Features

Arrival adopts and extends specification annotations recently added to the ISLE core language [20, 21, 63]. Compiler engineers can specify term pre- and post-conditions with require and provide constraints, expressed in a syntax modeled on SMTLIB. For example, the integer addition IR term iadd has the following annotation, expressing that the term’s result (a dedicated keyword) is the bit-vector addition of its inputs:

	1  (spec (iadd x y) (provide (= result (bvadd x y))))
	

To scale to high coverage of production instruction selection, Arrival extends ISLE’s specification language and implements an entirely new verification backend. Arrival’s rule chaining technique (§3) saves developers from adding pre- and post-conditions to every intermediate term, and Arrival automatically generates specifications for the lowest-level machine code MInst terms, from vendor-provided semantics (§5). To ensure high coverage, Arrival’s extensions include support for stateful operations (§4) and floating-point. Arrival further extends ISLE’s specification language with ergonomic features (struct types, macros, and enum pattern matching) which make Arrival expressive and productive at the scale of Cranelift’s instruction selectors.

2.3 Arrival’s Architecture

Arrival is built on top of Cranelift/Wasmtime. Figure 2 shows Cranelift’s compilation phases, beginning with the CLIF intermediate representation produced by compiler front-ends such as Wasmtime and the Rust compiler. Cranelift’s mid-end optimizes CLIF code, before lowering to machine code in target-specific instruction selectors (AArch64, x86, ...). Cranelift’s instructionselection backends, and some mid-end optimizations, are implemented as programs of ISLE rules.

Fig. 2. Cranelift compilation phases.

Figure 3 shows how Arrival verifies ISLE instruction selection. Arrival’s verification operates on expansions, each of which represents the result of combining (chaining) multiple ISLE rules together (often, for multiple distinct sub-terms). Arrival derives all possible expansions from an ISLE program, starting from the ISLE meta-compiler’s low-level rule representation (called the trie). For each expansion, Arrival forms verification conditions (VCs) to express the semantic equivalence of the expansion’s input and output terms. At this point expansions are still polymorphic—they typically apply to multiple possible compile-time value types. A final type inference pass expands terms into all possible type instantiations (monomorphizations) of input-program types. Finally, concrete VCs for every expansion and type instantiation are lowered to SMTLIB and dispatched to a backend SMT solver.

Fig. 3. Arrival’s verification pipeline.

Arrival derives high-assurance instruction set semantics from vendor-provided specifications. Arrival’s ISA specification pipeline is independent from the verifier: the verifier consumes the resulting ISA specifications in ISLE syntax. Using Arrival’s Rust library, developers configure the ISLE machine instruction terms to generate specifications for the lowest-level machine code IR (MInst), including any symbolic parameters (e.g., not-yet-fixed immediate values or registers) that exist in the IR but not the final concrete instruction encoding. Arrival assembles each instruction configuration into symbolic instruction encodings, executes them according to the vendor specification to derive semantics, and finally compiles semantics into ISLE’s spec language.

2.4 Bug Discovery with Arrival

This section shows Arrival’s capabilities by walking through a subtle Cranelift bug uncovered by Arrival but missed by prior work. This discovery highlights Arrival’s advances in industrial-scale instruction-selection verification: reasoning over multiple rule applications with rule chaining, precise and automated ISA specifications, and lightweight state modeling.

	1  (rule (trap_if_div_overflow ty x y) (let (
	2      ;; Check if y is -1, set flags if so.
	3      (y_is_neg1 ... (MInst.AluRRImm12 (ALUOp.AddS) ... y (u8_into_imm12 1)))
	4      ;; Check if x is min_value, set flags if so.
	5      (x_is_min_val ...(MInst.CCmpImm (size_from_ty ty) x (u8_into_uimm5 1) (nzcv ...) (Cond.Eq)))
	6      ;; Consume flags from previous instructions and trap if both are set (i.e., on overflow)
	7      (trap_if ... (MInst.TrapIf (cond_br_cond (Cond.Vs)) (trap_int_overflow))))
	8      ;; Return the sequence of instructions above
	9      ...))
	

	1 (spec (sdiv x y) (modifies clif_trap)
	2   (provide ; Division by zero causes trap.
	3            (if (bv_is_zero! y) clif_trap
	4            ; Integer overflow causes trap.
	5            (if (and (= x (bv_s_int_min! (widthof x)))
	6                     (bv_is_zero! (bvnot y))) clif_trap
	7            ; Else, compute the result.
	8            (and (not clif_trap) (= result (bvsdiv x y)))))))
	

3.1 Expansions: Chained Rule Applications

To see what it means to chain rules together, consider the initial lowering of bitwise-and (band) on AArch64:

	1 (rule (lower (has_type (fits_in_64 ty) (band x y)))
	2       (alu_rs_imm_logic_commutative (ALUOp.And) ty x y))
	

This rule lowers a band instruction on 64-bit-or-smaller integers to an intermediate helper term, alu_rs_imm_logic_commutative. Other bitwise operators use the same helper; the helper has five rules of its own to further select the final machine code. One such rule optimizes the case where the right operand is a value shifted by a constant amount (ishl with iconst):

	1 (rule (alu_rs_imm_logic_commutative op ty x (ishl y (iconst k)))
	2       (if-let amt (lshl_from_imm64 ty k))
	3       (alu_rrr_shift op ty x y amt))
	

When this rule matches, it produces the term alu_rrr_shift representing an AArch64 shiftedregister instruction (which in turn has its own rules). To verify such a lowering, we could specify the behavior of the intermediate helper and confirm both rules are semantics preserving. Instead, we could compute the combined effect of both rules (as shown below), and verify the overall result.

	1 (rule (lower (has_type (fits_in_64 ty) (band x (ishl y (iconst k)))))
	2       (if-let amt (lshl_from_imm64 ty k))
	3       (alu_rrr_shift (ALUOp.And) ty x y amt))
	

We call this operation chaining rules together, resulting in an expansion. Note how the helper term is no longer present: its pattern match conditions (ishl, iconst, ...) and rule body have been inlined into the expansion. We can repeat this process for all five of the helper term’s rules, producing five possible expansions for the band lowering (during compilation, only one of the five expansions would apply to a given IR snippet based on which match predicates are true). We can also iterate on terms remaining in the expansion (e.g., the rules for alu_rrr_shift can also be chained), continuing until no more rules can be applied, or we otherwise choose to stop.

Note this operation presents a trade-off: when we apply rule chaining to a term, it no longer needs a specification (saving developer effort), but it creates a cross product in the number of total expansions to be processed (increasing verifier work). This trade-off is the core challenge of rule chaining, among others we’ll see in the next section.

3.2 Challenges of Rule Chaining

In this section, we discuss how Arrival addresses the practical challenges of applying rule chaining: (1) path explosion, (2) rule priorities, and (3) expansion representation.

Path Explosion. At first, one might consider applying rule chaining maximally, generating expansions for every possible path through an entire ISLE instruction selector. Unfortunately, this is impractical for industrial instruction selectors.

First, the major ISLE backends in Cranelift have a theoretically unbounded number of paths due to cyclic rewrite rules. For example, consider this lower_fmla rule in the AArch64 backend:

	1 (rule 5 (lower_fmla op (fneg x) y z size)
	2         (lower_fmla (neg_fmla op) x y z size))
	

This rule lowers a fused-multiply-add operation in a special case where one operand is negative, turning it into a fused-multiply-subtract (or vice versa). The rule could apply repeatedly to a nested series of fneg operators. Any fixed input program has finitely many negations, but from the instruction selector’s perspective, there is no natural bound on the number of times it could apply.

Second, even after discarding cyclic terms, the number of paths through the selector is enormous: unrestricted rule chaining would yield over 487 million possible rule combinations in the AArch64 backend alone (many of which have multiple type instantiations). There are two main causes for this blowup: widely-used terms that contain just a few rules and terms that are less widely used but have many distinct rules. For example, the operand_size term contains two rules and appears pervasively, while the with_flags_chained term contains 26 rules.

Critically, these “explosive terms” are not the common case: $94\mathrm{\%}$ of terms in the AArch64 backend have four or fewer rules. Cyclic terms are also infrequent. This is encouraging: rule chaining can be practical, if we can mitigate the explosive effect of a small number of outliers.

Arrival addresses path explosion by making rule chaining configurable per-term. If a developer provides a specification for a term, it will not be chained. To avoid unbounded recursion, cyclic terms are always excluded. Otherwise, developers enable chaining by annotating the term with a (veri chain) attribute (Arrival also identifies single-rule terms that are essentially trivial wrappers that can be chained by default). When verifying an expansion, if a term has neither a specification nor an annotation, the developer will be prompted to add one of the two. Explicit opt-in for rule chaining provides a more predictable developer experience. This configurability allows most terms to be chained (reducing specification burden) while excluding explosive terms.

The rule chaining algorithm accounts for this configurability. Arrival eagerly applies rule chaining until it finds terms that already have specifications. Completed expansions are handed to the verifier. Next, terms with specifications become a new origin point for rule chaining expansion. The effect of this approach is to break the instruction selector graph into components. Terms at the boundaries have specs and rule chaining automatically handles reasoning within components.

Rule Priorities. Rules in ISLE have priorities to break ties when rules have overlapping match conditions. Most often, developers use priorities for efficiency rather than correctness: the higherpriority case produces faster code, but both would be correct. There are, however, certain cases where a lower priority rule is only correct assuming that a higher-priority rule did not match. The operand_size rules are a concise example:

	1 (rule 1 (operand_size (fits_in_32 _)) (OperandSize.Size32))
	2 (rule 0 (operand_size (fits_in_64 _)) (OperandSize.Size64))
	

Here, the first rule with higher priority 1 handles the 32 -bit or smaller case. The second, lowerpriority rule is for the 64-bit case; its correctness relies on only matching the 64-bit type, which is guaranteed because the higher-priority rule did not match. While this style is not common in ISLE, it does appear in important cases like the lowering of integer-comparison operations.

Arrival can automatically reason about prioritized rules (unlike prior work [63]). Logically, accounting for priority means that when chaining a rule, we must assert the negation of higherpriority rules’ match conditions. The practical challenge is that expressing negated match conditions can significantly bloat verification conditions. Negated conditions from higher-priority rules bring additional variables into scope, potentially many when a rule is the lowest priority in a long list. To avoid unnecessary bloat when priority doesn’t matter for correctness, Arrival’s rule negation is opt-in through an a (veri priority) attribute. Without the attribute, Arrival effectively assumes a conservative over-approximation of ISLE semantics. If a developer omits the attribute where it’s required, Arrival will catch the resulting verification failure and present a counter-example.

Expansion Representation. Our rule chaining algorithm requires an efficient implementation for rule composition. For ease of exposition in §3.1, we showed the result of chaining two rules in ISLE rule syntax. This is an over-simplification: expansions resulting from rule chaining cannot always be represented in ISLE’s surface syntax. Instead, Arrival implements chaining on a lowerlevel representation of ISLE terms and rules. Arrival achieves this by building its expansion data structure upon the ISLE meta-compiler’s trie representation, which we describe in the next section.

3.3 The Rule Chaining Algorithm

This section outlines Arrival’s rule chaining algorithm. First, it describes the trie representation on which chaining operates; then, it describes chaining itself. Finally, it describes how Arrival prunes infeasible paths and accommodates rule priorities.

The trie representation. Arrival’s rule chaining pass consumes the ISLE meta-compiler’s trie intermediate representation, which the compiler produces after performing semantic analysis on the AST. While ISLE’s AST has syntactic sugar, the trie is distilled to minimal primitives. Chaining is efficient at this level of abstraction. The trie representation for a given term contains:

When the ISLE rules are compiled to the Rust instruction selector, terms become functions, bindings become variables, rules and their constraints describe a control-flow path through the function, and the result is the return value on that path.

Building Expansions by Rule Chaining. The rule chaining algorithm takes ISLE terms and rules, a designated root term (typically the lower entry point), and term attributes configuring which terms can be chained. The output is a list of all feasible expansions, each of which represents the result of applying some set of rules.

Rule chaining is a worklist algorithm. We begin with a single expansion that only contains a call to the root term. Given an expansion popped from the worklist, we look for any term calls. If Arrival finds a call to a term that’s eligible for chaining, Arrival forks the expansion once for each of the rules for the called term. In each fork, it will chain that rule into the expansion—that is, inline the rule’s body in place of the call and collect the rule’s constraints. Conceptually, each fork represents the effect of taking one possible control-flow path (a rule) through the called term. Forked expansions are pushed onto the worklist. When an expansion no longer has any term calls eligible for chaining, it is complete. The completed expansion is then checked for calls to terms that have specs: instead of forking, Arrival initiates a new rule chaining process rooted at that term.

Mechanically, the resulting expansion structure holds all the information Arrival needs to build the verification query for a given chain of rules. It contains a root term, a set of all the relevant bindings for rules included in the chain, all the constraints brought into scope by applied rules, and a result binding (i.e., the result when the entire chain of rules matches).

Pruning on feasibility. Some rules are statically incompatible with one another, and thus chaining a rule into an expansion may produce an expansion with constraints that are trivially unsatisfiable. Take for example the logic for the smul_overflow instruction, which utilizes the intermediate helper (lower_extend_op ty (ArgumentExtension. Sext)) to emit a signed extension (Sext). One of the rules for this helper matches on 8-bit unsigned extension (lower_extend_op $I8 (ArgumentExtension.Uext)), and an attempt to chain this rule into the prior call would trivially fail to match on the extension type (signed vs. unsigned). To reduce path exploration, Arrival tries to statically evaluate constraints during expansion and prunes unsatisfiable paths.

Accounting for priorities. When Arrival chains a rule into an expansion, it may need to account for priority. Arrival considers all overlapping higher-priority rules that are annotated with the ISLE priority attribute. Limiting to explicitly annotated rules prevents verification condition bloat. For each selected higher-priority rule rule, Arrival expresses the negation of the rule’s constraints in the expansion structure, importing bindings as necessary.

4.1 Modeling Effects on State

Arrival’s approach is to model effects, not complete state. Arrival takes advantage of the specifics of the instruction-selection domain to define a simpler model. While production instruction selectors are complex in the number of rewrites they define, each individual $m$-to- $n$ IR-to-ISA mapping tends to have limited effects on state. For instance, instruction lowerings that interact with memory typically only involve one load or store. Similarly, a lowering either traps once or it does not. We find it is sufficient to capture these effects as global specification variables. To describe a possible load we do not need an entire representation of memory. Instead we can capture the load parameters on both IR and ISA—its address and size—as state variables, and verify that both sides have the same effect. Likewise, we can model the presence of a trap on each side with two boolean state variables. Since IR and ISA behaviors are diverse, developers use Arrival to define custom effect variables.

Given variables for possible state effects (loads, stores, traps, ...), Arrival enables developers to specify (1) how terms modify effect variables, and (2) relations that must hold between effect variables after lowering. When a term has a state effect—for example a CLIF load or an AArch64 ULoad32—the specs for those terms declare that they modify the corresponding effect variable and provide post-conditions that specify the effect’s parameters. State relations that must be true of any lowering, such as that both sides perform the same load, are expressed as post-conditions on the top-level lower entry point.

Since any term in an expansion can modify state variables, we also have to consider the cases where either zero or more than one term modifies a state variable. The zero case is common: for example, most instructions do not load from memory. Arrival handles this by allowing developers to specify a default value for an effect—for example, expressing that a load did not happen. More than one modification is an important case, though less common. For example, some lowerings (e.g., sdiv) can trap in more than one way (e.g., division by zero and overflow). Arrival handles this with conditional modification in the specs, which expresses the case where only one of multiple possible state modifications occurs (e.g., only one of the possible traps will actually happen).

4.2 Specification Language Support for State Effects

We extend the ISLE specification language with support for state effects.

Effect Variables. Developers declare a named state effect variable, with its type and default specification, as follows:

	1 (state <name> (type <type>) (default <default>))
	

This declaration introduces a global variable name of the given type. This variable will be present in the verification conditions for any expansion, including those where no term modifies the variable (in which case the default clause provides a spec for the effect variable’s value).

For example, consider the declaration:

	1  (state clif_trap (type Bool) (default (not clif_trap)))
	

It creates a state variable to model whether the input IR sequence traps in CLIF semantics. The default (not clif_trap) applies when none of the terms in an expansion modify clif_trap.

Specifying Term Effects. To describe a term’s effect on state, developers use modifies clause in the spec:

	1 (spec (<term> <args...>) (modifies <state> <cond>?) ...)
	

The modifies clause declares that the associated term modifies state. If the modification is conditional, the clause should also include a condition variable cond. When a spec declares it modifies a given state effect, the spec body must provide constraints that define when cond holds and the implied constraints on state when it does.

When verifying an expansion, the modifies clauses and their condition variables determine when the default spec for a state effect applies. That is, Arrival collects all modifies clauses for a given state and assumes the default spec when all conditional variables are false.

4.3 Case Study: CLIF-to-AArch64 State Modeling

Next, we walk through an example of Arrival’s state modeling for CLIF to AArch64 lowering.

Loads. In Arrival’s approach, we do not model all of memory. Instead, we model the parameters of a possible load effect by a CLIF instruction with a state variable.

	1 (state clif_load
	2     (type (struct (active Bool)
	3           (size_bits Int)
	4           (addr (bv 64))))
	5     (default (not (:active clif_load))))
	

The state variable expresses the fact that a load may or may not happen (via the active flag) and its size and address when it does. The default case is an inactive load. We define a parallel state variable isa_load for a possible load operation on the ISA side of the lowering. We also define a bit-vector loaded_value state variable for the symbolic value produced by a load.

	1  (state loaded_value (type (bv 64)) (default true))
	

The specification of the CLIF load instruction indicates that it modifies the clif_load effect and how the load parameters relate to instruction parameters. In addition, the result of load is the loaded_value state variable, truncated to the load size. This symbolic state variable enables Arrival to correctly find errors where, for example, the IR specifies that a loaded value should be sign-extended but the ISA performs a zero-extend.

	1 (spec (load flags p offset)
	2     (modifies clif_load) (modifies loaded_value)
	3      (provide
	4         ; Activate the CLIF load effect
	5         (:active clif_load)
	6         ; Load size is the width of the loaded value.
	7         (= (:size_bits clif_load) (widthof result))
	8         ; Address calculation.
	9         (= (:addr clif_load) (bvadd p (sign_ext 64 offset)))
	10        ; Result of the load is represented by low bits of the loaded value state register.
	11        (= result (conv_to (widthof result) loaded_value))
	12   )
	13 )
	

Likewise, Arrival’s ISA specification pipeline (§5) automatically detects when instructions access memory and modifies the isa_load effect accordingly within the generated spec. The result register of the load instruction is also set equal to the loaded_value state variable.

Finally, at the top-level, we must ensure that lowerings from CLIF to ISA preserve load semantics. We do so with a specification on the top-level lower entry point (§2):

	1 (spec (lower arg)
	2       (provide
	3         ; Either both active, or both not.
	4         (= (:active clif_load) (:active isa_load))
	5         ; If active, their parameters must match.
	6         (=> (:active clif_load) (= clif_load isa_load))
	7         ; ...
	

This specification states that clif_load and the isa_load must both be inactive or both active, and, if both are active, their parameters must be equivalent.

Traps. To describe trapping behavior, we introduce variables for whether CLIF semantics require a trap, and whether one happens in execution.

	1 (state clif_trap (type Bool) (default (not clif_trap))
	2 (state exec_trap (type Bool) (default (not exec_trap))))
	

These effect variables are boolean flags—either they fire or they don't—and they default to not firing. The top-level lower specification asserts that for any possible lowering, clif_traps if and only if exec_traps.

CLIF instruction specifications describe trap semantics by specifying when clif_trap is true, as we saw for sdiv (§2.4.2). Likewise, the specification for Cranelift’s TrapIf pseudo-instruction defines the conditions under which it triggers a trap.

	1 (spec (MInst.TrapIf kind trap_code)
	2   (modifies exec_trap this_inst_traps)
	3   (provide
	4     ; Conditions under which this instruction traps.
	5     (= this_inst_traps (match kind
	6         ((Zero r) (bv_is_zero! r))
	7         ((Cond cc) (cond_holds! cc (:flags_in result))) ...))
	8     ; If this instruction traps, set the global trap state.
	9     (=> this_inst_traps exec_trap)))
	

Crucially, the use of the condition variable this_inst_traps allows lowerings to instruction sequences that can potentially trap in multiple ways.

Flags. Lastly, we note that while we could use Arrival’s state modeling for AArch64 flags, it is natural to build on ISLE’s existing conventions for flags handling. Cranelift uses a with_flags combinator to wrap instruction sequences that pass flags between them, ensuring they are kept consecutive when machine code is emitted. Given a producer and consumer instruction, ISLE rules construct a (with_flags producer consumer) term when flags must be passed from one to the next. This affords an elegant way to specify the transfer of flags between instructions.

We specify that the representation of machine instructions during verification have input and output flags (AArch64’s NZCV flag bits):

	1 (model MInst (type (struct (flags_in (named NZCV))
	2                            (flags_out (named NZCV)))))
	

Given this, the specification of the with_flags term asserts that the flags_out of the producer equals the flags_in of the consumer.

Full State. The complete set of state variables defined for Arrival’s current AArch64 verification scope are:

5.1 Overview of Arrival’s Approach: Semantics from Symbolic Instruction Encodings

We illustrate Arrival’s approach with a running example throughout the section. The AluRRImm12 instruction family represents arithmetic on a register and a constant expressed in AArch64’s Imm12 immediate format. Cranelift’s machine code IR represents the AluRRImm12 family in ISLE as:

1 (AluRRImm12 (alu_op ALUOp) (size OperandSize) (rd WritableReg) (rn Reg) (imm12 Imm12))

Note the type of the last parameter, Imm12, is itself a structured type with two fields: a 12-bit bits constant and a flag shift12 that indicates whether to shift bits by 12 before the operation.

Considered as an ISLE term, our desired specification for AluRRImm12 would treat its inputs as symbolic variables: rn represents the value contained in the input register, and imm12 is the value of the instruction immediate. The specification should describe how the instruction performs an arithmetic operation based on these symbolic inputs.

However, vendor specifications capture the semantics of concrete instruction encodings. Overall, AluRRImm12 represents a massive family of encodings: four possible arithmetic operations, two possible operand sizes, 32 possible output registers, 32 possible input registers, two possible immediate shift flags, and 4,096 possible immediate bits. In total: 67,108,864 concrete instruction encodings! Generating semantics for all of them is out of the question (let alone feeding those results to an off-the-shelf SMT solver).

Arrival’s approach bridges the gap between symbolic values and instruction encodings, enabling all 67,108,864 encodings to be reduced to a tractable state space. At a high level, the approach partitions the entire AluRRImm12 family into subsets, each represented by an encoding template (an instruction encoding with symbolic bit ranges), and computes succinct semantics for each one.

Arrival builds upon recent work by the ASLp project [2, 39], which showed how to reduce the verbosity of Arm’s specifications via partial evaluation. Their tooling maps a fully concrete 32-bit encoded instruction to a (usually) short program describing that instruction’s behavior. For example, given the concrete instruction 0x91048ca4, ASLp produces a "reduced ASL" program that roughly says:

1 R[4]= add_bits{{64}}(R[5], 291);

This corresponds to the assembly code: add ×4,×5, #291, i.e., adding the immediate constant value 291 to the value of register ×5 and storing the result in register ×4.

To derive semantics for instruction encoding templates, we built SymASLp, a fork of ASLp extended to support partial evaluation on symbolic instruction encodings. For example, SymASLp can derive semantics for the set of instructions add x4, x5, #< bits >, with encoding template 1 |0010001|0|bits|00101|00100. The template describes: 64-bit size (1), add opcode (0010001), an immediate that is not shifted (0) with a value given by a 12-bit variable (bits), and register indices (00101 and 00100). Given this template, SymASLp produces a short semantics program (Figure 4) for all 2¹² instruction encodings in the template, in terms of the bits variable. With templates like this, SymASLp can derive concise semantics for entire subsets of the AluRRImm12 family at once.

Fig. 4. Arrival’s specification generation pipeline for AluRRImm12 instructions. (a) Developer-provided configuration determines how to parameterize the instruction family. (b) Arrival produces encoding templates using the Cranelift assembler, one for each possible value of the enumerated fields (alu_op, size and imm12.shift12), and splices in the symbolic bit range bits. (c) SymASLp generates semantics for each encoding template. (d) Arrival translates each semantics block into one case of the full ISLE specification.

Using SymASLp, Arrival’s pipeline generates the AluRRImm12 specification as illustrated in Figure 4 and described below (with further details in §5.2):

Finally, Arrival validates that the instruction encoding templates are consistent with the Cranelift assembler (§5.2.3). That is, Arrival provides assurance that the 16 cases we defined for AluRRImm12 are identical to the encodings the assembler produces.

5.2 Details of Arrival’s ISA-Specification Generation Pipeline

Arrival takes as input authoritative, vendor-validated ISA specifications written in ASL. Developers use Arrival’s Rust library to configure instruction families (§5.2.1). Arrival automatically generates ISLE specifications for each configured machine instruction (§5.2.2). The results are succinct enough to be human-readable and checked into the Arrival codebase, decoupling specifications from the pipeline and its dependencies. Arrival also automatically validates the configured instruction encodings against those produced by Cranelift’s internal assembler (§5.2.3). This moves more of Cranelift’s code (e.g., much of its assembler) out of our trusted computing base.

6.1 What Verification Coverage Can Arrival Achieve?

We use Arrival to verify Cranelift instruction lowerings for CLIF instructions emitted by Wasmtime’s Wasm compiler. We focus on Wasm’s core instruction set [1], where verification is required to provide assurance of its sandboxing security guarantees. Our work verifies, with minor exceptions: all integer numerics, (non-atomic) memory loads/stores, floating-point numerics, and conversions.

We verify Cranelift’s AArch64 backend, because it is actively-maintained, widely-used, and benefits from Arm’s machine-readable semantics. RISC-V has a formal specification in Sail [4], but RISC-V is less widely used and a Tier 3 target [66]. Intel’s promised machine-readable specification [55] is not yet available; applying it to Cranelift would be exciting future work.

Arrival supports tagging ISLE rules and terms by their categories, which we use to select subsets of expansions for verification. Tags include categories like wasm_proposal_mvp for Wasm 1.0 core functionality—the Minimum Viable Product (MVP) release—and float for floating-point numerics and conversions to/from integers.

Our verification scope encompasses 6,212 total expansions (distinct chains of rules). As Arrival’s type inference and applicability checks process these expansions, some are deemed impossible due to type or pattern-matching predicate conflicts. Others have multiple possible applicable type instantiations (i.e., the same rule chain could apply to both 32 - and 64 - bit inputs). As a result, a total of 10,834 type instantiations are deemed applicable and proceed to verification.

We measure performance on a desktop workstation with Intel i7-13700K processor with 8 performance-cores and 8 efficiency-cores, totaling 24 threads with hyper-threading.

Table 1 shows the full break-down of expansion verification results by category. Across all expansions, 10,807 are verified, while 27(0.2%) time out with a solver timeout of 4 hours. The overwhelming majority of queries complete in a matter of a few seconds (§6.3). We use two backend SMT solvers (cvc5 [8] and Z3 [23]) and enable developers to select a default and configure an override by applying tags. We found the best performance with cvc5 for most expansions and Z3 for certain floating-point and bitwise operator terms ( 38 expansions). Expansions that timeout are: some divisions and remainders, and population count. Such cases have always been a challenge for the underlying SMT solvers [27, 31, 43]. We do find that although proving UNSAT in these cases is difficult, our anecdotal experience shows that Arrival can quickly provide counter-examples when bugs are purposefully introduced.

Our verification coverage has limited caveats:

Arrival also covers some Cranelift extensions to Wasm, for example 8- and 16-bit integer operations (revealing the sdiv bug). Further work could expand our coverage to all of Wasm core (e.g., stack and control flow), and go beyond Wasm 1.0 (e.g., SIMD).

Comparison to Prior Work. In both breadth and depth of coverage, Arrival goes beyond prior efforts to verify Cranelift’s instruction selector [63]. Arrival (1) verifies memory and floating-point lowerings; (2) achieves deeper end-to-end coverage of the same lowerings, down to machine code IR; (3) verifies more behaviors (e.g., trap semantics); and (4) uncovers previously missed bugs (§2.4.1). Arrival’s rule chaining makes direct comparisons difficult, but to convey a sense of scale: Arrival covers 3.3× more rules and 29.2× more type instantiations.

6.2 Does Arrival Reduce Specification Burden?

We evaluate specification burden by considering the specs required to verify the large subset of the WebAssembly-critical backend described in §6.1. We consider how many specs were required, how many of those were provided with the assistance of Arrival’s automation, and how much manual effort it saved. Overall, we find that of the 410 term specs required, 60% benefit from some form of Arrival’s automation, including almost all of the most complex ISA specs. Indeed, of the 266 terms where automation was feasible, we automated 93%.

Table 2 shows how specs benefit from automation, broken down by the major categories below.

ISA. Arrival’s ISA specification pipeline (§5) automatically derives the vast majority of instruction family specifications. ISLE’s machine instruction IR groups many instructions into a small set of top-level terms. For example, 19 distinct arithmetic instructions use AluRRR (which is then further specialized based on operand size). In total, the generated specifications cover 559 encoding templates across 39 ISLE terms, leading to 12,608 lines of ISLE specification language. The configuration required to parameterize all instruction families is 1.9 K lines (6.5× less than the generated specifications). This code is largely boilerplate, and the ISA specification pipeline provides guard-rails to detect mistakes (§5.2.3). Future work could express this configuration in a more concise DSL.

Three specific ISA terms still require hand-written specifications. Two immediate encoding cases—AluRRImmLogic and AluRRImmShift—present substantial challenges for the ISA specification pipeline. Both cases use an unusually complex part of the ASL specification for the encoding of logical immediates in AArch64 [25]. While it might have been possible to proceed with codegeneration, we opted for simpler hand-written specifications instead. The other exception to automation here are pseudo-instructions, e.g., TrapIf (mentioned in §4). Pseudo-instructions do not directly correspond to AArch64 instructions and have tight integration with the Cranelift engine; therefore specifications cannot be derived purely from vendor-provided semantics.

Internal. Internal terms are defined within ISLE itself: mostly intermediate terms used to express instruction selection logic, or terms introduced by ISLE type definitions (e.g., enum variants). Arrival’s automation means that very few internal terms require manual specification. With rule chaining, most intermediate terms (116) are automatically inlined (§3); therefore developers do not have to provide specifications. In addition, Arrival synthesizes specifications for most ISLE-defined types (95 terms), allowing authors to reason about them without additional specification effort.

Cranelift IR. Since Cranelift IR has no formal semantics, we wrote our own. Where possible, we used line-by-line transcriptions of the WebAssembly specification associated with the IR term, or specifications already added to ISLE in prior work [63]. In other cases, we relied on inspection of the implementation and discussions with developers. In the long run, we expect that semantics for a large subset of CLIF could be automatically derived from Wasm’s semantics once the migration to SpecTec [68] is complete, with human input for the non-one-to-one operators.

External. External terms are bridges to external Rust functions, mostly for pattern-matching predicate logic. Their behavior must be specified by hand for Arrival to reason about them. External specifications are trusted, as well as some trusted helpers (e.g., the with_flags combinator).

Comparison to Prior Work. The Crocus verifier [63] would have required hand-written specifications for all 410 terms, or 2.6× more than Arrival. The initial Crocus verification effort required 136 annotations [63, §4.1]. At the cost of 24 more hand-written specifications Arrival achieved far broader coverage (§6.1).

6.3 Is Arrival Performant Enough to be Incorporated into Developer Workflows?

In this section, we evaluate whether Arrival’s performance is sufficient to meet our usability goals. Can it produce results fast enough to be used in Cranelift development, both in CI and in local iteration on instruction-selection rules?

We envision that continuous-integration might execute full-coverage verification runs on a schedule (e.g., nightly or weekly). In this context, developers are not blocked on feedback, so execution times of up to a few hours could be acceptable. In addition, runs should be possible on commodity hardware readily available from cloud providers. Arrival is multi-threaded and will parallelize expansions over available cores. For high-assurance, some verification runs should use large solver timeouts to maximize coverage. In this case, the overall time is dictated by the selected timeout. There is also value in more frequent lower-timeout runs that bring most of the value with far less compute resources. With a solver timeout of 60 seconds and using cvc 5 only, the verification run in §6.1 takes 10.06 minutes to complete. This run achieves almost the same total coverage, with 55 expansions timing out instead of 27. While a 16 -core machine is powerful, it could be a reasonable expense for a job lasting a few minutes once a day. With Arrival’s parallelization, the job could scale down to smaller hardware and still take an acceptable amount of time in CI. With this performance, it could also be possible to run verification for a selected subset of rules on pull-requests affecting ISLE files.

For local iteration, developers seek faster feedback, typically on a laptop rather than server-class hardware. In this context, limited runs over in-development rules are more common, and developers will typically benefit from the fact that the common-case verification time for a single type instantiation is a few seconds. Figure 5 shows the distribution of type instantiation verification times across the full verification run, showing that the vast majority complete in 5 seconds or less. For a developer utilizing Arrival’s filtering mechanisms to narrow down to an in-development rule, each run will hit a modest number of type instantiations and produce feedback in seconds or minutes.

Fig. 5. Cumulative distribution function (CDF) of verification times for type instantiations in the full verification run from §6.1.