Further strengthen the type-based optimizations #5688
Merged
Conversation
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
While at it, also add test cases for addition and multiplication.
The ssa_opt_float pass rewrites arithmetic instructions to special float operations. During the rewrite, the `arg_types` annotation was inherited in a random way. Be sure to assign correct `arg_types` annotation for each new float instruction created.
Optimize the use of a tuple as lookup table, such as in the following
example:
element(N, {10, 11, 12, 13, 14, 15})
bjorng
added
team:VM
Contributor
CT Test Results 4 files 358 suites 44m 6s ⏱️ Results for commit 46323c0. ♻️ 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 |
The main type analysis and optimizer sub pass iterates until a
fixpoint is reached. To ensure convergence, this sub pass is limited
in how it calculates ranges. It is only allowed to calculate a range
for operations that retain or shrink the ranges of their
operands. Examples of such operations are `band`, `bsr`, and `rem`. It
is not possible to calculate a range for operations such as `+' and
`bsl` that expand the ranges of their arguments.
This commit adds the `opt_range` sub pass that is run a single time
after type analysis pass. It will start from the types found in
annotations and propagate them forward through arithmetic instructions.
Here is an example:
foo(N0) ->
N1 = N0 band 3,
N = N1 + 1, % N1 is in 0..3
element(N, % N is in 1..4
{zero,one,two,three}).
The range for `N1` was found by the main type pass. The range for
`N` was found by `opt_ranges`. Given a range for `N`, the JIT
will omit all range and type test for this call to `element/2`.
bjorng
force-pushed
the
bjorn/type-based-optimizations
branch
from
becb62f to
9be154d
Compare
bjorng
force-pushed
the
bjorn/type-based-optimizations
branch
from
9be154d to
46323c0
Compare
garazdawi
reviewed
Feb 7, 2022
bjorng
force-pushed
the
bjorn/type-based-optimizations
branch
from
46323c0 to
382d84f
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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.
Building on #5316 and #5664, this pull request annotates more arithmetic instructions with type information to allow the JIT to generate better code.
With this PR, the compiler and the JIT can now optimize a tuple used as a lookup table such as in the following example (similar to real code in the
base64module):Because
Nis known to be an integer in the range 1 through 4, the JIT will omit all type and range checks and generate inlined code to fetch theNth element of the tuple.