[wip] [mypyc] feat: unroll certain for loops with known params #19518
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
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
e68c440 to
7c238c8
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.
This PR, when finished, will unroll any
forloops that iterate across a set of values which are known at compile timeThis allows us to entirely bypass any iteration overhead and keep more things in C-space
It also does the same when iterating across the values of any mypyc-defined tuple types, whether the values are known at compile time or not
The generated C code will be longer but more readable with less branching and no iterator overhead, will offer the C compiler many more opportunities for optimization
It's probably best for everyone if these 2 PRs are merged before anyone spends time looking at this one:
range#19511