[all-commits] [llvm/llvm-project] 4b3f25: [mlir] [dataflow] unify semantics of program point...

[donald chen via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 4b3f251bada55cfc20a2c72321fa0bbfd7a759d5
      https://github.com/llvm/llvm-project/commit/4b3f251bada55cfc20a2c72321fa0bbfd7a759d5
  Author: donald chen <chenxunyu1993 at gmail.com>
  Date:   2024-10-11 (Fri, 11 Oct 2024)

  Changed paths:
    M flang/lib/Optimizer/Transforms/StackArrays.cpp
    M mlir/include/mlir/Analysis/DataFlow/DeadCodeAnalysis.h
    M mlir/include/mlir/Analysis/DataFlow/DenseAnalysis.h
    M mlir/include/mlir/Analysis/DataFlow/SparseAnalysis.h
    M mlir/include/mlir/Analysis/DataFlowFramework.h
    M mlir/include/mlir/IR/Block.h
    M mlir/lib/Analysis/DataFlow/DeadCodeAnalysis.cpp
    M mlir/lib/Analysis/DataFlow/DenseAnalysis.cpp
    M mlir/lib/Analysis/DataFlow/IntegerRangeAnalysis.cpp
    M mlir/lib/Analysis/DataFlow/LivenessAnalysis.cpp
    M mlir/lib/Analysis/DataFlow/SparseAnalysis.cpp
    M mlir/lib/Analysis/DataFlowFramework.cpp
    M mlir/lib/Dialect/Arith/Transforms/IntRangeOptimizations.cpp
    M mlir/test/lib/Analysis/DataFlow/TestDeadCodeAnalysis.cpp
    M mlir/test/lib/Analysis/DataFlow/TestDenseBackwardDataFlowAnalysis.cpp
    M mlir/test/lib/Analysis/DataFlow/TestDenseForwardDataFlowAnalysis.cpp
    M mlir/test/lib/Analysis/DataFlow/TestSparseBackwardDataFlowAnalysis.cpp
    M mlir/test/lib/Analysis/TestDataFlowFramework.cpp

  Log Message:
  -----------
  [mlir] [dataflow] unify semantics of program point (#110344)

The concept of a 'program point' in the original data flow framework is
ambiguous. It can refer to either an operation or a block itself. This
representation has different interpretations in forward and backward
data-flow analysis. In forward data-flow analysis, the program point of
an operation represents the state after the operation, while in backward
data flow analysis, it represents the state before the operation. When
using forward or backward data-flow analysis, it is crucial to carefully
handle this distinction to ensure correctness.

This patch refactors the definition of program point, unifying the
interpretation of program points in both forward and backward data-flow
analysis.

How to integrate this patch?

For dense forward data-flow analysis and other analysis (except dense
backward data-flow analysis), the program point corresponding to the
original operation can be obtained by `getProgramPointAfter(op)`, and
the program point corresponding to the original block can be obtained by
`getProgramPointBefore(block)`.

For dense backward data-flow analysis, the program point corresponding
to the original operation can be obtained by
`getProgramPointBefore(op)`, and the program point corresponding to the
original block can be obtained by `getProgramPointAfter(block)`.

NOTE: If you need to get the lattice of other data-flow analyses in
dense backward data-flow analysis, you should still use the dense
forward data-flow approach. For example, to get the Executable state of
a block in dense backward data-flow analysis and add the dependency of
the current operation, you should write:

``getOrCreateFor<Executable>(getProgramPointBefore(op),
getProgramPointBefore(block))``

In case above, we use getProgramPointBefore(op) because the analysis we
rely on is dense backward data-flow, and we use
getProgramPointBefore(block) because the lattice we query is the result
of a non-dense backward data flow computation.

related dsscussion:
https://discourse.llvm.org/t/rfc-unify-the-semantics-of-program-points/80671/8
corresponding PSA:
https://discourse.llvm.org/t/psa-program-point-semantics-change/81479



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications