Skip to content

Prepass/Checker ideas #999

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
dcodeIO opened this issue Dec 9, 2019 · 2 comments
Closed

Prepass/Checker ideas #999

dcodeIO opened this issue Dec 9, 2019 · 2 comments

Comments

@dcodeIO
Copy link
Member

dcodeIO commented Dec 9, 2019

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.

@dcodeIO
Copy link
Member Author

dcodeIO commented Dec 21, 2019

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...

@dcodeIO
Copy link
Member Author

dcodeIO commented May 27, 2020

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.

@dcodeIO dcodeIO closed this as completed May 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant