You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
The more I think about this the more I appreciate the current "ephemeral control flow on the side" approach. So I'm considering whether there are ways to embrace what we have, for instance by adding utility to Binaryen to not only obtain information about its IR but also to modify it. Like, once a function has been compiled, we know everything about it and can technically modify parts of it, for instance eliminating unnecessary instructions, inject more code or even recompiling with a different set of assumptions. Hmhmm...
Closing this issue as part of 2020 vacuum because it's really just ideas, and nothing concrete yet, so the usefulness of keeping this issue open is somewhat limited.
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.
The text was updated successfully, but these errors were encountered: