…or and optional block arguments
This change extends the TOSA `cond_if` operation's print and parse logic
to handle the following:
- The condition operand may now have any rank, as long as the total
number of elements sums to 1.
%1 = tosa.cond_if %0 : tensor<1x1x1xi1> -> tensor<4xf32>
- The `then` and `else` regions can now include optional block
arguments. The updated IR syntax reflects this:
%1 = tosa.cond_if %0 (%arg2 = %arg0, %arg3 = %arg1) : tensor<i1>
(tensor<4xf32>, tensor<4xf32>) -> tensor<4xf32>
- Removed parentheses around single result types in the printed
representation, aligning with the `AsmPrinter` conventions.
Co-authored-by: Luke Hutton <luke.hutton@arm.com>
Supports the case where the sizes of the subview op is dynamic.When
there are more for loops in the tile algorithm, multiple subviews are
performed and test-compose-subview does not work when the size operand
of the subview ops is dynamic value.
This is a nomination for the maintainers of the egress category within
MLIR as proposed in
https://discourse.llvm.org/t/mlir-project-maintainers/87189. As agreed
in the Project Council meeting on July 17, we are proceeding with
category nominations without waiting for lead maintainers to be
nominated.
This is a nomination for the maintainers of the tensor compiler category
within MLIR as proposed in
https://discourse.llvm.org/t/mlir-project-maintainers/87189. As agreed
in the Project Council meeting on July 17, we are proceeding with
category nominations without waiting for lead maintainers to be
nominated.
In https://github.com/llvm/llvm-project/pull/149156, I ensured that we
no longer generate spurious `tensor.empty` ops when vectorizing
`linalg.unpack`.
This follow-up removes leftover code that is now redundant but was
missed in the original PR.
This is a nomination for the maintainers of the core category within
MLIR as proposed in
https://discourse.llvm.org/t/mlir-project-maintainers/87189. As agreed
in the Project Council meeting on July 17, we are proceeding with
category nominations without waiting for lead maintainers to be
nominated.
With LDBG(), the code isn't guarded in release mode, even if the optimizer
will remove it because there is a `if (false)` statement. We need the
function declaration to be there at minima.
The Toy tutorial used outdated API. Update the example to:
* Use the `OpAdaptor` in all places.
* Do not mix `RewritePattern` and `ConversionPattern`. This cannot
always be done safely and should not be advertised in the example code.
Reverts llvm/llvm-project#147950
I noticed some fails in the reduction tests with clang after this
change. I need to understand the failures better. Reverting this for
now.
Operation folders can do two things:
1. Modify IR (in-place op modification). Failing to legalize an in-place
folded operation does not trigger an immediate rollback. This happens
only if the driver decides to try a different lowering path, requiring
it to roll back a bunch of modifications, including the application of
the folder.
2. Create new IR (constant op materialization of a folded attribute).
Failing to legalize a newly created constant op triggers an immediate
rollback.
In-place op modifications should be guarded by
`startOpModification`/`finalizeOpModification` because they are no
different from other in-place op modifications. (They just happen
outside of a pattern, but that does not mean that we should not track
those changes; we are tracking everything else.) This commit adds those
two function calls.
This commit also moves the `rewriter.replaceOp(op, replacementValues);`
function call before the loop nest that legalizes the newly created
constant ops (and therefore `replacementValues`). Conceptually, the
folded op must be replaced before attempting to legalize the constants
because the constant ops may themselves be replaced as part of their own
legalization process. The previous implementation happened to work in
the current conversion driver, but is incompatible with the One-Shot
Dialect Conversion driver, which expects to see the most recent IR at
all time.
From an end-user perspective, this commit should be NFC. A common
folder-rollback pattern that is exercised by multiple tests cases: A
`memref.dim` is folded to `arith.constant`, but `arith.constant` is not
marked as legal as per the conversion target, triggering a rollback.
Note: Folding is generally unsafe in a dialect conversion (see #92683),
but that's a different issue. (In a One-Shot Dialect Conversion, it will
no longer be unsafe.)
Erasing the operation to which the current insertion point is set,
leaves the insertion point in an invalid state. This commit resets the
insertion point to the following operation.
Also adjust the insertion point when inlining a block.
This commit makes some minor NFC-style improvements to the
`notifyBlockInserted` and `notifyOperationInserted` implementations:
* Rename some variables.
* Add more comments and document the fact the current mechanism has a
bug when running in "rollback allowed" mode.
* Move some code from the `notify...` functions into the constructor of
the respective `IRRewrite` objects. This is in preparation of the
One-Shot Dialect Conversion refactoring. The moved pieces of code are
not needed in "no rollback" mode and properly encapsulated inside of
`IRRewrite`, which is also not needed in "no rollback" mode.
* Slightly improve `-debug` output.
Add a new "expensive check" when running with `allowPatternRollback =
false`: returning "failure" after modifying IR is no longer allowed.
This check detects a few more API violations in addition to the check
`undoRewrites`. The latter check will be removed soon. (Because the
One-Shot Dialect Conversion will no longer maintain the stack of IR
rewrites.)
Also fix a build error when expensive checks are enabled.
Add `lookupOrDefault` / `lookupOrNull` wrappers to
`ConversionPatternRewriterImpl` and call those wrappers throughout the
code base.
This commit is in preparation of the One-Shot Dialect Conversion
refactoring. In future, the implementation will bypass the `mapping`
when rollback is disabled. The switch will be made in those wrapper
functions.
Do not access the erased `scf.while` operation in the lowering pattern.
That won't work anymore in a One-Shot Dialect Conversion and triggers a
use-after-free sanitizer error.
After the One-Shot Dialect Conversion refactoring, a
`ConversionPatternRewriter` will behave more like a normal
`PatternRewriter`.
Fixed some bugs in documentation. Add CallOpInterfaceHandle to the
arguments of ChangeCallTargetOp, after doing so the section described in
the documentation works correctly, Otherwise the following code reports
an error.
```
// Cast to our new type.
%casted = transform.cast %call : !transform.any_op to !transform.my.call_op_interface
// Using our new operation.
transform.my.change_call_target %casted, "microkernel" : !transform.my.call_op_interface
```
%T has been deprecated for about seven years and is to be avoided given
it does not use a unique dir per test. Remove it from lit tests in MLIR
with the eventual goal to be removing support within llvm-lit.
This patch just reuses %t.o given it is deleted in between sections of
the test.
DEBUGLOG_WITH_STREAM_AND_TYPE is an internal implementation detail of
LDBG in DebugLog.h. When NDEBUG is defined,
DEBUGLOG_WITH_STREAM_AND_TYPE is not defined at all.
Signed-off-by: Benoit Jacob <jacob.benoit.1@gmail.com>
This patch removes spurious includes of `llvm/IR` files, and unnecessary
link components in the LLVM dialect.
The only major dependencies still coming from LLVM are
`llvm::DataLayout`, which is used by `verifyDataLayoutString` and some
`dwarf` symbols in some attributes. Both of them should likely be
removed in the future.
Finally, I also removed one constructor from `LLVM::AssumeOp` that used
[OperandBundleDefT](https://llvm.org/doxygen/classllvm_1_1OperandBundleDefT.html)
without good reason and introduced a header unnecessarily.
The revision restrict the `linalg.pack` op to not have artificial
padding semantics. E.g., the below is valid without the change, and it
becomes invalid with the change.
```mlir
func.func @foo(%src: tensor<9xf32>) -> tensor<100x8xf32> {
%cst = arith.constant 0.000000e+00 : f32
%dest = tensor.empty() : tensor<100x8xf32>
%pack = linalg.pack %src
padding_value(%cst : f32)
inner_dims_pos = [0]
inner_tiles = [8] into %dest
: tensor<9xf32> -> tensor<100x8xf32>
return %pack : tensor<100x8xf32>
}
```
IMO, it is a misuse if we use pack ops with artificial padding sizes
because the intention of the pack op is to relayout the source based on
target intrinsics, etc. The output shape is expected to be
`tensor<2x8xf32>`. If people need extra padding sizes, they can create a
new pad op followed by the pack op.
This also makes consumer tiling much easier because the consumer fusion
does not support artificial padding sizes. It is very hard to make it
work without using ad-hoc patterns because the tiling sizes are about
source, which implies that you don't have a core_id/thread_id to write
padding values to the whole tile.
People may have a question how why pad tiling implementation works. The
answer is that it creates an `if-else` branch to handle the case. In my
experience, it is very struggle in transformation because most of the
time people only need one side of the branch given that the tile sizes
are usually greater than padding sizes. However, the implementation is
conservatively correct in terms of semantics. Given that the
introduction of `pack` op is to serve the relayout needs better, having
the restriction makes sense to me.
Removed tests:
-
`no_bubble_up_pack_extending_dimension_through_expand_cannot_reassociate`
from `data-layout-propagation.mlir`: it is a dup test to
`bubble_up_pack_non_expanded_dims_through_expand` after we fix the
shape.
- `fuse_pack_consumer_with_untiled_extra_padding` from
`tile-and-fuse-consumer.mlir`: it was created for artificial padding in
the consumer fusion implementation.
The other changes in lit tests are just fixing the shape.
---------
Signed-off-by: hanhanW <hanhan0912@gmail.com>
