[all-commits] [llvm/llvm-project] 1e7a6c: [mlir][linalg] Add getIteratorTypesArray to Linalg...

[Oleg Shyshkov via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1e7a6c0874f57014132b857b2d201d6aaa75feee
      https://github.com/llvm/llvm-project/commit/1e7a6c0874f57014132b857b2d201d6aaa75feee
  Author: Oleg Shyshkov <shyshkov at google.com>
  Date:   2022-09-27 (Tue, 27 Sep 2022)

  Changed paths:
    M mlir/include/mlir/Dialect/Linalg/IR/LinalgInterfaces.td
    M mlir/lib/Dialect/Linalg/IR/LinalgInterfaces.cpp
    M mlir/lib/Dialect/Linalg/Transforms/DropUnitDims.cpp
    M mlir/lib/Dialect/Linalg/Transforms/ElementwiseOpFusion.cpp
    M mlir/lib/Dialect/Linalg/Transforms/Generalization.cpp
    M mlir/lib/Dialect/Linalg/Transforms/InlineScalarOperands.cpp

  Log Message:
  -----------
  [mlir][linalg] Add getIteratorTypesArray to LinalgInterface.

Summary:
Most of the code that gets `iterator_types` from LinalgInterface is forced to
extract values from an `Attribute`. As a result, the usage pattern looks like
this:

```
SmallVector<StringRef> iterators = llvm::to_vector<4>(linalgOp.iterator_types().getAsValueRange<StringAttr>());
```

It also forces all operations that implement LinalgOp interface to have
`iterator_types` attribute even when the information can be easily infered from
other parameters.

In perfect future, `getIteratorTypeArray` should be the only method to get
iterator types from the interface. The default implementation can rely on
`iterator_types` attribute though.

The name `getIteratorTypeArray` was picked to be consistent with existing
`getIndexingMapsArray`.

This patch add a few sample usages. More cleanups will follow.

Differential Revision: https://reviews.llvm.org/D134729