[mlir][NFC] Update remaining textual references of un-namespaced `func` operations

The special case parsing of operations in the `func` dialect is being removed, and
operations will require the dial

[mlir][NFC] Update remaining textual references of un-namespaced `func` operations

The special case parsing of operations in the `func` dialect is being removed, and
operations will require the dialect namespace prefix.

show more ...

[mlir][NFC] Update textual references of `func` to `func.func` in Transform tests

The special case parsing of `func` operations is being removed.

[mlir] Update LICM to support Graph Regions

Changes the algorithm of LICM to support graph regions (no guarantee of topologically sorted order). Also fixes an issue where ops with recursive side eff

[mlir] Update LICM to support Graph Regions

Changes the algorithm of LICM to support graph regions (no guarantee of topologically sorted order). Also fixes an issue where ops with recursive side effects and regions would not be hoisted if any nested ops used operands that were defined within the nested region.

Reviewed By: rriddle

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

show more ...

[mlir] Fix missing check on nested op values in LICM

LICM checks that nested ops depend only on values defined outside
before performing hoisting.
However, it specifically omits to check for termina

[mlir] Fix missing check on nested op values in LICM

LICM checks that nested ops depend only on values defined outside
before performing hoisting.
However, it specifically omits to check for terminators which can
lead to SSA violations.
This revision fixes the incorrect behavior.

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

show more ...

[MLIR] Replace std ops with arith dialect ops

Precursor: https://reviews.llvm.org/D110200

Removed redundant ops from the standard dialect that were moved to the
`arith` or `math` dialects.

Renamed

[MLIR] Replace std ops with arith dialect ops

Precursor: https://reviews.llvm.org/D110200

Removed redundant ops from the standard dialect that were moved to the
`arith` or `math` dialects.

Renamed all instances of operations in the codebase and in tests.

Reviewed By: rriddle, jpienaar

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

show more ...

[MLIR] Create memref dialect and move dialect-specific ops from std.

Create the memref dialect and move dialect-specific ops
from std dialect to this dialect.

Moved ops:
AllocOp -> MemRef_AllocOp
A

[MLIR] Create memref dialect and move dialect-specific ops from std.

Create the memref dialect and move dialect-specific ops
from std dialect to this dialect.

Moved ops:
AllocOp -> MemRef_AllocOp
AllocaOp -> MemRef_AllocaOp
AssumeAlignmentOp -> MemRef_AssumeAlignmentOp
DeallocOp -> MemRef_DeallocOp
DimOp -> MemRef_DimOp
MemRefCastOp -> MemRef_CastOp
MemRefReinterpretCastOp -> MemRef_ReinterpretCastOp
GetGlobalMemRefOp -> MemRef_GetGlobalOp
GlobalMemRefOp -> MemRef_GlobalOp
LoadOp -> MemRef_LoadOp
PrefetchOp -> MemRef_PrefetchOp
ReshapeOp -> MemRef_ReshapeOp
StoreOp -> MemRef_StoreOp
SubViewOp -> MemRef_SubViewOp
TransposeOp -> MemRef_TransposeOp
TensorLoadOp -> MemRef_TensorLoadOp
TensorStoreOp -> MemRef_TensorStoreOp
TensorToMemRefOp -> MemRef_BufferCastOp
ViewOp -> MemRef_ViewOp

The roadmap to split the memref dialect from std is discussed here:
https://llvm.discourse.group/t/rfc-split-the-memref-dialect-from-std/2667

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

show more ...

Revert "[MLIR] Create memref dialect and move several dialect-specific ops from std."

This commit introduced a cyclic dependency:
Memref dialect depends on Standard because it used ConstantIndexOp.

Revert "[MLIR] Create memref dialect and move several dialect-specific ops from std."

This commit introduced a cyclic dependency:
Memref dialect depends on Standard because it used ConstantIndexOp.
Std depends on the MemRef dialect in its EDSC/Intrinsics.h

Working on a fix.

This reverts commit 8aa6c3765b924d86f623d452777eb76b83bf2787.

show more ...

