We should update results of the BranchProbabilityInfo after removing block in JumpThreading. Otherwise we will get dangling pointer inside BranchProbabilityInfo cache. Which can lead to various problems. Note that there is similar issue for the BlockFrequencyInfo but it's a subject for separate change.
Details
- Reviewers
dnovillo reames davidxl sanjoy congh haicheng hfinkel - Commits
- rGee40d1e8da38: Re-submit r272891 "Prevent dangling pointer problems in BranchProbabilityInfo"
rGc9179fd2c263: [JumpThreading] Prevent dangling pointer problems in BranchProbabilityInfo
rL275563: Re-submit r272891 "Prevent dangling pointer problems in BranchProbabilityInfo"
rL272891: [JumpThreading] Prevent dangling pointer problems in BranchProbabilityInfo
Diff Detail
- Repository
- rL LLVM
Event Timeline
include/llvm/Analysis/BranchProbabilityInfo.h | ||
---|---|---|
120 ↗ | (On Diff #59535) | New code should not use \brief, since we have autobrief enabled for our doxygen. |
include/llvm/Transforms/Utils/Local.h | ||
302 ↗ | (On Diff #59535) | Nit: document the new parameter (and maybe the \p LVI as well)? |
lib/Analysis/BranchProbabilityInfo.cpp | ||
643 ↗ | (On Diff #59535) | Why do you need to do a linear search here? Isn't Probs a DenseMap<Edge, BranchProbability>? IOW, why not: for (int i = 0; i < BB->numSuccessors(); i++) Probs.erase({BB, i}); |
unittests/Analysis/BlockFrequencyInfoTest.cpp | ||
58 ↗ | (On Diff #59535) | Should this be called releaseBPI? |
59 ↗ | (On Diff #59535) | Nit: spelling. Also add a period after the sentence. |
lib/Analysis/BranchProbabilityInfo.cpp | ||
---|---|---|
643 ↗ | (On Diff #59535) | Problem with this approach is that contents of the BB could have been changed since it was first recorded. If conditional terminator was replaced with unconditional jump, we may leave some BB references hanging in the map. |
unittests/Analysis/BlockFrequencyInfoTest.cpp | ||
58 ↗ | (On Diff #59535) | This is to be symmetric with buildBFI. Besides I suspect that BFI has the same issue and we will need to add "BFI->releaseMemory()" here. |
lib/Analysis/BranchProbabilityInfo.cpp | ||
---|---|---|
644 ↗ | (On Diff #59894) | Yes, compile time might be an issue here. It would be possible to avoid linear search by changing data type of the branch probability storage from: DenseMap<pair<BasicBlock*, unsigned>, BranchProbability> Probs; into: DenseMap<BasicBlock*, IndexedMap<unsigned>> Probs; However it would be fairly large change and I don't wont to mix it with this one. Does it sound reasonable if I will submit this version first and then follow up with a data type change? |
lib/Analysis/BranchProbabilityInfo.cpp | ||
---|---|---|
644 ↗ | (On Diff #59894) | Right, other than that issue, this lgtm; but I'd prefer waiting till someone more familiar with this code has had time to chime in about the potential compile time problems. |
I agree with Igor's analysis. Let's first fix the correctness issue. Any compile-time problems that show up, can be fixed with a data structure change later. Igor, do you have any test cases that show the problem? Without a test case, it's harder to justify this change.
Thanks. Diego.
Hi,
Noticeable effect of this failure appears only if new BasicBlock was allocated at the same place as the removed one. It will depend on many things which are impossible to guarantee for a single test case. I've added test which will fail AssertingVH in case if BasicBlock was not removed. Should be enough to guarantee that no one forgets to call eraseBlock in the future.
lib/Transforms/Scalar/JumpThreading.cpp | ||
---|---|---|
238 ↗ | (On Diff #60360) | maybe just check nullness of BPI |
268 ↗ | (On Diff #60360) | Same here. |
753 ↗ | (On Diff #60360) | This pattern repeats many times, it is better to create a small wrapper member function to erase BB. |
test/Transforms/JumpThreading/dangling-pointers-in-bpi.ll | ||
1 ↗ | (On Diff #60360) | What does this test do? THere is no check string? |
This change was reverted due to the failing AssertingVH on some of the buildbots. Looked very much like a problem described in llvm-dev thread "Should analyses be able to hold AssertingVH to IR? (related to PR28400)". I bypassed this issue by using CallbackVH instead of AssertingVH and resubmitted (r275563).