Inefficient compiler optimization between stable versions on nightly

[ArhanChaudhary]

I have been recently been working on a logic simulator that requires building on the nightly channel. With the release of Rust 1.77.1, I subsequently updated my version from nightly-2024-02-08 to nightly-2024-03-28 and instantly noticed a drastic performance impact. Upon further investigation, starting from nightly-2024-02-12 and onwards, the compiler is no longer able to optimize my multiplexor function.

The godbolt link is unintentionally misleading with its versions. Strangely, this regression does not happen on the equivalent stable channel versions (1.76.0 and 1.77.1), and the reason why this happens only on nightly is beyond my current knowledge.

rustc --version --verbose: (The first bad version, and I think the dates are shifted because of time zones)

rustc 1.78.0-nightly (1a648b397 2024-02-11)
binary: rustc
commit-hash: 1a648b397dedc98ada3dd3360f6d661ec2436c56
commit-date: 2024-02-11
host: aarch64-apple-darwin
release: 1.78.0-nightly
LLVM version: 17.0.6

I'm not sure which regression label to mark this issue with, since it's occurred between stable versions but on the nightly channel, so I'll omit one for now.

@rustbot modify labels: -regression-untriaged

[workingjubilee]

@ArhanChaudhary

The godbolt link is unintentionally misleading with its versions. Strangely, this regression does not happen on the equivalent stable channel versions (1.76.0 and 1.77.1), and the reason why this happens only on nightly is beyond my current knowledge.

The stable version may be marked as having come out on 2024-03-27 but it dates to the nightly of around ~13 weeks before that, that's probably why. (i.e. there's not actually a corresponding stable release for nightly 2024-02-12 yet).

[Noratrieb]

Thank you for the report! It would be useful to bisect the regression using cargo-bisect-rustc to make it easier to figure out what happened and ping the relevant people. You already have the nightly, but getting the precise PR is even better.

[ArhanChaudhary]

Thank you for the report! It would be useful to bisect the regression using cargo-bisect-rustc to make it easier to figure out what happened and ping the relevant people. You already have the nightly, but getting the precise PR is even better.

Thanks for the response. I'm short on time at this exact moment, but I'll identify and bisect the regression commit soon.

[ArhanChaudhary]

searched nightlies: from nightly-2024-02-08 to nightly-2024-02-13
regressed nightly: nightly-2024-02-12
searched commit range: 6cc4843...1a648b3
regressed commit: 42752cb

bisected with cargo-bisect-rustc v0.6.8

Host triple: aarch64-apple-darwin
Reproduce with:

cargo bisect-rustc -v --start=2024-02-08 --end=2024-02-13 --script ./test.sh 

test.sh (using cargo-show-asm)

#!/bin/sh

set -ex

export OUTPUT=`cargo asm --simplify`
test ${#OUTPUT} -lt 500

I can provide more information about my build configuration if necessary.

[DianQK]

It seems that jump-threading is making the IR more complex. The optimization information has not been lost: https://alive2.llvm.org/ce/z/cPHXB2.

@rustbot label A-mir-opt A-LLVM

[DianQK]

Disable jump-threading: https://godbolt.org/z/MfM9Mnb6K.
Disable jump-threading (-Cno-prepopulate-passes): https://godbolt.org/z/Wcj7j7b5s (I can see the IR has become more complex. For jump-threading, this might not be a problem.)
Alive2: https://alive2.llvm.org/ce/z/a_9jWL.

[apiraino]

paging @cjgillot @tmiasko for #117206

@ArhanChaudhary thanks for bisecting your issue report. Can you quantify a bit the performance impact reported? thanks

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium

[ArhanChaudhary]

paging @cjgillot @tmiasko for #117206

@ArhanChaudhary thanks for bisecting your issue report. Can you quantify a bit the performance impact reported? thanks

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-medium

For my logic simulator specifically, the simulated clock speed drops from around 21.5 MHz to 1.75 MHz following this regression on a wasm32-unknown-unknown target, leaving me unable to use later nightly versions with a performance impact of around 90%. And although not a big deal for my use case, the binary size also increases from 552kb to 659kb. These happen primarily because the multiplexor function is an important part of my logic simulator and I have aggressive performance inlining rules, so this single inefficiency starts to add up.

[ArhanChaudhary]

@rustbot label -E-needs-bisection