-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
Refactor type-checking to not inline everything #1557
Comments
The IR would like to organise a program into a tree. Instructions gathered into blocks, gathered into functions, gathered into modules. So having distinct functions and all their meta available to IR would be beneficial structurally and analytically. To the best of my knowledge, the debugger is mostly interested in attributing spans to instructions, but being able to resolve full paths of symbols to instructions is important to set breakpoints (or inspect memory values). Without the absolute naming of functions this becomes impossible. @Dentosal knows more. |
For some context: function declarations were originally inlined upon application to assist with a 1:1 codegen. You're given a fully typed node and you just serialize it to opcodes. You are also right in that it allows us to skip implementing a function call stack in the Fuel VM. It has certainly caused a fair share of hurdles, though. |
I dig your proposed module format for sure. I'm wondering if |
This will be solved by #1821. |
Currently, type-checking inlines everything into the entry point of the root module. As a result a call to
compile_to_ast
(or more specifically,TypedParseTree::type_check
) leaves us with a singleTypedParseTree
representing only the root module with its inlined entry point. TheTypedParseTree
s for individual submodules are dropped duringcompile_inner_dependency
.Why inline everything (and why during type-check)?
The original motivation behind inlining everything was to simplify the old code generation step which translated the AST directly to ASM. By inlining everything into the entry point during type-checking, the burden of having to think about how to represent function calls in Fuel VM assembly was removed altogether. @sezna pls correct me if I'm wrong or missing something here!
Issues with inlining everything
We are starting to see some bubbling issues arise from the current approach of inlining everything, and in particular inlining everything during type checking.
node_at_span
implementation insway-lsp
due to inlined AST #1555sway-ir
implementation Future IR desiderata. #738We also see some shoe-horning of unrelated compilation steps into type-checking as a result. E.g. currently we pass the
dead_code_graph
through the entirety of type-checking solely because that's the only time we have access to the fully typed submodules. As a result there are mentions ofdead_code_graph
everywhere throughout semantic_analysis, when ideally it could be a small, distinct step that follows type-checking.Potential Solution
Change type-checking to return a more structured, non-inlined representation of the typed program. E.g. I'm imagining something like the following pseudo:
Having something like this would help a lot with the sway-lsp issue and help with the separation of concerns like the graph construction for control flow analysis.
I'm less clear on what the implications would be for
sway-ir
or what this would mean for keeping function mappings in code generation that could be used by the debugger - @otrho you might have some more insight?Even if we do end up determining that it's useful to have an inlined AST for code generation, It would be beneficial to separate this into a dedicated AST-inlining step that operates on the structured, non-inlined AST.
The text was updated successfully, but these errors were encountered: