When transferring affected values in the cache from an old value, identified by the value of the current callback, to the specified new value we might need to insert a new entry into the DenseMap which constitutes the cache. Doing so might delete the current callback object. Move the copying logic into a new function, a member of the assumption cache itself, so that we don't run into UB should the callback handle itself be removed mid-copy.
Details
Details
- Reviewers
dim chandlerc sanjoy - Commits
- rG481bb24909f3: Merging r292133: --------------------------------------------------------------…
rGc29d5f167446: Fix use-after-free bug in AffectedValueCallbackVH::allUsesReplacedWith
rL292312: Merging r292133:
rL292133: Fix use-after-free bug in AffectedValueCallbackVH::allUsesReplacedWith
Diff Detail
Diff Detail
- Repository
- rL LLVM
Event Timeline
Comment Actions
The code lgtm, but
- Can you easily test this using a C++ unit test? I'll settle for something that normally runs "fine", but trips asan if the build is using asan.
- getAffectedValues should be renamed to getOrInsertAffectedValues.
lib/Analysis/AssumptionCache.cpp | ||
---|---|---|
121 ↗ | (On Diff #84505) | Can you use llvm::find here (in a later change)? |
132 ↗ | (On Diff #84505) | Please add why it may dangle. |
Comment Actions
I'll experiment with this today and commit one in follow-up. I might also be able to create an IR test case for instcombine if things work out just right.
- getAffectedValues should be renamed to getOrInsertAffectedValues.
Sure.
lib/Analysis/AssumptionCache.cpp | ||
---|---|---|
121 ↗ | (On Diff #84505) | Yes, I think so. I'd forgotten about that. |