[MLIR] Remove unneeded LLVMDialect.h include in ControlFlowToSCF.cpp (#113560)

This fixes the following failure when doing a clean build (in particular
no .ninja* lying around) of lib/libMLIRContro

[MLIR] Remove unneeded LLVMDialect.h include in ControlFlowToSCF.cpp (#113560)

This fixes the following failure when doing a clean build (in particular
no .ninja* lying around) of lib/libMLIRControlFlowToSCF.a only:
```
In file included from llvm/include/llvm/IR/Module.h:22,
from mlir/include/mlir/Dialect/LLVMIR/LLVMDialect.h:37,
from mlir/lib/Conversion/ControlFlowToSCF/ControlFlowToSCF.cpp:19
llvm/include/llvm/IR/Attributes.h:90:14: fatal error: llvm/IR/Attributes.inc: No such file or directory
```

show more ...

Revert "[mlir] NFC: fix dependence of (Tensor|Linalg|MemRef|Complex) dialects on LLVM Dialect and LLVM Core in CMake build (#104832)"

This reverts commit 43b508566799751aa180f1eaaafc5be693f2f1ae sin

Revert "[mlir] NFC: fix dependence of (Tensor|Linalg|MemRef|Complex) dialects on LLVM Dialect and LLVM Core in CMake build (#104832)"

This reverts commit 43b508566799751aa180f1eaaafc5be693f2f1ae since it
caused the build to break with BUILD_SHARED_LIBS=ON.

show more ...

[mlir] NFC: fix dependence of (Tensor|Linalg|MemRef|Complex) dialects on LLVM Dialect and LLVM Core in CMake build (#104832)

This change removes dependencies declared as either 'LINK_LIBS' or
'LINK

[mlir] NFC: fix dependence of (Tensor|Linalg|MemRef|Complex) dialects on LLVM Dialect and LLVM Core in CMake build (#104832)

This change removes dependencies declared as either 'LINK_LIBS' or
'LINK_COMPONENTS' across several MLIR libraries. The removed
dependencies appear
to be incorrect and may have been required in older versions of the
project.
These dependencies cause many high level dialects to have transitive
dependence on the LLVM dialect and the LLVM 'Core' library
('llvm/lib/IR').

Note that if using the 'Ninja' CMake generator, one can inspect the
dependencies
(including all transitive libraries) of any given MLIR target but using
the command `ninja -C <build dir> -t browse` and navigating to the
library
of interest in a web browser.

show more ...

[mlir] Use `OpBuilder::createBlock` in op builders and patterns (#82770)

When creating a new block in (conversion) rewrite patterns,
`OpBuilder::createBlock` must be used. Otherwise, no
`notifyBlo

[mlir] Use `OpBuilder::createBlock` in op builders and patterns (#82770)

When creating a new block in (conversion) rewrite patterns,
`OpBuilder::createBlock` must be used. Otherwise, no
`notifyBlockInserted` notification is sent to the listener.

Note: The dialect conversion relies on listener notifications to keep
track of IR modifications. Creating blocks without the builder API can
lead to memory leaks during rollback.

show more ...

[mlir][CFGToSCF] Visit subregions in CFGToSCF pass

This is useful when user already have partially-scf'ed IR or other ops with nested regions (e.g. linalg.generic).

Also, improve error message and

[mlir][CFGToSCF] Visit subregions in CFGToSCF pass

This is useful when user already have partially-scf'ed IR or other ops with nested regions (e.g. linalg.generic).

Also, improve error message and pass docs.

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

show more ...

[mlir][CFGToSCF] Add interface changes for downstream projects

This is a follow-up to https://reviews.llvm.org/D156889

Downstream projects may have more complicated ops than the control flow ops up

[mlir][CFGToSCF] Add interface changes for downstream projects

This is a follow-up to https://reviews.llvm.org/D156889

Downstream projects may have more complicated ops than the control flow ops upstream and therefore need a more powerful interface to support the lifting process. Use cases include the propagation of (inherent) metadata that was previously on the control flow ops and now needs to be lifted to structured control flow ops.
Since the lifting process is inherently non-local in respect to the function-body, we require stronger guarantees from the interface.

This patch therefore makes two changes to the interface:
* Passes the terminator that is being replaced to `createStructuredBranchRegionTerminatorOp`
* Adds as precondition to `createCFGSwitchOp` that its predecessors are already correctly established

Asserts have been added to verify these were it makes sense and to correctly state intent. I have not added tests purely because testing preconditions like these is not really feasible (and incredibly specific).

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

show more ...

[mlir][NFC] Expose the `CFGToSCFInterface` for the `ControlFlowToSCF` pass

This is useful for any downstream users who may just want to use slightly different ops than the pass or need to take into

[mlir][NFC] Expose the `CFGToSCFInterface` for the `ControlFlowToSCF` pass

This is useful for any downstream users who may just want to use slightly different ops than the pass or need to take into account other ops in the input while still dealing with ControlFlow ops for the most part.
This also helps writing test implementations for `transformCFGToSCF`.

Since the implementation is now public, comments noting the post conditions of the methods have been added to ensure downstream users can stay compatible with the existing implementation.

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

show more ...

[mlir][cf] Add ControlFlow to SCF lifting pass

Structured control flow ops have proven very useful for many transformations doing analysis on conditional flow and loops. Doing these transformations

[mlir][cf] Add ControlFlow to SCF lifting pass

Structured control flow ops have proven very useful for many transformations doing analysis on conditional flow and loops. Doing these transformations on CFGs requires repeated analysis of the IR possibly leading to more complicated or less capable implementations. With structured control flow, a lot of the information is already present in the structure.

This patch therefore adds a transformation making it possible to lift arbitrary control flow graphs to structured control flow operations. The algorithm used is outlined in https://dl.acm.org/doi/10.1145/2693261. The complexity in implementing the algorithm was mostly spent correctly handling block arguments in MLIR (the paper only addresses the control flow graph part of it).

Note that the transformation has been implemented fully generically and does not depend on any dialect. An interface implemented by the caller is used to construct any operation necessary for the transformation, making it possible to create an interface implementation purpose fit for ones IR.

For the purpose of testing and due to likely being a very common scenario, this patch adds an interface implementation lifting the control flow dialect to the SCF dialect.
Note the use of the word "lifting". Unlike other conversion passes, this pass is not 100% guaranteed to convert all ControlFlow ops.
Only if the input region being transformed contains a single kind of return-like operations is it guaranteed to replace all control flow ops. If that is not the case, exactly one control flow op will remain branching to regions terminating with a given return-like operation (e.g. one region terminates with `llvm.return` the other with `llvm.unreachable`).

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

show more ...