compiler: Optimize record updates #6033
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
CT Test Results 5 files 441 suites 1h 18m 20s ⏱️ For more details on these failures, see this check. Results for commit 85aa2e0. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts// Erlang/OTP Github Action Bot |
jhogberg
force-pushed
the
john/compiler/optimize-record-updates/OTP-18126
branch
from
209f508 to
43592a7
Compare
garazdawi
approved these changes
May 30, 2022
jhogberg
force-pushed
the
john/compiler/optimize-record-updates/OTP-18126
branch
from
43592a7 to
5b5be11
Compare
bjorng
approved these changes
May 31, 2022
jhogberg
force-pushed
the
john/compiler/optimize-record-updates/OTP-18126
branch
5 times, most recently
from
5ffc74f to
a450a24
Compare
|
Thanks, I've refactored the changes to |
jhogberg
added
testing
We don't need to stash the preserved term if it's currently live, making the code slightly shorter.
This is needed to keep the type information consistent in an upcoming commit that optimizes record updates. It will introduce a psuedo-instruction that does several updates at once, which gets converted either to a specialized instruction or a series of `setelement/3` calls during code generation. As the `setelement/3` is taken through `beam_call_types`, and that only dealt with normalized types prior to this commit, its type information would be less precise and could cause validation to fail.
This instruction updates several tuple fields at once, improving on the old `setelement/3 + set_tuple_element` method in the following ways: * Eliminates BIF call overhead, the tuple is copied and updated inline. * Doesn't require special treatment in the validator. * Uses heap allocations in the same manner as `put_tuple2` and friends. * When all fields are updated with the same value (runtime check), we can set `Dst=Src` and move on with our day. This is impossible with `set_tuple_element` as it requires a new copy every time to avoid creating illegal references from the old heap to the new heap.
jhogberg
force-pushed
the
john/compiler/optimize-record-updates/OTP-18126
branch
from
a450a24 to
85aa2e0
Compare
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.
#2080 isn't such a bad idea now that we have the JIT and far better type analysis. This PR is a modernized version that improves record update performance by a small but noticeable amount.