`block-placement` LLVM pass introduces superfluous instruction in unrolled loop

[kotauskas]

Since Rust code is affected by this, and because Rustc uses a fork of LLVM, I'm reporting this here, although the same issue probably affects other LLVM-based compilers.

The following code:

fn check(b: u8) -> Option<u8> {
    if let 1..=127 = b { Some(b) } else { None }
}
pub fn conv(bytes: [u8; 4]) -> Option<u32> {
    bytes
        .into_iter()
        .try_fold(0, |sum, ch| {
            check(ch).map(|digit| sum + u32::from(digit))
        })
}

has this at the end of its assembly output:

        mov eax, 1
        ret
.LBB0_5:
        ret

Here it is on Godbolt.

.LBB0_5 could've been moved before the ret, reducing the number of rets in the function to 1. In fact, the LLVM IR only contains one ret up until the block placement pass, as can be seen in the optimization pipeline viewer on Godbolt.

Meta

rustc --version --verbose:

rustc 1.91.0-nightly (de3efa79f 2025-08-08)
binary: rustc
commit-hash: de3efa79f95852c7427587f1d535bfea7c0d6779
commit-date: 2025-08-08
host: x86_64-unknown-linux-gnu
release: 1.91.0-nightly
LLVM version: 21.1.0
Internal compiler ID: nightly

[workingjubilee]

Our fork of LLVM is extremely minimal on purpose. These days it is almost exclusively backports of patches. So, "probably" is more like "virtual certainty".

[Noratrieb]

This issue is best filed against LLVM itself (with an LLVM IR reproducer)