rucc_opt/rules.rs
1//! Matching the rewrite rules against the IR.
2//!
3//! Design: `spec/optimizer/13-rewrite-rules.md`. The rules themselves are in `rules/`, one file
4//! per tier, and the automaton they compile into is generated by `rucc-rules` when this crate is
5//! built. What each rule means is `crates/rucc-ir/rules/ir.model`, and `rucc-verify` makes every
6//! one of them prove itself against that model before it may be used.
7//!
8//! The walk over the automaton is [`rucc_base::rules`], which is where it is because
9//! `rucc-codegen` matches its lowering rules with the same walk and neither crate can see the
10//! other. What an IR instruction looks like to that walk is [`rucc_ir::term`], for the same
11//! reason: a rewrite rule and a lowering rule that spelled `add.i32` differently would be two
12//! vocabularies over one IR.
13//!
14//! The names are re-exported rather than reached for through `rucc_base`, because the generated
15//! file refers to them through `super` and that is the whole of the contract between the two.
16
17pub mod canonical;
18pub mod compare;
19pub mod identities;
20pub mod strength;
21pub mod width;
22
23pub use rucc_base::rules::{Guard, Match, Node, Piece, Rule, Subject, Table, Test};