This is an archive of the discontinued LLVM Phabricator instance.

[Local] Fix removeUnreachableBlocks change reporting
AbandonedPublic

Authored by jroelofs on Jul 15 2020, 2:29 PM.

Details

Reviewers
fhahn
Summary

I believe this might be the cause of the assertion failures in the EXPENSIVE_CHECKS bot on GreenDragon. See build #16770. I can't reproduce that failure myself, but this ought to be more precise, even if it's not what's triggering that particular issue.

Diff Detail

Event Timeline

jroelofs created this revision.Jul 15 2020, 2:29 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 15 2020, 2:29 PM
fhahn added a comment.Jul 16 2020, 6:21 AM

I think it would be great if we would have a reproducer to see exactly what's going on.

If the block is already set for deletion, whoever added it should take care of dropping references & co and there should be nothing to do for us here.

So it might be more straight forward to not include blocks already pending deletion in DeadBlockSet. That way, we could have an early bail out if the deadblockset is empty. Otherwise we know we are going to make changes (mark a new block for deletion at least) and we can always return true at that point I think.

Technically, the function might not actually delete any blocks there and then, but the blocks marked for deletion here will eventually be deleted (Once the DTU flushes the updates).

jroelofs abandoned this revision.Jul 16 2020, 9:29 AM

I found a way to repro it, and this patch doesn't have an effect on it.

fhahn added a comment.Jul 16 2020, 9:31 AM

I found a way to repro it, and this patch doesn't have an effect on it.

Great, thanks for confirming. As mentioned earlier, we shouldn't have to make any changes for blocks already marked as deleted. It still might be worthwhile to simplify the code as suggested.