Description
So I've been looking into implementing a pre-pass (checker) a bit (initially to spot closed-over locals before compiling closures) and figured that this might also be a good opportunity to get our own lightweight IR going.
Currently we have the AST parsed from the sources and half an IR as program elements, but once there is a pre-pass of sorts we can as well do things like building a CFG while checking, comprised of basic blocks with incoming and outgoing links, leading to an alias graph like we use it in the post-assemblyscript pass on the Binaryen side. Means we could do ARC optimizations on our side, or whatever else we can do with a CFG. Ofc there are arguments for and against a CFG, and Max has done some research into alternatives, so that's mostly an arbitrary pick because I've become familiar with it when implementing the Binaryen pass. What I like about it is mostly that it can do quite a few things and isn't overly hard to implement.
However, if we do that we'll end up with additional data on the AST (like resolved types, resolved instances of generics) that isn't trivially convertible to JSON, but that might also be another opportunity. The splitting of AST and IR is not ultimately necessary currently except for serialization purposes (which we don't do yet, but was the initial idea), and somewhat limits the information we can store per node. If we'd combine this into one, we'd gain the option to serialize not only the plain AST but also the CFG, so that we can at some point cache it across compilation runs (only rebuilding it if a function changed), which might make a lot of sense to reduce checking/compilation times eventually.
So far these are just ideas, but thought I pin this so you guys are aware, as this would be a major change to how the compiler works.