This is quite informative for an introduction to one particular type of IR. It's better than some others because it actually does mention that there are alterna

This is quite informative for an introduction to one particular type of IR. It's better than some others because it actually does mention that there are alternatives in some places. And since what people are using an IR for varies a lot from program to program, there is no alternative that is always best (there are trends, but even then you should be aware of the cost comparison). Since this post talks a lot about SSA, it might be worth mentioning the thing that probably confuses people the most: how do you know if a variable is valid in a BB. It can be informative (but memory-inefficient, and probably optimization-inefficient) to require all incoming variables to go through phi nodes. Also think about how destructors and outward `goto/break` affect dominance in strange ways. The second understated thing about SSA is: exactly how much additional data do you store for exactly what period of time. "Don't store the extra data" means many passes will have to recompute it, but "do store the extra data" makes it costlier when passes have to invalidate it. Also make sure you don't run out of RAM! My own post (more focused on interpreters, but not exclusively so) probably talks more about alternative implementation choices (though I do say "don't do that" for strictly-worse ones, and there are some I still haven't gone into detail about) in many compiler stages than any other source I've seen: https://gist.github.com/o11c/6b08643335388bbab0228db763f99219 https://gist.github.com/o11c/6b08643335388bbab0228db763f9921... The main aspect about the linked post that annoys me is that it falls into the trap of declaring a duality between "stack-based" and "register-based", when in fact there are so many options that the difference within each of those named categories can be bigger than the difference between them.