[mlir] Make `Regions`s `cloneInto` multithread-readable

Prior to this patch, `cloneInto` would do a simple walk over the blocks and contained operations and clone and map them as it encounters them.

[mlir] Make `Regions`s `cloneInto` multithread-readable

Prior to this patch, `cloneInto` would do a simple walk over the blocks and contained operations and clone and map them as it encounters them. As finishing touch it then remaps any successor and operands it has remapped during that process.

This is generally fine, but sadly leads to a lot of uses of both operations and blocks from the source region, in the cloned operations in the target region. Those uses lead to writes in the use-def list of the operations, making `cloneInto` never thread safe.

This patch reimplements `cloneInto` in three steps to avoid ever creating any extra uses on elements in the source region:
* It first creates the mapping of all blocks and block operands
* It then clones all operations to create the mapping of all operation results, but does not yet clone any regions or set the operands
* After all operation results have been mapped, it now sets the operations operands and clones their regions.

That way it is now possible to call `cloneInto` from multiple threads if the Region or Operation is isolated-from-above. This allows creating copies of functions or to use `mlir::inlineCall` with the same source region from multiple threads. In the general case, the method is thread-safe if through cloning, no new uses of `Value`s from outside the cloned Operation/Region are created. This can be ensured by mapping any outside operands via the `BlockAndValueMapping` to `Value`s owned by the caller thread.

While I was at it, I also reworked the `clone` method of `Operation` a little bit and added a proper options class to avoid having a `cloneWithoutRegionsAndOperands` method, and be more extensible in the future. `cloneWithoutRegions` is now also a simple wrapper that calls `clone` with the proper options set. That way all the operation cloning code is now contained solely within `clone`.

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

show more ...

[mlir] Allow RegionRange to accept ArrayRef<Region *>

Adds another pointer to the union in RegionRange to allow RegionRange to work on ArrayRef<Region *> (i.e. vectors of Region *).

Reviewed By: rr

[mlir] Allow RegionRange to accept ArrayRef<Region *>

Adds another pointer to the union in RegionRange to allow RegionRange to work on ArrayRef<Region *> (i.e. vectors of Region *).

Reviewed By: rriddle

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

show more ...

[mlir] Make locations required when adding/creating block arguments

BlockArguments gained the ability to have locations attached a while ago, but they
have always been optional. This goes against th

[mlir] Make locations required when adding/creating block arguments

BlockArguments gained the ability to have locations attached a while ago, but they
have always been optional. This goes against the core tenant of MLIR where location
information is a requirement, so this commit updates the API to require locations.

Fixes #53279

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

show more ...

Preserve argument locations when cloning a region.

Reviewed By: mehdi_amini

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

Fix clang-tidy issues in mlir/ (NFC)

Reviewed By: ftynse

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

[mlir][NFC] Move several small methods from .cpp to .h to allow more aggressive inlining

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

[Dominators] Rewrite the dominator implementation for efficiency. NFC.

The previous impl densely scanned the entire region starting with an op
when dominators were created, creating a DominatorTree

[Dominators] Rewrite the dominator implementation for efficiency. NFC.

The previous impl densely scanned the entire region starting with an op
when dominators were created, creating a DominatorTree for every region.

This is extremely expensive up front -- particularly for clients like
Linalg/Transforms/Fusion.cpp that construct DominanceInfo for a single
query. It is also extremely memory wasteful for IRs that use single
block regions commonly (e.g. affine.for) because it's making a
dominator tree for a region that has trivial dominance. The
implementation also had numerous unnecessary minor efficiencies, e.g.
doing multiple walks of the region tree or tryGetBlocksInSameRegion
building a DenseMap that it didn't need.

This patch switches to an approach where [Post]DominanceInfo is free
to construct, and which lazily constructs DominatorTree's for any
multiblock regions that it needs. This avoids the up-front cost
entirely, making its runtime proportional to the complexity of the
region tree instead of # ops in a region. This also avoids the memory
and time cost of creating DominatorTree's for single block regions.

Finally this rewrites the implementation for simplicity and to avoids
the constant factor problems the old implementation had.

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

show more ...

[Verifier] Significantly speed up IsolatedFromAbove checking. NFC.

The implementation had a couple of problems, including checking
"isProperAncestor" in an inefficient way. It also recursed into
ot

[Verifier] Significantly speed up IsolatedFromAbove checking. NFC.

The implementation had a couple of problems, including checking
"isProperAncestor" in an inefficient way. It also recursed into
other "isolated from above" ops. In the case of CIRCT, we get
three levels of isolated ops:

mlir::ModuleOp
firrtl::CircuitOp
firrtl::FModuleOp

The verification for module would recurse into the circuits and
fmodules checking them. The verifier hook for circuit would
recurse into all the modules reverifying them, fmoduleop would
then reverify them. The same happens for mlir::ModuleOp and Func.

While here, fix an old design problem: IsolatedFromAbove checking
was implemented by a method on the Region class, which isn't
actually general and isn't used by anything else. Move it over
to be a trait impl verifier method like the others and specialize
it for its task.

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

show more ...

[NFC] Add getArgumentTypes() to Region

- Add getArgumentTypes() to Region (missed from before)
- Adopt Region argument API in `hasMultiplyAddBody`
- Fix 2 typos in comments

Differential Revision: h

[NFC] Add getArgumentTypes() to Region

- Add getArgumentTypes() to Region (missed from before)
- Adopt Region argument API in `hasMultiplyAddBody`
- Fix 2 typos in comments

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

show more ...

[MLIR] Add argument related API to Region

- Arguments of the first block of a region are considered region arguments.
- Add API on Region class to deal with these arguments directly instead of
usi

