Optimize compilation of functional-looking assignment RHSs #5589
Conversation
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
atomb
previously approved these changes
Jul 1, 2024
The first couple of test failures look like they're just because some files need to be regenerated, but there are a few integration test failures that look real. |
# Conflicts: # Source/DafnyCore/Backends/SinglePassCodeGenerator/SinglePassCodeGenerator.cs
# Conflicts: # Source/DafnyCore/Backends/SinglePassCodeGenerator/SinglePassCodeGenerator.Statement.cs # Source/DafnyCore/GeneratedFromDafny/DCOMP.cs # Source/DafnyCore/GeneratedFromDafny/RAST.cs
atomb
previously approved these changes
Jul 10, 2024
| Contract.Assert(n == inTmps.Count); | ||
| // finally, the jump back to the head of the function | ||
| EmitJumpToTailCallStart(wr); | ||
| Contract.Assert(!inLetExprBody); // a tail call had better not sit inside a target-code lambda |
| @@ -2749,7 +2750,10 @@ protected class NullClassWriter : IClassWriter { | |||
| Coverage.Instrument(f.Body.tok, $"entry to function {f.FullName}", w); | |||
| Contract.Assert(enclosingFunction == null); | |||
| enclosingFunction = f; | |||
| CompileReturnBody(f.Body, f.OriginalResultTypeWithRenamings(), w, accVar); | |||
| #if NEW_ATTEMPT | |||
There was a problem hiding this comment.
Is this relevant beyond debugging?
There was a problem hiding this comment.
Oops. That was leftover from straightening out a merge. Thanks for catching that.
| @@ -3606,6 +3606,10 @@ protected class ClassWriter : IClassWriter { | |||
| message = "unexpected control point"; | |||
| } | |||
|
|
|||
| // Wrapping an "if (true) { ... }" around the "break" statement is a way to tell the Java compiler not to give | |||
| // errors for any (unreachable) code that may follow. | |||
atomb
approved these changes
Jul 10, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Previously, the single-pass compiler would use
TrExprOptto turn nested expressions into target-language statements, ending in areturn. This PR generalizes that mechanism so that the ending action is parameterized. In particular, the PR now appliesTrExprOptto single-LHS assignment statements. This allows the RHS of such assignment statements to be deeply nested expressions, without running into, for example, the limits ofjavacto deal with nested lambda expressions.Fixes #3868
Implementation
This PR required a change to the target-code strategy of
matchconstructs. Previously,cases turned into a sequence ofifstatements (note, not a cascadingif). If one of thoseifstatements determined that thecaseapplied, then a boolean variable,unmatched, was set tofalse. Each of theseifstatements was thus also guarded by the conditionunmatched.This previous strategy caused a problem when the body of the cases is an assignment. Since every assignment was guarded by an
if, target languages with definite-assignment rules weren't able to determine that the variable was always assigned.A more straightforward strategy is to jump (using a
breakorgoto) to the end of the target code for thematch, rather than setting theunmatchedvariable. This lets the target language easily see that the variable has been assigned on all paths. It also means that theunmatchedvariable and its tests are not needed at all. Furthermore, the lastcasedoes not need an enclosingifstructure at all, since if the priorcases don't apply, then the last one must apply.This PR improves the strategy to the one with jumps.
Work along the way
fix: Use Downcast for let RHS and for function body
Fixes #5597
By submitting this pull request, I confirm that my contribution is made under the terms of the MIT license.