Module machine 

What a pass knows about the machine it is compiling for.

Design: section 40.12 of spec/optimizer/40-cost-models.md, which writes down the interface a pass asks a target through, and tamnd/rucc#655, which is the observation that no pass could reach it. The cost tables have existed since the crate did and nothing outside rucc-cost ever called for_arch, because a pass is handed a function and a function does not know what it is being compiled for.

Why it sits on the analysis cache

crate::Analyses is the one thing every pass is already handed besides the function and the fuel, so putting the machine there is what makes it reachable without a fourth argument on every run. The cache is per function and so is the machine’s lifetime as far as a pass is concerned, and the pipeline builds one for the module and hands out copies.

It is a copy rather than a borrow because it is two words, a pointer to a table nobody writes and the goal. A pass that wants both the machine and an analysis out of the same cache would otherwise be holding two borrows of it, one of them mutable, which is a fight with the borrow checker over a value cheaper to copy than to reference.

A target with no back end

rucc_cost::for_arch answers None for AArch64 and RISC-V, because neither has a back end and neither has a cost table, and a default table would be numbers nobody chose that every pass would believe. So Machine::costs is an Option and a pass that needs a number has to say what it does without one. What it should do is nothing, and say so as a missed remark: an optimization that guessed at the cost model would be a pass tuned for a machine that is not the one being compiled for.

Structs

Machine

The target a pass is compiling for, and which of its two cost tables applies.