[MLIR] Add argument related API to Region

- Arguments of the first block of a region are considered region arguments.
- Add API on Region class to deal with these arguments directly instead of
using the front() block.
- Changed several instances of existing code that can use this API
- Fixes https://bugs.llvm.org/show_bug.cgi?id=46535

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

show more ...

[mlir][IR] Add a Region::getOps method that returns a range of immediately nested operations

This allows for walking the operations nested directly within a region, without traversing nested regions

[mlir][IR] Add a Region::getOps method that returns a range of immediately nested operations

This allows for walking the operations nested directly within a region, without traversing nested regions.

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

show more ...

[mlir] Extended Liveness analysis to support nested regions.

The current Liveness analysis does not support operations with nested regions.
This causes issues when querying liveness information abou

[mlir] Extended Liveness analysis to support nested regions.

The current Liveness analysis does not support operations with nested regions.
This causes issues when querying liveness information about blocks nested within
operations. Furthermore, the live-in and live-out sets are not computed properly
in these cases.

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

show more ...

[llvm][STLExtras] Move various iterator/range utilities from MLIR to LLVM

This revision moves the various range utilities present in MLIR to LLVM to enable greater reuse. This revision moves the fol

[llvm][STLExtras] Move various iterator/range utilities from MLIR to LLVM

This revision moves the various range utilities present in MLIR to LLVM to enable greater reuse. This revision moves the following utilities:

* indexed_accessor_*
This is set of utility iterator/range base classes that allow for building a range class where the iterators are represented by an object+index pair.

* make_second_range
Given a range of pairs, returns a range iterating over the `second` elements.

* hasSingleElement
Returns if the given range has 1 element. size() == 1 checks end up being very common, but size() is not always O(1) (e.g., ilist). This method provides O(1) checks for those cases.

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

show more ...

Mass update the MLIR license header to mention "Part of the LLVM project"

This is an artifact from merging MLIR into LLVM, the file headers are
now aligned with the rest of the project.

[mlir] NFC: Remove Value::operator* and Value::operator-> now that Value is properly value-typed.

Summary: These were temporary methods used to simplify the transition.

Reviewed By: antiagainst

Di

[mlir] NFC: Remove Value::operator* and Value::operator-> now that Value is properly value-typed.

Summary: These were temporary methods used to simplify the transition.

Reviewed By: antiagainst

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

show more ...

NFC: Replace ValuePtr with Value and remove it now that Value is value-typed.

ValuePtr was a temporary typedef during the transition to a value-typed Value.

PiperOrigin-RevId: 286945714

Adjust License.txt file to use the LLVM license

PiperOrigin-RevId: 286906740

NFC: Introduce new ValuePtr/ValueRef typedefs to simplify the transition to Value being value-typed.

This is an initial step to refactoring the representation of OpResult as proposed in: https://gro

NFC: Introduce new ValuePtr/ValueRef typedefs to simplify the transition to Value being value-typed.

This is an initial step to refactoring the representation of OpResult as proposed in: https://groups.google.com/a/tensorflow.org/g/mlir/c/XXzzKhqqF_0/m/v6bKb08WCgAJ

This change will make it much simpler to incrementally transition all of the existing code to use value-typed semantics.

PiperOrigin-RevId: 286844725

show more ...

NFC: Remove unnecessary 'llvm::' prefix from uses of llvm symbols declared in `mlir` namespace.

Aside from being cleaner, this also makes the codebase more consistent.

PiperOrigin-RevId: 286206974

Add new indexed_accessor_range_base and indexed_accessor_range classes that simplify defining index-able ranges.

Many ranges want similar functionality from a range type(e.g. slice/drop_front/operat

Add new indexed_accessor_range_base and indexed_accessor_range classes that simplify defining index-able ranges.

Many ranges want similar functionality from a range type(e.g. slice/drop_front/operator[]/etc.), so these classes provide a generic implementation that may be used by many different types of ranges. This removes some code duplication, and also empowers many of the existing range types in MLIR(e.g. result type ranges, operand ranges, ElementsAttr ranges, etc.). This change only updates RegionRange and ValueRange, more ranges will be updated in followup commits.

PiperOrigin-RevId: 284615679

show more ...

Add RegionRange for when need to abstract over different region iteration

Follows ValueRange in representing a generic abstraction over the different
ways to represent a range of Regions. This wrapp

Add RegionRange for when need to abstract over different region iteration

Follows ValueRange in representing a generic abstraction over the different
ways to represent a range of Regions. This wrapper is not as ValueRange and only
considers the current cases of interest: MutableArrayRef<Region> and
ArrayRef<std::unique_ptr<Region>> as occurs during op construction vs op region
querying.

Note: ArrayRef<std::unique_ptr<Region>> allows for unset regions, so this range
returns a pointer to a Region instead of a Region.
PiperOrigin-RevId: 284563229

show more ...

Replace some remnant uses of "inst" with "op".

PiperOrigin-RevId: 278961676

Assert that region is not cloned into itself.

PiperOrigin-RevId: 273707291

Make isIsolatedAbove robuster to invalid IR

This function is only called from the verifier.

PiperOrigin-RevId: 267145495

Refactor the 'walk' methods for operations.

This change refactors and cleans up the implementation of the operation walk methods. After this refactoring is that the explicit template parameter for t

Refactor the 'walk' methods for operations.

This change refactors and cleans up the implementation of the operation walk methods. After this refactoring is that the explicit template parameter for the operation type is no longer needed for the explicit op walks. For example:

op->walk<AffineForOp>([](AffineForOp op) { ... });

is now accomplished via:

op->walk([](AffineForOp op) { ... });

PiperOrigin-RevId: 266209552

show more ...