[Linalg][Canonicalization] Add Tensor -> Scalar Pattern

[chrsmcgrr]

There are many other patterns and checks within Linalg that define a
scalar to be a single value that is not a single element tensor type.

This blocks certain transforms (LinalgSpecialization) and checks.

Take for example the following:

module {
  func.func public @main() -> tensor<32x256xf32> {
    %cst = arith.constant dense<0.58510226> : tensor<1xf32>
    %0 = tensor.empty() : tensor<32x256xf32>
    %1 = linalg.generic {indexing_maps = [#map, #map1], iterator_types = ["parallel", "parallel"]} ins(%cst : tensor<1xf32>) outs(%0 : tensor<32x256xf32>) {
    ^bb0(%in: f32, %out: f32):
      linalg.yield %in : f32
    } -> tensor<32x256xf32>
    func.return %1 : tensor<32x256xf32>
  }
}

The generic in question performs a broadcast from a scalar to a tensor.
However, the transforms and checks that identifies this oepration as a
FillOp do not trigger because the definition of a scalar at the input
is one that is not a RankedTensor, rather a single value.

The following change attempts to reconcile this discrepancy by
converting any known operand on a generic to a true scalar. Resulting
in the following:

module {
  func.func public @main() -> tensor<32x256xf32> {
    %cst = arith.constant 0.58510226 : f32
    %0 = tensor.empty() : tensor<32x256xf32>
    %1 = linalg.generic {indexing_maps = [#map, #map1], iterator_types = ["parallel", "parallel"]} ins(%cst : f32) outs(%0 : tensor<32x256xf32>) {
    ^bb0(%in: f32, %out: f32):
      linalg.yield %in : f32
    } -> tensor<32x256xf32>
    func.return %1 : tensor<32x256xf32>
  }
}

[chrsmcgrr]

• fix: DecomposeGenericByUnfoldingPermutation pass #12
• [Linalg][Canonicalization] Add Tensor -> Scalar Pattern #11 👈 (View in Graphite)
• integrate-llvm-project-20250508

This stack of pull requests is managed by Graphite. Learn more about stacking.

[chrsmcgrr]

Opting for another solution.