Skip to main content

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//! The addresses are the other thing [`lower`] builds by name rather than by rule, and there are
51//! two of them. The address of a local is a `lea` off the stack pointer with a displacement the
52//! frame fills in later, and the address of a name at file scope is a `lea` off the instruction
53//! pointer with the name on it. Neither is a rule because neither is a claim about bitvectors: one
54//! of them is waiting on a number nothing knows yet and the other is right because of what the
55//! linker does with a relocation. A cast between a pointer and an integer as wide as one is here
56//! for the opposite reason, which is that it is no instruction at all.
57//!
58//! [`frame`] is what a function's stack looks like while it runs: which registers the prologue has
59//! to put back, where every spilled value went, and how many bytes the stack pointer moves. It is
60//! worked out after allocation because the largest area in most frames is the spill slots and
61//! nothing knows how many of those there are until the allocator has finished running out of
62//! registers.
63//!
64//! [`finish`] writes that frame into the function: the prologue that takes it, the moves the
65//! allocator handed back as edits, and the epilogue at the end of every block the function
66//! returns from. After it every register is physical and every offset into the frame is a
67//! constant, which is the point at which a function is one an encoder could read.
68//!
69//! [`layout`] runs last and is what makes a function something a machine could run rather than
70//! something a printer could print. It puts the blocks in the order they are laid out in and then
71//! writes the jumps that order needs, which is where a conditional branch finally becomes a test
72//! and a jump and where an edge to the next block becomes nothing at all.
73//!
74//! [`pipeline`] is the order all of that runs in, which is the only thing about the back end a
75//! caller outside this crate has to know and now the only thing it has to say. It is one function
76//! from an IR function to a machine one, and a [`pipeline::Machine`] describing what is being
77//! compiled for. The driver's `--emit=mir-final` is a call to it per definition in the module.
78//!
79//! [`coverage`] is what says whether all of that adds up to a back end. Every IR opcode is lowered
80//! by a rule, or somewhere a rule cannot reach and the reason is written down, or nowhere and the
81//! issue that closes it is written down. Which of the three each one is is checked rather than
82//! believed, and the count of the third is one of the numbers `spec/15-testing.md` says we keep
83//! about ourselves. It is not zero yet.
84//!
85//! The other coverage question is the one only a corpus can answer, which is which of the rules
86//! that are written anything ever fires. [`coverage::Fired`] is what records that as the selector
87//! goes, and `-Zrule-coverage=FILE` is how a run of the compiler is asked for it.
88//!
89//! What is not here yet is the optimizing path: no scheduling, no peepholes, and a block order
90//! from the shape of the control flow rather than from how often each block runs.
91//!
92//! Every crate in the workspace is published, and publishing implies a promise. This one is
93//! tier 3: its Rust API is explicitly unstable and will change without a major version bump.
94//! Depend on the `rucc` binary's behaviour, not on this.
95
96#![doc(html_root_url = "https://docs.rs/rucc-codegen/0.4.1")]
97
98pub mod abi;
99pub mod coverage;
100pub mod expand;
101pub mod finish;
102pub mod frame;
103pub mod layout;
104pub mod lower;
105pub mod pipeline;
106pub mod select;
107pub mod split;
108pub mod term;
109pub mod varargs;
110
111/// The milestone in `spec/17-milestones.md` that fills this crate in.
112pub const MILESTONE: &str = "M3";
113
114#[cfg(test)]
115mod tests {
116    #[test]
117    fn milestone_is_recorded() {
118        assert!(super::MILESTONE.starts_with('M'));
119    }
120}