Inclusive ranges (..=) slower than exclusive range + 1 (..n + 1) #131333
Labels
C-optimization
Category: An issue highlighting optimization opportunities or PRs implementing such
I-slow
Issue: Problems and improvements with respect to performance of generated code.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
I'm not sure why this happens, but ..= generates more instructions than ..n + 1. We should figure out which one is more performant and make both equal. (This question sprouted from rust-lang/rust-clippy#8317)
Godbolt
..n + 1
..=n
The text was updated successfully, but these errors were encountered: