# \[RFC\] Unify the semantics of program points

**URL:** https://discourse.llvm.org/t/rfc-unify-the-semantics-of-program-points/80671
**Category:** MLIR
**Tags:** mlir
**Created:** [August 12, 2024, 11:24am UTC](https://discourse.llvm.org/t/rfc-unify-the-semantics-of-program-points/80671 "2024-08-12T11:24:08Z")
**Posts on this page:** 1
**Showing post:** 8

<div class="post-metadata">

### Author: ![cxy](https://sea1.discourse-cdn.com/flex021/user_avatar/discourse.llvm.org/cxy/32/21266_2.png) [@cxy](https://discourse.llvm.org/u/cxy)
#### Post date: [August 21, 2024, 2:38am UTC](https://discourse.llvm.org/t/rfc-unify-the-semantics-of-program-points/80671/8 "2024-08-21T02:38:22Z")

</div>

> [@ftynse](#):
>
> Could you elaborate on what you propose by “instead of requiring the input of the visit function to be only “program points” of block and op types.”? I see this in sparse analyses:

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:

> <https://github.com/llvm/llvm-project/blob/12d4c89e88bf9349a063fdd992233b29adeb8241/mlir/lib/Analysis/DataFlow/DenseAnalysis.cpp#L53>

Here is the sparse check:

> <https://github.com/llvm/llvm-project/blob/12d4c89e88bf9349a063fdd992233b29adeb8241/mlir/lib/Analysis/DataFlow/SparseAnalysis.cpp#L92>

Here is the check in DeadCodeAnalysis:

> <https://github.com/llvm/llvm-project/blob/12d4c89e88bf9349a063fdd992233b29adeb8241/mlir/lib/Analysis/DataFlow/DeadCodeAnalysis.cpp#L239>

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.

---

_[View the full topic](https://discourse.llvm.org/t/rfc-unify-the-semantics-of-program-points/80671)._