If we replace an llvm.assume with another one and we have an active
assumption cache, we might end up with an llvm.assume in the cache
twice, breaking an invariant. Avoid this by unregistering the assumption
when necessary.
Details
- Reviewers
jonpa spatel jmolloy lebedev.ri bollu
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
Can you explain why this requires manual handling, and is not handled by the ValueHandle RAUW logic in AC?
Good point. The current value handle RAUW logic is only dealing with affected values, the idea is still valid.
I could replace the
struct ResultElem { WeakTrackingVH Assume;
with a CallbackVH to deal with this.
I'll try it out, thought's welcome.
@nikic Using CallbackVH for the llvm.assume in the Cache is not as simple as I thought. I will do it but it changes the data structures a bit, unsure how that will impact compile time.
llvm/lib/Transforms/Scalar/GVNSink.cpp | ||
---|---|---|
884 | Okay, I think now I get it. The problem is that we use a WeakTrackingVH, which means that it will follow RAUW, and we do multiple replacements to the same assume. This makes me wonder though: Can't we just replace the WeakTrackingVH with a WeakVH? Doing RAUW on assumes is not really meaningful because the instruction has no return value. I believe it's fine to just ignore RAUW by using WeakVH, and then in this case, the old assumes would get nulled out by the eraseFromParent below. |
llvm/lib/Transforms/Scalar/GVNSink.cpp | ||
---|---|---|
884 | Trying that now. Avoiding dangling references is still kinda nice but I'm OK with a minimal fix as well. Either way. |
@nikic This is where one assume is replaced with another, e.g., in the attached test.