[compiler-v2] [waiting for comparison testing before merging] Inefficient loads: window peephole optimization #14796
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
⏱️ 1h 29m total CI duration on this PR
|
This stack of pull requests is managed by Graphite. Learn more about stacking. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #14796 +/- ##
=======================================
Coverage 60.1% 60.1%
=======================================
Files 856 856
Lines 211013 211019 +6
=======================================
+ Hits 126824 126830 +6
Misses 84189 84189 ☔ View full report in Codecov by Sentry. |
vineethk
changed the title
vineethk
force-pushed
the
vk/variable-window-peephole
branch
from
b9e661a to
17a143c
Compare
Merged
2 tasks
brmataptos
approved these changes
Sep 30, 2024
|
|
||
| impl InefficientLoads { | ||
| // We need at least 3 instructions, corresponding to points 1, 2, and 4 in the pattern | ||
| // described in the module documentation. |
There was a problem hiding this comment.
module documentation --> file documentation, above.
There was a problem hiding this comment.
It is indeed the module documentation (made using //! at the beginning of the file).
I'll add saying "at the top of the file" to clarify, but we have used this terminology elsewhere in the code base in the same sense as here.
| } | ||
|
|
||
| impl WindowOptimizer for InefficientLoads { | ||
| fn optimize_window(&self, window: &[Bytecode]) -> Option<(Vec<Bytecode>, usize)> { |
There was a problem hiding this comment.
Document this function. The Vec seems to be a new copy of the window which is optimized. What is the usize?
There was a problem hiding this comment.
Note that this is an implementation of a trait method (WindowOptimizer::optimize_window), which contains the documentation:
/// Given a `window` of bytecode, return a tuple containing:
/// 1. an optimized version of a non-empty prefix of the `window`.
/// 2. size of this prefix (should be non-zero).
/// If `None` is returned, the `window` is not optimized.
I don't think it makes sense to copy paste this documentation of the trait method into every implementation: this is not the style followed either in our repo or generally in Rust or other languages I have worked with. So I am leaving this as is.
|
|
||
| impl<T: FixedWindowOptimizer> BasicBlockOptimizer for FixedWindowProcessor<T> { | ||
| impl<T: WindowOptimizer> BasicBlockOptimizer for WindowProcessor<T> { | ||
| fn optimize(&self, block: &[Bytecode]) -> Vec<Bytecode> { | ||
| let mut old_block = block.to_vec(); | ||
| // Run single passes until code stops changing. |
There was a problem hiding this comment.
It seems likely this can be optimized, but we can wait and see how slow it is first.
There was a problem hiding this comment.
SG. Right now, there does not seem to be any statistical difference between compilation with this on and off, when compiling the aptos framework and its dependencies.
| 0: LdU64(1) | ||
| 1: LdU64(2) | ||
| 2: LdU64(3) | ||
| 3: CopyLoc[0](Arg0: &S) |
There was a problem hiding this comment.
We really should fix the bytecode generator. This kind of thing doesn't look easily amenable to peephole opts.
There was a problem hiding this comment.
I added this test to showcase a case where just the peephole won't be sufficient, as you point out. I have a follow up PR where I have reduced a bunch of remaining cases from the aptos-framework where we have optimizable code-gen behavior.
vineethk
force-pushed
the
vk/variable-window-peephole
branch
from
17a143c to
3c9937d
Compare
rahxephon89
approved these changes
Oct 1, 2024
vineethk
changed the title
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ Forge suite
|
✅ Forge suite
|
✅ Forge suite
|
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
Closes #14169.
Note: this PR will not be merged until appropriate comparison testing is carried out on this branch.
In this PR, we implement a peephole optimization for addressing inefficient loads generated (load constant that is immediately stored, and then later moved back to the stack). This optimization subsumes a previous optimization, which has been removed.
With this optimization, when compiling the
aptos-framework, the difference between number of instructions generated by v1 vs. v2 is down to an increase of 0.7%.This PR also includes some refactoring in the peephole optimization traits, and some small changes to the output of the instruction count comparison script.
How Has This Been Tested?
opt_load_01.move,test03goes from 34 instructions to 14).Key Areas to Review
Type of Change
Which Components or Systems Does This Change Impact?