rucc_codegen/lib.rs
1//! Instruction selection, scheduling, block layout, frames and prologue emission.
2//!
3//! Design: `spec/10-backend.md`. Layer rank 11, see `spec/18-package-layout.md`.
4//!
5//! # Status
6//!
7//! The lowering tables are here. `rules/x86-64.rules` is compiled into a matching automaton when
8//! this crate is built, and [`select`] is the walk over it: hand it a term and it gives back the
9//! rule that fires and what the pattern bound. No lowering is written as `match` arms in this
10//! crate and none ever will be, which is the settled decision `spec/10-backend.md` section 10.2
11//! records.
12//!
13//! The selector is here too. [`lower`] walks a function and builds machine IR out of what the
14//! table gives back, and [`term`] is how an IR instruction is shown to the matcher. Between them
15//! they cover the arithmetic the rule file covers, which is every integer operation at every
16//! width the machine has one for.
17//!
18//! Loads and stores are covered too, and they are the first rules with an effect. What one of
19//! those claims is settled the same way everything else is: a term may compute a memory rather
20//! than a value, and the two halves of a rule have to agree about which they computed. A return
21//! is covered as well, and it is the first rule about the calling convention: what it claims is
22//! that the value comes through unchanged, and which register it comes through is a target fact
23//! [`rucc_target::x86_64`] states and a test there checks against both conventions.
24//!
25//! The branches are covered, and they are the rules with the least in them. Where a block goes is
26//! on the block in machine IR rather than on its terminator, so a rule for a branch never names a
27//! block and an unconditional jump is not a rule at all: the edge is the whole of it. What is
28//! left of a conditional branch is the condition, which is what its rule is about.
29//!
30//! [`split`] is what has to run between lowering and allocation now that there are branches. An
31//! edge that carries values into a block arrived at more than one way, out of a block that leaves
32//! more than one way, has nowhere to put the moves those values turn into, so it is split into two
33//! edges that do.
34//!
35//! [`abi`] is the other side of the same convention and the one part of it that is not a rule at
36//! all. Which register an argument arrives in depends on its position and on the classification
37//! of every argument before it, and a rule matches one term and can see none of that, so the
38//! arguments are built from what [`rucc_target::CallRegs`] says. A function's parameters are
39//! bound to the registers they arrived in before its first instruction is looked at, which is
40//! what makes a function that takes arguments one this can compile at all: the allocator refuses
41//! an entry block with parameters on it, because there is no edge into an entry block for the
42//! moves that give a block parameter its value to go on.
43//!
44//! The calls are built there too, and for the same reason: a rule pattern sees one term and a
45//! call's operands are whatever the signature made them. What the callee is free to destroy is
46//! written into the call as a definition of each of those registers, which is the whole of what
47//! the allocator needs to keep a value that outlives the call somewhere else. What passes on the
48//! stack is refused rather than passed wrongly, on this side as on the other.
49//!
50//! [`frame`] is what a function's stack looks like while it runs: which registers the prologue has
51//! to put back, where every spilled value went, and how many bytes the stack pointer moves. It is
52//! worked out after allocation because the largest area in most frames is the spill slots and
53//! nothing knows how many of those there are until the allocator has finished running out of
54//! registers.
55//!
56//! [`finish`] writes that frame into the function: the prologue that takes it, the moves the
57//! allocator handed back as edits, and the epilogue at the end of every block the function
58//! returns from. After it every register is physical and every offset into the frame is a
59//! constant, which is the point at which a function is one an encoder could read.
60//!
61//! [`layout`] runs last and is what makes a function something a machine could run rather than
62//! something a printer could print. It puts the blocks in the order they are laid out in and then
63//! writes the jumps that order needs, which is where a conditional branch finally becomes a test
64//! and a jump and where an edge to the next block becomes nothing at all.
65//!
66//! [`pipeline`] is the order all of that runs in, which is the only thing about the back end a
67//! caller outside this crate has to know and now the only thing it has to say. It is one function
68//! from an IR function to a machine one, and a [`pipeline::Machine`] describing what is being
69//! compiled for. The driver's `--emit=mir-final` is a call to it per definition in the module.
70//!
71//! What is not here yet is the optimizing path: no scheduling, no peepholes, and a block order
72//! from the shape of the control flow rather than from how often each block runs.
73//!
74//! Every crate in the workspace is published, and publishing implies a promise. This one is
75//! tier 3: its Rust API is explicitly unstable and will change without a major version bump.
76//! Depend on the `rucc` binary's behaviour, not on this.
77
78#![doc(html_root_url = "https://docs.rs/rucc-codegen/0.3.6")]
79
80pub mod abi;
81pub mod finish;
82pub mod frame;
83pub mod layout;
84pub mod lower;
85pub mod pipeline;
86pub mod select;
87pub mod split;
88pub mod term;
89
90/// The milestone in `spec/17-milestones.md` that fills this crate in.
91pub const MILESTONE: &str = "M3";
92
93#[cfg(test)]
94mod tests {
95 #[test]
96 fn milestone_is_recorded() {
97 assert!(super::MILESTONE.starts_with('M'));
98 }
99}