Ordering symbols for closures and code, and closure projection substitution#540
Closed
Keryan-dev wants to merge 3 commits intoocaml-flambda:flambda2.0-stablefrom
Closed
Ordering symbols for closures and code, and closure projection substitution#540Keryan-dev wants to merge 3 commits intoocaml-flambda:flambda2.0-stablefrom
Keryan-dev wants to merge 3 commits intoocaml-flambda:flambda2.0-stablefrom
Conversation
This was referenced Jul 6, 2021
|
Being done in the Flambda backend repo. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
This finish the job of #511 by replacing closure projections by the corresponding lifted symbols and ordering the symbols topologically before declaring them, and grouping when necessary.
This is concurrent to #541, which simply groups declarations together in a single let-binding.
The patch is not in a mergeable state, see issue #542.
I open the two PRs to discuss which approach is preferable as I have little insight on the way Simplify deals with let-symbols, performance-wise.
This patch is heavier than #541 (which doesn't add cost to the transformation) but produce code that might be more easily handled down the line. Sorting the declarations is done in a very similar way than
Sorted_lifted_constants, which is a bit frustrating but I didn't think wise to try to adapt it to be of use inLambda_to_flambda.