a phi node
/ FYE node (phi = the Greek letter, written φ) /
Picture two roads merging into one. A traveler arriving at the junction carries a parcel, but it came from a different shop depending on which road they took. To know what is in the parcel at the junction, you have to ask which road they came in on. A phi node is the compiler's way of asking exactly that question about a value at a control-flow merge.
Phi nodes exist because of SSA's one rule: every name is defined exactly once. That rule breaks at a merge point. Suppose an if-statement sets x to 1 on the then-path and x to 2 on the else-path; after the branches rejoin, code that uses x cannot point to a single definition. SSA introduces a phi node at the start of the merge block: x3 = phi(x1 from the then-block, x2 from the else-block). It says 'x3 equals x1 if we arrived from the then-block, else x2'. It is not a real machine instruction that computes anything — it is a notation that records, per incoming edge, which earlier version flows in. There is one phi argument for each predecessor block.
It matters because phi nodes are what let SSA keep its single-definition promise across branches and loops (a loop variable gets a phi at the loop header choosing between its initial value and its updated value). Without phi nodes, dataflow analysis would have to scatter back through control flow at every merge. A caveat: phi is a fiction of the IR. Before code generation, the compiler 'destroys' phis by inserting ordinary copy instructions on the incoming edges, so no phi survives into the actual machine code.
if (cond) x1 = 1; else x2 = 2; // merge block: x3 = phi(x1 [from then], x2 [from else]) // pick by the path actually taken use(x3)
The phi node names x3 as 'whichever version reached this point', so SSA keeps exactly one definition per name.
A phi is not a real instruction and computes nothing at run time; it is removed before codegen by inserting plain copies on the incoming edges, so you will never see a phi in disassembly.