-
Notifications
You must be signed in to change notification settings - Fork 39
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
mirgen: improve scope-only
block
support (#928)
## Summary Don't emit `mnkBlock` MIR nodes for `nkBlockStmt`/`nkBlockExpr` nodes (`block` statements/expression) are not used for control-flow. This reduces the size of the produced MIR code and means that neither compiler-generated scope-only blocks nor `block` statements/ expression not targeted by `break` statements reach the code generators. Most notably, the code generated by the JavaScript code generator improves, in terms of size. ## Details Detection of blocks-used-for-control-flow is done via testing for the `sfUsed` flag: if present, the `nkBlockStmt`/`nkBlockExpr` is treated as used for control-flow, otherwise it's treated as only opening a scope. This is only a conservative approximation, however, and blocks where the label is marked as used through other means (or by appearing in a `break` within a `compiles`) will be mis-detected. So that the detection also works for `transf`-injected breaks and blocks, all `nkBreakStmt` AST in `transf` / `closureiters` / `lambdalifting` is now generated via the new `newBreakStmt` procedure in `lowerings`, which marks the provided label as used. When `mirgen.genBlock` gets passed an `nkBlockExpr`/`nkBlockStmt` node where the label symbol is not marked as used, it only emits the `mnkScope` block necessary for correct variable lifetimes. Since `cnkBlockStmt` are only generated for `mnkBlock` nodes by `cgirgen`, this means that the block statements are omitted in the final generated code too. Finally, `transf.transformBlock` is improved, and a necessary fix is applied: - instead of introducing a new label with `newLabel` during inlining, the original symbol is copied and adjusted. This ensures that the symbol flags (e.g., whether the symbol is used) are kept - the label symbol is no longer pushed to the `breakSyms` stack in the *inlining* case. This was/is unnecessary, as inlined AST is already transformed, and so none of the `nkBreakStmt` nodes within are processed - the *non-inlining* case doesn't use `transformSons`, but transforms the body AST directly. While having no practical effect at the moment, this means that the label slot is no longer treated as a symbol-in-a-usage-position No `mnkBlock` nodes being emitted for scope-only blocks is also visible in the `--expandArc` output, so the tests depending on the output are adjusted.
- Loading branch information
Showing
9 changed files
with
109 additions
and
102 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters