[all-commits] [llvm/llvm-project] 06d5b1: [SROA] Remove Dead Instructions while creating spe...
llvmbot via All-commits
all-commits at lists.llvm.org
Fri Dec 18 08:53:58 PST 2020
Branch: refs/heads/master
Home: https://github.com/llvm/llvm-project
Commit: 06d5b1c9ad52476e845f969cf82e00e383f9cf40
https://github.com/llvm/llvm-project/commit/06d5b1c9ad52476e845f969cf82e00e383f9cf40
Author: Arnamoy Bhattacharyya <arnamoy.bhattacharyya at huawei.com>
Date: 2020-12-18 (Fri, 18 Dec 2020)
Changed paths:
M llvm/include/llvm/Transforms/Scalar/SROA.h
M llvm/lib/Transforms/Scalar/SROA.cpp
Log Message:
-----------
[SROA] Remove Dead Instructions while creating speculative instructions
The SROA pass tries to be lazy for removing dead instructions that are collected during iterative run of the pass in the DeadInsts list. However it does not remove instructions from the dead list while running eraseFromParent() on those instructions.
This causes (rare) null pointer dereferences. For example, in the speculatePHINodeLoads() instruction, in the following code snippet:
```
while (!PN.use_empty()) {
LoadInst *LI = cast<LoadInst>(PN.user_back());
LI->replaceAllUsesWith(NewPN);
LI->eraseFromParent();
}
```
If the Load instruction LI belongs to the DeadInsts list, it should be removed when eraseFromParent() is called. However, the bug does not show up in most cases, because immediately in the same function, a new LoadInst is created in the following line:
```
LoadInst *Load = PredBuilder.CreateAlignedLoad(
LoadTy, InVal, Alignment,
(PN.getName() + ".sroa.speculate.load." + Pred->getName()));
```
This new LoadInst object takes the same memory address of the just deleted LI using eraseFromParent(), therefore the bug does not materialize. In very rare cases, the addresses differ and therefore, a dangling pointer is created, causing a crash.
Reviewed By: lebedev.ri
Differential Revision: https://reviews.llvm.org/D92431
More information about the All-commits
mailing list