This mirrors the existing pattern for pushing unpack down through
padding, restricting to cases where the padded dimensions aren't tiled
by the pack.
Additionally reformats the propagation test to make it easier to read.
The MLIR classes Type/Attribute/Operation/Op/Value support
cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast
functionality in addition to defining methods with the same name.
This change begins the migration of uses of the method to the
corresponding function call as has been decided as more consistent.
Note that there still exist classes that only define methods directly,
such as AffineExpr, and this does not include work currently to support
a functional cast/isa call.
Caveats include:
- This clang-tidy script probably has more problems.
- This only touches C++ code, so nothing that is being generated.
Context:
- https://mlir.llvm.org/deprecation/ at "Use the free function variants
for dyn_cast/cast/isa/…"
- Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443
Implementation:
This first patch was created with the following steps. The intention is
to only do automated changes at first, so I waste less time if it's
reverted, and so the first mass change is more clear as an example to
other teams that will need to follow similar steps.
Steps are described per line, as comments are removed by git:
0. Retrieve the change from the following to build clang-tidy with an
additional check:
https://github.com/llvm/llvm-project/compare/main...tpopp:llvm-project:tidy-cast-check
1. Build clang-tidy
2. Run clang-tidy over your entire codebase while disabling all checks
and enabling the one relevant one. Run on all header files also.
3. Delete .inc files that were also modified, so the next build rebuilds
them to a pure state.
4. Some changes have been deleted for the following reasons:
- Some files had a variable also named cast
- Some files had not included a header file that defines the cast
functions
- Some files are definitions of the classes that have the casting
methods, so the code still refers to the method instead of the
function without adding a prefix or removing the method declaration
at the same time.
```
ninja -C $BUILD_DIR clang-tidy
run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\
-header-filter=mlir/ mlir/* -fix
rm -rf $BUILD_DIR/tools/mlir/**/*.inc
git restore mlir/lib/IR mlir/lib/Dialect/DLTI/DLTI.cpp\
mlir/lib/Dialect/Complex/IR/ComplexDialect.cpp\
mlir/lib/**/IR/\
mlir/lib/Dialect/SparseTensor/Transforms/SparseVectorization.cpp\
mlir/lib/Dialect/Vector/Transforms/LowerVectorMultiReduction.cpp\
mlir/test/lib/Dialect/Test/TestTypes.cpp\
mlir/test/lib/Dialect/Transform/TestTransformDialectExtension.cpp\
mlir/test/lib/Dialect/Test/TestAttributes.cpp\
mlir/unittests/TableGen/EnumsGenTest.cpp\
mlir/test/python/lib/PythonTestCAPI.cpp\
mlir/include/mlir/IR/
```
Differential Revision: https://reviews.llvm.org/D150123
Commit b4563ee17ce45728a323c2708e549627b0a8ee9c enabled propagation for
pack and unpack through non-elementwise operations, update comments and
methods names to reflect the changes made.
Rework some tests where the `linalg.generic` was reading from
`tensor.empty`, which is undefined behaviour.
Reviewed By: hanchung, qedawkins
Differential Revision: https://reviews.llvm.org/D149952
In `bubbleUpPackOpThroughGenericOp`, we replaced the init operands with
a new `tensor.empty` if the operation was a pure element-wise op. This
behaviour is not wrong but not ideal because we "break" the original
use-def-chain of the output operand by materializing a new
`tensor.empty`. We should use `tensor.empty` as a destination *only* if the
initial init operand was already a `tensor.empty`, as we do in
`PushDownUnpack`.
Reviewed By: hanchung
Differential Revision: https://reviews.llvm.org/D149250
Allows pack propagation through non-elementwise generics as long as all
tiled dimensions have parallel iterator types and are only indexed with
affine dim expressions by any of the operands.
This enables unpack propagation cases where the result type is different
from the current unpack destination tensor and thus motivates a similar
helper as the for pack for creating a destination tensor based on
pack information.
Outer dim permutations are allowed to permute reduction dims, however
remains unsupported for non-affine dim indexing map results.
Additionally ops with gather semantics now explicitly prohibit propagation.
Pack/unpack propagation through reductions may not always be beneficial
so user control over propagation decisions is made available through
a control function similar to the one for fusion.
Differential Revision: https://reviews.llvm.org/D147508
`isScalar` only returns true if the operand is non-shaped.
But we need to handle also rank zero tensors.
Reviewed By: hanchung
Differential Revision: https://reviews.llvm.org/D144989
Currently, the insertion point for `bubbleUpPackOpThroughElemGenericOp`
is after the tensor.pack this means that the new generic will be created
right after the tensor.pack. This is inconvenient because we are moving
the position of the generic; the idea is to move pack/unpack around, not
linalg.generics. This PR changes the insertion point to preserve the
position of the generic.
Additionally, it restricts the pattern to fire if the generic has a
single user (`tensor.pack`) to avoid introducing recomputation.
Reviewed By: hanchung
Differential Revision: https://reviews.llvm.org/D144246
The pack/unpack propagation patterns currently assume all map results
for non-scalar arguments are AffineDimExprs, leading to crashes when the
input operand being packed has constant expressions.
Differential Revision: https://reviews.llvm.org/D144443
When propagating tensor.unpack ops through elementwise generics, a new
output tensor is needed if the element type of the input differs from
that of the output in the elementwise op.
Differential Revision: https://reviews.llvm.org/D144438
Introduce a pattern to 'push down' a `tensor.unpack` through a
`tensor.pad`. The propagation happens if the unpack does not touch the
padded dimensions.
Reviewed By: hanchung
Differential Revision: https://reviews.llvm.org/D143907
Introduce `pushDownUnPackOpThroughElemGenericOp` to propagate producer
unpack operation through an element-wise linalg.generic operation. This
pattern complements `BubbleUpPackOpThroughElemGenericOp`. The general
idea is to bubble up tensor.pack as much as possible while pushing down
tensor.unpack as much as possible, and canonicalize away symmetrical
tensor.pack and tensor.unpack operations.
Currently, `pushDownUnPackOpThroughElemGenericOp` expects a single
tensor.unpack operation as the producer of one of the linalg.generic's
operands.
Reviewed By: hanchung
Differential Revision: https://reviews.llvm.org/D142523
Pass to `getPackingInfoFromConsumer` the tensor.pack op instead of all
the arguments derived from it. Additionally, remove the padding from the
struct, as we currently don't handle propagation when `tensor.pack`
requires padding. We will add back the field when we will need it.
Reviewed By: hanchung
Differential Revision: https://reviews.llvm.org/D141837
Instead of folding the transpose into the linalg.generic keep the
transposition in the packing operation, effectively making the
linalg.generic transparent to the propagation. Additionally, if the init
operand of the generic has users pack the init and pass it as the
operand to the generic.
Reviewed By: hanchung
Differential Revision: https://reviews.llvm.org/D141483
std::optional::value() has undesired exception checking semantics and is
unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The
call sites block std::optional migration.
This patch fixes:
mlir/lib/Dialect/Linalg/Transforms/DataLayoutPropagation.cpp:52:42:
error: 'None' is deprecated: Use std::nullopt
instead. [-Werror,-Wdeprecated-declarations]
Considering the case that generic + pack (with outer_dim_perms), the
truth is that it is equipvelent to generic + pack + transpose. There are
two steps to bubble up the pack op accross the generic op.
Step 1. swap generic + pack -> pack + generic.
In this step, we can bind the packing information to dimensions of
iteration domain. With the information, we can pack the operands with
corresponding data tile sizes; the packed inner dimensions will be
appended to the indexing_maps. Note that the outer dimensions of
indexing maps are not changed at all.
Step 2. Fold the transpose into generic op.
The step two is just updating the indexing map, so we do not have to
handle outer_dim_perms anymore.
There could be step 3 to extract the transpose op out (i.e., generic ->
transpose + generic), then we can fold the transpose into the pack op.
This step is not done in the revision.
Co-authored-by: Lorenzo Chelini <l.chelini@icloud.com>
Reviewed By: chelini
Differential Revision: https://reviews.llvm.org/D139680
It introduces a pattern that swaps `linalg.generic + tensor.pack` to
`tensor.pack + linalg.generic`. It requires all the iteration types
being parallel; the indexing map of output operand is identiy. They can
all be relaxed in the future.
The user can decide whether the propagation should be applied or not by
passing a control function.
Reviewed By: mravishankar
Differential Revision: https://reviews.llvm.org/D138882