[MLIR] Create memref dialect and move several dialect-specific ops from std.

Create the memref dialect and move several dialect-specific ops without
dependencies to other ops from std dialect to thi

[MLIR] Create memref dialect and move several dialect-specific ops from std.

Create the memref dialect and move several dialect-specific ops without
dependencies to other ops from std dialect to this dialect.

Moved ops:
AllocOp -> MemRef_AllocOp
AllocaOp -> MemRef_AllocaOp
DeallocOp -> MemRef_DeallocOp
MemRefCastOp -> MemRef_CastOp
GetGlobalMemRefOp -> MemRef_GetGlobalOp
GlobalMemRefOp -> MemRef_GlobalOp
PrefetchOp -> MemRef_PrefetchOp
ReshapeOp -> MemRef_ReshapeOp
StoreOp -> MemRef_StoreOp
TransposeOp -> MemRef_TransposeOp
ViewOp -> MemRef_ViewOp

The roadmap to split the memref dialect from std is discussed here:
https://llvm.discourse.group/t/rfc-split-the-memref-dialect-from-std/2667

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

show more ...

[mlir][AsmPrinter] Refactor printing to only print aliases for attributes/types that will exist in the output.

This revision refactors the way that attributes/types are considered when generating al

[mlir][AsmPrinter] Refactor printing to only print aliases for attributes/types that will exist in the output.

This revision refactors the way that attributes/types are considered when generating aliases. Instead of considering all of the attributes/types of every operation, we perform a "fake" print step that prints the operations using a dummy printer to collect the attributes and types that would actually be printed during the real process. This removes a lot of attributes/types from consideration that generally won't end up in the final output, e.g. affine map attributes in an `affine.apply`/`affine.for`.

This resolves a long standing TODO w.r.t aliases, and helps to have a much cleaner textual output format. As a datapoint to the latter, as part of this change several tests were identified as testing for the presence of attributes aliases that weren't actually referenced by the custom form of any operation.

To ensure that this wouldn't cause a large degradation in compile time due to the second full print, I benchmarked this change on a very large module with a lot of operations(The file is ~673M/~4.7 million lines long). This file before this change take ~6.9 seconds to print in the custom form, and ~7 seconds after this change. In the custom assembly case, this added an average of a little over ~100 miliseconds to the compile time. This increase was due to the way that argument attributes on functions are structured and how they get printed; i.e. with a better representation the negative impact here can be greatly decreased. When printing in the generic form, this revision had no observable impact on the compile time. This benchmarking leads me to believe that the impact of this change on compile time w.r.t printing is closely related to `print` methods that perform a lot of additional/complex processing outside of the OpAsmPrinter.

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

show more ...

[mlir][ASM] Refactor how attribute/type aliases are specified.

Previously they were separated into "instance" and "kind" aliases, and also required that the dialect know ahead of time all of the ins

[mlir][ASM] Refactor how attribute/type aliases are specified.

Previously they were separated into "instance" and "kind" aliases, and also required that the dialect know ahead of time all of the instances that would have a corresponding alias. This approach was very clunky and not ergonomic to interact with. The new approach is to provide the dialect with an instance of an attribute/type to provide an alias for, fully replacing the original split approach.

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

show more ...

[mlir] Change dialect namespace loop->scf

All ops of the SCF dialect now use the `scf.` prefix instead of `loop.`. This
is a part of dialect renaming.

Differential Revision: https://reviews.llvm.or

[mlir] Change dialect namespace loop->scf

All ops of the SCF dialect now use the `scf.` prefix instead of `loop.`. This
is a part of dialect renaming.

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

show more ...

[MLIR] Implement LoopLikeInterface for loop.parallel

Summary:
This is to allow optimizations like loop invariant code motion to work
on the ParallelOp.

Additional small cleanup on the ForOp impleme

[MLIR] Implement LoopLikeInterface for loop.parallel

Summary:
This is to allow optimizations like loop invariant code motion to work
on the ParallelOp.

Additional small cleanup on the ForOp implementation of
LoopLikeInterface and the test file of loop-invariant-code-motion.

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

