This is a known issue:
- LLVM Memory Model needs more rigor to avoid undesired optimization results · Issue #34577 · llvm/llvm-project · GitHub
- Miscompilation with noalias and pointer equality · Issue #59679 · llvm/llvm-project · GitHub
- InstCombine cannot blindly assume that inttoptr(ptrtoint x) -> x · Issue #33896 · llvm/llvm-project · GitHub
- IndVarSimplify incorrectly replaces a pointer with another · Issue #39717 · llvm/llvm-project · GitHub
I recently encountered the same bug where LLVM was replacing a pointer with another one so I created D143129 in an attempt to fix the issue using alias analysis results (to target my specific bug).
@nikic suggested that the correct way to go would be be to compare the pointer’s underlying objects and that we should check IR diffs for llvm-test-suite to see the impact of this approach.
I posted the IR diffs for llvm-test-suite using -O3 in this comment here (also see the follow-up comments for some discussion): ⚙ D143129 [GVN] Do not propagate equalities for noalias pointers
Reviewers suggested that I post this on discourse to seek more opinions. I think there are three main questions here:
- Is there a better way to deal with this issue?
- Should we allow replacement of pointers with null?
- How should we deal with other optimization regressions?