[Mlir-commits] [mlir] [mlir] [dataflow] Refactoring the definition of program points in dat… (PR #105656)

[Rob Suderman]

rsuderman wrote:

So I believe we will want to revert this and reland in the future with changes.

The main issue is the changes to `ProgramPoint`. Where previously we allowed it to be an old ProgramPoint (now LatticeAnchor) it now assumes that the location is an operation or block. However the `torch-mlir` pass uses symnames instead to check for cases. Other frameworks do similar cases of `symnames` for referencing a shared handle not mapped to any particular operation. Likely the right choice is to remove `ProgramPoint` and have the dependent location be some type of LatticeAnchor or generalized type rather than hardcoding to an `Operation*` or `Block*`. If we don't want to assume the same type as `LatticeAnchor` we can create a similar generic for storing the program point used to visit.

In short, this actually removes some functionality that would require completely reworking downstream analysis passes to correct without there being a clear benefit in imposing this new restriction.

https://github.com/llvm/llvm-project/pull/105656