show more ...

[mlir][SideEffects] Replace the old SideEffects dialect interface with the newly added op interfaces/traits.

Summary:
The old interface was a temporary stopgap to allow for implementing simple LICM

[mlir][SideEffects] Replace the old SideEffects dialect interface with the newly added op interfaces/traits.

Summary:
The old interface was a temporary stopgap to allow for implementing simple LICM that took side effects of region operations into account. Now that MLIR has proper support for specifying memory effects, this interface can be deleted.

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

show more ...

[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types.

Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, ma

[mlir] Change the syntax of AffineMapAttr and IntegerSetAttr to avoid conflicts with function types.

Summary: The current syntax for AffineMapAttr and IntegerSetAttr conflict with function types, making it currently impossible to round-trip function types(and e.g. FuncOp) in the IR. This revision changes the syntax for the attributes by wrapping them in a keyword. AffineMapAttr is wrapped with `affine_map<>` and IntegerSetAttr is wrapped with `affine_set<>`.

Reviewed By: nicolasvasilache, ftynse

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

show more ...

Implement simple loop-invariant-code-motion based on dialect interfaces.

PiperOrigin-RevId: 275004258

Add a canonicalization to erase empty AffineForOps.

AffineForOp themselves are pure and can be removed if there are no internal operations.

PiperOrigin-RevId: 266481293

Standardize the value numbering in the AsmPrinter.

Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain

Standardize the value numbering in the AsmPrinter.

Change the AsmPrinter to number values breadth-first so that values in adjacent regions can have the same name. This allows for ModuleOp to contain operations that produce results. This also standardizes the special name of region entry arguments to "arg[0-9+]" now that Functions are also operations.

PiperOrigin-RevId: 257225069

show more ...

Globally change load/store/dma_start/dma_wait operations over to affine.load/store/dma_start/dma_wait.
In most places, this is just a name change (with the exception of affine.dma_start swapping the

Globally change load/store/dma_start/dma_wait operations over to affine.load/store/dma_start/dma_wait.
In most places, this is just a name change (with the exception of affine.dma_start swapping the operand positions of its tag memref and num_elements operands).
Significant code changes occur here:
*) Vectorization: LoopAnalysis.cpp, Vectorize.cpp
*) Affine Transforms: Transforms/Utils/Utils.cpp

PiperOrigin-RevId: 256395088

show more ...

Remove unnecessary -verify-diagnostics

These were likely added in error because of confusion about the flag when it was just called "-verify". The extra flag doesn't cause much harm, but it does mak

Remove unnecessary -verify-diagnostics

These were likely added in error because of confusion about the flag when it was just called "-verify". The extra flag doesn't cause much harm, but it does make mlir-opt do more work and clutter the RUN line

PiperOrigin-RevId: 254037016

show more ...

Rename -verify mlir-opt flag to -verify-expected-diagnostics

This name has caused some confusion because it suggests that it's running op verification (and that this verification isn't getting run b

Rename -verify mlir-opt flag to -verify-expected-diagnostics

This name has caused some confusion because it suggests that it's running op verification (and that this verification isn't getting run by default).

PiperOrigin-RevId: 254035268

show more ...

Loop invariant code motion - remove reliance on getForwardSlice. Add more tests.

--

PiperOrigin-RevId: 250950703

Prepend an "affine-" prefix to Affine pass option names - NFC

Trying to activate both LLVM and MLIR passes in mlir-cpu-runner showed name collisions when registering pass names.
One possible

Prepend an "affine-" prefix to Affine pass option names - NFC

Trying to activate both LLVM and MLIR passes in mlir-cpu-runner showed name collisions when registering pass names.
One possible way of disambiguating that should also work across dialects is to prepend the dialect name to the passes that specifically operate on that dialect.

With this CL, mlir-cpu-runner tests still run when both LLVM and MLIR passes are registered

--

PiperOrigin-RevId: 246539917

show more ...

Loop invariant code motion.

--

PiperOrigin-RevId: 244043679