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
Fixed some major issues related to Dead Variable Elimination #23
Merged
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
csabahruska
reviewed
Feb 11, 2019
Copy propagation now no longer viloates PNI conventions (disabled right-unit law) Added a new ExpChange type: DeletedHeapOperation Added DeletedHeapOperation effect to NonSharedElimination
Now NonsharedElimination only invalidates the analysis results if it actually changed the AST.
When binding into a variable, both liveness and strutural information was propagated both ways. Now liveness info is only propagated backward and structural info is only propagated forward.
Now DVE correctly handles case expressions with side-effecting computations. Now DVE correctly handles case expressions with failable patterns.
Live Variable Anaylsis now only marks node tags live if they are either bound out to a node pattern, or pattern matched on AND the result of the expression is live. Side-effects and pattern match failure checks are handled by DVE.
BPS will make DVE much simpler to implement BPS makes sure that: - only variable can be bound to non-variable patterns - all case scrutinees are variables
Now DVE correctly handles binding patterns.
DVE now correctly handles store/fetch pairs in dead alternatives
andorp
reviewed
May 19, 2019
csabahruska
reviewed
May 20, 2019
Right unit law still works, but the last expression in a binding sequence always must be of form "pure <var>".
Rendering option for pretty printing was a global option for the pipeline. Now it is an argument for the printer flag.
csabahruska
reviewed
May 29, 2019
andorp
requested changes
May 29, 2019
Removed some dead code Added newlines
andorp
approved these changes
May 30, 2019
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.
The problem
Dead Variable Elimination treated side-effecting computation incorrectly.
Take a look at the following example:
The variable
y
is DEAD, because it is irrelevant in the context of the pure result of the program. However, its binding cannot be removed, because it contains a side-effecting computation. If we were to remove this, the semantics of the program would change.The solution
Treat side-effecting computations in the transformation level using
EffectMap
. Now Dead Variable Elimination will perform a simple bottom-up analysis of the syntax tree, and collect so-called "protected" variables. These variables are protected, because some expression with a side-effecting computation is bound to them. Protected variables cannot be removed from the program.Note that this analysis is local, it will not follow function calls.
Prerequisites
Pattern bindings need special treatment, because their left-hand side can contain any arbitrary expression. This makes it hard to "identify" a computation. To resolve this problem with minimal effort, we introduce a new convention: Each pattern binding with a non-variable pattern must have a simple left-hand side, that is they can only be of the form:
pure <var>
. Also, for convenience, all case scrutinees can only be variables as well. This ensures that every "real" computation has a name.To introduce these conventions, we define a new transformation:
BindingPatternSimplification
.Alternative solution
We could implement an interprocedural analysis which calculates the possible side-effecting computations for every function and binding. Currently,
EffectMap
only calculates this information for functions, which is not sufficient.Failable patterns
Case expressions containing failable patterns can give rise to a very similar problem to side-effecting computations. See the code below.
The variable
y
is DEAD considering the pure result of the program, but a failable case expression is bound to it. If we consider pattern match errors to be implicit (i.e.: the runtime would throw an error whenever it cannot match a value on any pattern), then this is a very similar problem to the one mentioned above. However, if pattern match errors are explicit (i.e.: there is always a#default
alternative with an error throwing right-hand side), then the above piece of code has undefined semantics, and we do not have to consider it for any analysis or transformation.This question requires further discussion.