Skip to main content

rucc_target/
branch.rs

1//! The instructions a laid out branch is made of.
2//!
3//! Design: `spec/10-backend.md` sections 10.6 and 10.8.
4//!
5//! A lowering rule for a conditional branch says one thing, which is what the branch is on. Where
6//! its two arms go is on the block rather than in the instruction, and which of them the block
7//! falls through to is not knowable until every block of the function has been put in an order.
8//! So the instructions that actually branch are chosen by the block layout, after allocation, and
9//! they are named here for the same reason [`crate::FrameInsts`] names a push: the crate that
10//! writes them is a pipeline crate and `spec/10-backend.md` section 10.8 says a pipeline crate
11//! holds no target-specific code.
12//!
13//! # What each one has to be
14//!
15//! The shapes are fixed, because the code that writes them writes one shape each. The test reads
16//! one register and sets whatever the machine's condition state is. The three jumps read nothing
17//! and write nothing, and where each goes is the first successor of the block it ends, which is
18//! how every other arm is already carried.
19//!
20//! Two conditional jumps rather than one, because which one a block ends with depends on which
21//! arm the layout put next. A block that falls into the arm taken when the condition does not
22//! hold ends with the jump that is taken when it does, and a block that falls into the other arm
23//! ends with the other jump. Neither is more natural than the other and a target that could only
24//! name one would force the layout to lay every second branch out backwards.
25//!
26//! After the layout has run, a block that ends in a conditional jump has exactly two successors:
27//! the first is where the jump goes, and the second is the block laid out next, which is where it
28//! goes when the jump is not taken. There is never a second jump in the same block, because the
29//! layout makes a block for one rather than writing it.
30//!
31//! # The condition state is not an operand
32//!
33//! Nothing here mentions the flags, on a machine that has them or on one that does not. What
34//! makes that sound is that the test and the jump that reads it are written next to each other,
35//! by one pass, after the allocator has finished, so there is nothing left in the compiler that
36//! could put an instruction between them.
37//!
38//! # The test a comparison makes unnecessary
39//!
40//! Almost every branch in a C program is on a comparison, and a comparison already sets the
41//! condition state. The byte a rule selects for it, the test of that byte against itself and the
42//! jump on the answer are three instructions where the machine wanted two, and the two it wanted
43//! are the comparison with nothing kept and a jump on the condition the comparison was asked
44//! about.
45//!
46//! [`Fusion`] is that pair written down, one entry per comparison a rule can select. The layout
47//! looks for one when the instruction in front of the branch is a comparison whose byte the
48//! branch is the whole of what reads, and writes the two instructions in the entry instead of the
49//! three it found. Which of the two jumps it writes is the same question as before and gets the
50//! same answer, so an entry names both.
51//!
52//! It stays a table rather than becoming an operation on the names. `cmp_set_ae_ri_64` and
53//! `cmp_ri_64` and `jcc_ae` are strings a target chose and not a spelling anything here may
54//! derive, and a target whose comparisons are shaped differently, or which has no condition state
55//! at all, writes a shorter table or an empty one.
56
57/// Every instruction a laid out branch is made of.
58#[derive(Debug, Clone, Copy, PartialEq, Eq)]
59pub struct BranchInsts {
60    /// What a rule file and the machine IR put in front of this target's opcodes, such as `x64.`,
61    /// which says which target a term belongs to and is not part of the opcode.
62    pub prefix: &'static str,
63    /// What a lowering rule selects for a conditional branch, which is what the layout replaces.
64    ///
65    /// It reads the condition and does nothing, which is as much of a branch as a rule can say.
66    /// Naming it here is what lets the layout find one and be sure it has found one, rather than
67    /// assuming that whatever a two-armed block ends with must be the branch.
68    pub cond: &'static str,
69    /// Reads the register the branch is on and sets the condition state from whether it is zero.
70    pub test: &'static str,
71    /// Goes to the block's first successor when the condition held.
72    pub if_true: &'static str,
73    /// Goes to the block's first successor when the condition did not hold.
74    pub if_false: &'static str,
75    /// Goes to the block's first successor.
76    pub jump: &'static str,
77    /// The comparisons a branch on their answer can be folded into, and what each pair becomes.
78    ///
79    /// Empty is a target that does not do this, and the layout then writes the test every time.
80    pub fused: &'static [Fusion],
81}
82
83/// A comparison, and the two instructions a branch on its answer becomes.
84#[derive(Debug, Clone, Copy, PartialEq, Eq)]
85pub struct Fusion {
86    /// The comparison a rule selects, which writes a byte saying what it found.
87    pub set: &'static str,
88    /// The same comparison with the byte gone, which sets the condition state and keeps nothing.
89    ///
90    /// Its operands are the ones the comparison read, in the same order, with the destination at
91    /// the front taken off. The layout rewrites nothing else about them.
92    pub cmp: &'static str,
93    /// Goes to the block's first successor when the comparison held.
94    pub if_true: &'static str,
95    /// Goes to the block's first successor when the comparison did not hold.
96    pub if_false: &'static str,
97}