<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>SSA from Scratch, with Mica on Mica</title><link>https://mica-dev.com/learn/ssa/</link><description>Recent content in SSA from Scratch, with Mica on Mica</description><image><title>Mica</title><url>https://mica-dev.com/Mica%20Development%20Web.jpeg</url><link>https://mica-dev.com/Mica%20Development%20Web.jpeg</link></image><generator>Hugo</generator><language>en</language><atom:link href="https://mica-dev.com/learn/ssa/index.xml" rel="self" type="application/rss+xml"/><item><title>1 — The question SSA answers</title><link>https://mica-dev.com/learn/ssa/why-ssa/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://mica-dev.com/learn/ssa/why-ssa/</guid><description>The intermediate code a compiler works on, the question every optimization asks of it — which write does this read see? — the dataflow answer, and the SSA answer, which puts the reply into the name.</description></item><item><title>2 — The graph and its dominators</title><link>https://mica-dev.com/learn/ssa/graph-and-dominance/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://mica-dev.com/learn/ssa/graph-and-dominance/</guid><description>Basic blocks and the edges between them, a loop as a back edge, and the dominator tree with its dominance frontiers: the structure SSA is built on, read from the compiler&amp;#39;s own files.</description></item><item><title>3 — Where the φ functions go</title><link>https://mica-dev.com/learn/ssa/phi-placement/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://mica-dev.com/learn/ssa/phi-placement/</guid><description>Why two versions of a variable can only meet at a dominance frontier, how the frontier is iterated because a φ is itself a write, and why a variable nobody reads gets no φ at all: placement, worked by hand and checked against the compiler.</description></item><item><title>4 — Renaming</title><link>https://mica-dev.com/learn/ssa/renaming/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://mica-dev.com/learn/ssa/renaming/</guid><description>How every write becomes a new version and every read finds the one version that reaches it: one walk over the dominator tree with a stack per variable, worked by hand and checked line by line against the compiler&amp;#39;s SSA listing.</description></item><item><title>5 — What SSA makes easy</title><link>https://mica-dev.com/learn/ssa/optimizations/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://mica-dev.com/learn/ssa/optimizations/</guid><description>Forwarding, constant folding, value numbering and dead code, each shown before and after on a small routine, with the ledger in which the compiler counts its own work: why one definition per name makes each of them short.</description></item><item><title>6 — Leaving SSA</title><link>https://mica-dev.com/learn/ssa/leaving-ssa/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://mica-dev.com/learn/ssa/leaving-ssa/</guid><description>A machine has no φ functions, so the form must be left before code is made: the textbook&amp;#39;s copies, the lost copy and the swap that break them, conventional SSA, and how Mica leaves the form by renaming alone — with the further reading for the whole series.</description></item></channel></rss>