Certainly. The visit function in DataFlowAnalysis takes a program point as its argument. This function is invoked during initialization or when iterating to a fixed point. Each time it’s called, its semantics involve visiting a program point and updating the lattice based on the semantics of the program point (connection of blocks or content of operations). It then wakes up dependent nodes, triggering subsequent calls to visit . Importantly, both the argument to visit and the awakened dependencies can only be program points, not lattice anchors.
Therefore, within the program, we’ll check that the program point in the visit function is either an operation or a block:
Here is the dense check:
Here is the sparse check:
Here is the check in DeadCodeAnalysis:
The reason for these checks is precisely because we haven’t made a clear distinction between program points and lattice anchors.
In summary, I don’t think this is just a name change. What we are doing is separating the concepts of lattice anchor and program point. A lattice anchor can be a program point or something else (value, CFGEdge), representing the point where a lattice can be attached, while a program point strictly represents a point in the program execution.
The parameter of the visit function in data flow analysis and DataFlowSolver::workItem should both continue to use program points, while functions related to lattices should be replaced with lattice anchors. By doing this, we can eliminate the aforementioned failures.