Description
The reproducer for this is a bit large, I've (mostly) reduced an output from https://github.com/cbeuw/rustlantis, so what I have is Rust MIR, but I'm linking a godbolt that has the LLVM IR: https://godbolt.org/z/sP7qG363b (Reduced a bit more than the previous but now requires the rustc flag -Zmir-opt-level=0 https://godbolt.org/z/1xWhzfMMq)
The structure of this program is that it hashes some locals, and prints a hash at the end. At some point in the optimization pipeline, the hash changes.
We (me and @nikic, who walked me through some opt-bisect use) are pretty confident this is an Aarch64 ISel issue because this produces the good hash:
rustc +nightly main.rs -Copt-level=2 -Cllvm-args=-opt-bisect-limit=3642 && ./main
And this produces the bad hash:
rustc +nightly main.rs -Copt-level=2 -Cllvm-args=-opt-bisect-limit=3647 && ./main
And the passes in that bisect range are:
BISECT: running pass (3643) AArch64 Instruction Selection on function (_ZN4main4main17he1f737bca831c768E)
BISECT: running pass (3644) SME Peephole Optimization pass on function (_ZN4main4main17he1f737bca831c768E)
BISECT: running pass (3645) Early Tail Duplication on function (_ZN4main4main17he1f737bca831c768E)
BISECT: running pass (3646) Optimize machine instruction PHIs on function (_ZN4main4main17he1f737bca831c768E)
BISECT: running pass (3647) Merge disjoint stack slots on function (_ZN4main4main17he1f737bca831c768E)
We've already checked that
rustc +nightly main.rs -Copt-level=2 -Cllvm-args=-no-stack-coloring=1 && ./main
produces the bad hash, so it doesn't seem like this is related to stack coloring.