[all-commits] [llvm/llvm-project] 6aeea7: [mlir][dataflow] Fix for integer range analysis pr...

[Spenser Bauman via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 6aeea700df6f3f8db9e6a79be4aa593c6fcc7d18
      https://github.com/llvm/llvm-project/commit/6aeea700df6f3f8db9e6a79be4aa593c6fcc7d18
  Author: Spenser Bauman <sbauman at mathworks.com>
  Date:   2024-05-28 (Tue, 28 May 2024)

  Changed paths:
    M mlir/include/mlir/Analysis/DataFlow/IntegerRangeAnalysis.h
    M mlir/include/mlir/Dialect/Arith/IR/ArithOps.td
    M mlir/include/mlir/Dialect/GPU/IR/GPUOps.td
    M mlir/include/mlir/Dialect/Index/IR/IndexOps.td
    M mlir/include/mlir/Interfaces/InferIntRangeInterface.h
    M mlir/include/mlir/Interfaces/InferIntRangeInterface.td
    M mlir/include/mlir/Interfaces/Utils/InferIntRangeCommon.h
    M mlir/lib/Analysis/DataFlow/IntegerRangeAnalysis.cpp
    M mlir/lib/Dialect/Arith/IR/InferIntRangeInterfaceImpls.cpp
    M mlir/lib/Interfaces/InferIntRangeInterface.cpp
    M mlir/lib/Interfaces/Utils/InferIntRangeCommon.cpp
    M mlir/test/Dialect/Arith/int-range-interface.mlir
    M mlir/test/lib/Dialect/Test/TestOps.td

  Log Message:
  -----------
  [mlir][dataflow] Fix for integer range analysis propagation bug (#93199)

Integer range analysis will not update the range of an operation when
any of the inferred input lattices are uninitialized. In the current
behavior, all lattice values for non integer types are uninitialized.

For operations like arith.cmpf

```mlir
%3 = arith.cmpf ugt, %arg0, %arg1 : f32
```

that will result in the range of the output also being uninitialized,
and so on for any consumer of the arith.cmpf result. When control-flow
ops are involved, the lack of propagation results in incorrect ranges,
as the back edges for loop carried values are not properly joined with
the definitions from the body region.

For example, an scf.while loop whose body region produces a value that
is in a dataflow relationship with some floating-point values through an
arith.cmpf operation:

```mlir
func.func @test_bad_range(%arg0: f32, %arg1: f32) -> (index, index) {
  %c4 = arith.constant 4 : index
  %c1 = arith.constant 1 : index
  %c0 = arith.constant 0 : index

  %3 = arith.cmpf ugt, %arg0, %arg1 : f32

  %1:2 = scf.while (%arg2 = %c0, %arg3 = %c0) : (index, index) -> (index, index) {
    %2 = arith.cmpi ult, %arg2, %c4 : index
    scf.condition(%2) %arg2, %arg3 : index, index
  } do {
  ^bb0(%arg2: index, %arg3: index):
    %4 = arith.select %3, %arg3, %arg3 : index
    %5 = arith.addi %arg2, %c1 : index
    scf.yield %5, %4 : index, index
  }

  return %1#0, %1#1 : index, index
}
```

The existing behavior results in the control condition %2 being
optimized to true, turning the while loop into an infinite loop. The
update to %arg2 through the body region is never factored into the range
calculation, as the ranges for the body ops all test as uninitialized.

This change causes all values initialized with setToEntryState to be set
to some initialized range, even if the values are not integers.

---------

Co-authored-by: Spenser Bauman <sabauma at fastmail>



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