[PATCH] D127874: [analyzer] Reimplement UnreachableCodeChecker using worklists

Thu Jun 16 06:30:30 PDT 2022

martong added a comment.

> If some checker placed a sink node into some block, the successors of the sink block was marked unreachable previously. This leads to an unpleasant situation from the user's point of view since a different bugreport gets correlated with the FPs caused by the sink node of that. This effectively means that for each unconditional sink, we will also have (preferable) an unreachable code report as well.

An example and/or a visualization would be useful for this.

> Now, we ignore unreachable nodes if the predecessor is reachable, but none of its successors are.

Isn't there a contradiction here? The node's predecessor must have at least one reachable successor, the node itself; otherwise the node itself would be unreachable.

> the sweep-back part cannot be implemented correctly via a DFS visitation

What is the purpose of this sweep-back? You should summarize that here.

> ... Do a backward DFS to find the start of each unreachable CFG block chain ...

How does it find the //start// if there is a cycle in the graph? Isn't it rather about finding strongly connected components?

> The sweep-back part cannot be implemented correctly via a DFS visitation ... Why do we need to do the sweep-back part in BFS order?

Connected components can be found by both DFS or BFS. Please elaborate why should we prefer BFS? The problem you are trying to solve seems to be an unnecessarily convoluted problem to me. Shouldn't it be enough to simply pick one node (or all of them) from the connected component? It should not matter if we use DFS or BFS for finding the nodes in a connected component.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D127874/new/

https://reviews.llvm.org/D127874