| Issue |
139866
|
| Summary |
AArch64 ISel(?) miscompilation from weird Rust MIR
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
saethlin
|
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
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.
![]()
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
