This prevents against assertion errors like PR32659 which occur from a
replacement deleting a node after it's been added to the list argument
of RemoveDeadNodes.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
The code change seems safe, but the test doesn't fail with recent trunk (I tried r304685).
Is there still a way to expose the bug? If not, can we just assert that no deleted node can get this far?
Is there still a way to expose the bug?
I'm reasonably there's a sequence that could trigger the bug in some backend, but I don't think I can generate it. The failing test was dealing with a net of TokenFactors fusedin a single instruction which wasn't being simplified.
If not, can we just assert that no deleted node can get this far?
Unfortunately no. The original bug is that we're triggering on a deleted_node a bit further down in deallocation. the caller of the changed function is builds up a list of nodes to delete after having moved some of the the users of the added nodes' values. But it's possible that moving those values will cause a previously added node to be deleted. I could filter the node vector on the caller side and prune there, but that's just a un-loopfused version of this.