Open
Description
I tried this code:
playground link, build asm or llvm ir to see it
pub fn range_inclusive_slow() {
for _i in 0..=500 {}
}
pub fn range_exclusive_fast() {
for _i in 0..500 {}
}
I expected to see this happen: In release mode, both functions should be optimized to no-ops.
Instead, this happened: range_exclusive_fast
was optimized away while range_inclusive_slow
was not. The only difference between the functions is the use of an inclusive range.
playground::range_inclusive_slow:
xor ecx, ecx
mov eax, 500
.LBB0_1:
lea edx, [rcx + 1]
cmp ecx, 500
mov ecx, edx
cmovge ecx, eax
jge .LBB0_3
cmp ecx, 501
jl .LBB0_1
.LBB0_3:
ret
playground::range_exclusive_fast:
ret
As far as I can tell, the range_inclusive_slow
assembly code does a whole lot of nothing (besides wasting cpu time), so I'm not sure why it wasn't optimized away (when the Range
one was). The issue is also present in the LLVM IR.
Meta
rustc --version --verbose
:
rustc 1.86.0-nightly (8239a37f9 2025-02-01)
binary: rustc
commit-hash: 8239a37f9c0951a037cfc51763ea52a20e71e6bd
commit-date: 2025-02-01
host: x86_64-unknown-linux-gnu
release: 1.86.0-nightly
LLVM version: 19.1.7
@rustbot label -C-bug A-codegen A-LLVM C-optimization I-slow T-compiler
Metadata
Metadata
Assignees
Labels
Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generationCategory: An issue highlighting optimization opportunities or PRs implementing suchIssue: Problems and improvements with respect to performance of generated code.Relevant to the compiler team, which will review and decide on the PR/issue.