Skip to content

Empty RangeInclusive for loop optimizes worse than using Range #136423

Open
@Sky9x

Description

@Sky9x

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

No one assigned

    Labels

    A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.A-codegenArea: Code generationC-optimizationCategory: An issue highlighting optimization opportunities or PRs implementing suchI-slowIssue: Problems and improvements with respect to performance of generated code.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions