While iterating optimizations is nice, I think you missed the main point of SSA.
SSA makes dataflow between operations explicit; it completely eliminates the original (incidental) names from programs. Because of that, all dataflow problems (particularly forward dataflow problems) get vastly simpler.
With SSA you can throw basically all forward dataflow problems (particularly with monotonic transformations) into a single pass and they all benefit each other. Without SSA, you have every single transformation tripping over itself to deal with names from the source program and introducing transformations that might confuse other analyses.
I know we teach different compiler optimizations at different stages, but it's really important to realize that all of them need to work together and that having each as a separate pass is a good way to fail at the phase ordering problem.
And going further with the sea-of-nodes representation just makes them all more powerful; I really do recommend reading Cliff Click's thesis.
It's funny, I've been working on a CPS (continuation passing style) graph optimizer loosly based on Cliff Click's thesis and when I show it to the robots they're like "yeah, that's academic fluffery, it'll never fly" to try inflate my ego a bit until I explain how it actually works then they're "wait, that's actually possible ...and a good idea".
His 'optimization as a constraint solving problem' thing is actually pretty powerful and it just so happens I've been fiddling with a Projective Dynamics constraint solver (which is what the VM is for, to define the constraints) whivh I can abuse to optimize CPS graphs so... take that Robots!
You're very correct but I suppose I was really answering why compilers centralize around SSA. It's a bold choice to choose one data structure for everything, and that requires more motivation than, "it makes certain optimizations really easy". Because again, it makes other stuff harder.
>And going further with the sea-of-nodes representation just makes them all more powerful; I really do recommend reading Cliff Click's thesis.
We might have to agree to disagree on this one. I actually found sea of nodes to be a boneheaded idea. It makes one or two optimizations a little more elegant but everything else a huge pain in the ass. At least, that was my experience.
A huge benefit of the sea of nodes representation, at least how I envisioned it and we implemented in the early days of TurboFan, is that branch folding, load elimination, and all of the other forward dataflow analyses that do monotonic reductions can be combined into a single pass that operates on the IR in the optimal order and can iterate to a fix point efficiently.
SSA makes dataflow between operations explicit; it completely eliminates the original (incidental) names from programs. Because of that, all dataflow problems (particularly forward dataflow problems) get vastly simpler.
With SSA you can throw basically all forward dataflow problems (particularly with monotonic transformations) into a single pass and they all benefit each other. Without SSA, you have every single transformation tripping over itself to deal with names from the source program and introducing transformations that might confuse other analyses.
I know we teach different compiler optimizations at different stages, but it's really important to realize that all of them need to work together and that having each as a separate pass is a good way to fail at the phase ordering problem.
And going further with the sea-of-nodes representation just makes them all more powerful; I really do recommend reading Cliff Click's thesis.