[mlir] Swap integer range inference to the new framework

Integer range inference has been swapped to the new framework. The integer value range lattices automatically updates the corresponding const

[mlir] Swap integer range inference to the new framework

Integer range inference has been swapped to the new framework. The integer value range lattices automatically updates the corresponding constant value on update.

Depends on D127173

Reviewed By: krzysz00, rriddle

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

show more ...

[mlir] An implementation of sparse data-flow analysis

This patch introduces a (forward) sparse data-flow analysis implemented with the data-flow analysis framework. The analysis interacts with liven

[mlir] An implementation of sparse data-flow analysis

This patch introduces a (forward) sparse data-flow analysis implemented with the data-flow analysis framework. The analysis interacts with liveness information that can be provided by dead-code analysis to be conditional. This patch re-implements SCCP using dead-code analysis and (conditional) constant propagation analyses.

Depends on D127064

Reviewed By: rriddle, phisiart

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

show more ...

[MLIR][DataFlowAnalysis] Use a queue to maintain the worklist

Since the analysis is described to be suitable for a forward
data-flow analysis, maintaining the worklist as a queue mimics
RPO ordering

[MLIR][DataFlowAnalysis] Use a queue to maintain the worklist

Since the analysis is described to be suitable for a forward
data-flow analysis, maintaining the worklist as a queue mimics
RPO ordering of block visits, thus reaching the fixpoint earlier.

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

show more ...

Adjust "end namespace" comment in MLIR to match new agree'd coding style

See D115115 and this mailing list discussion:
https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html

Differenti

Adjust "end namespace" comment in MLIR to match new agree'd coding style

See D115115 and this mailing list discussion:
https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html

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

show more ...

[mlir] Refactor the forward dataflow propagation in SCCP into a generic framework

This revision takes the forward value propagation engine in SCCP and refactors it into a more generalized forward da

[mlir] Refactor the forward dataflow propagation in SCCP into a generic framework

This revision takes the forward value propagation engine in SCCP and refactors it into a more generalized forward dataflow analysis framework. This framework allows for propagating information about values across the various control flow constructs in MLIR, and removes the need for users to reinvent the traversal (often not as completely). There are a few aspects of the traversal, that were conservative for SCCP, that should be relaxed to support the needs of different value analyses. To keep this revision simple, these conservative behaviors will be left in (Note that this won't produce an incorrect result, but may produce more conservative results than necessary in certain edge cases. e.g. region entry arguments for non-region branch interface operations). The framework also only focuses on computing lattices for values, given the SCCP origins, but this is something to relax as needed in the future.

Given that this logic is already in SCCP, a majority of this commit is NFC. The more interesting parts are the interface glue that clients interact with.

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

show more ...

[mlir][IR] Remove the concept of `OperationProperties`

These properties were useful for a few things before traits had a better integration story, but don't really carry their weight well these days

[mlir][IR] Remove the concept of `OperationProperties`

These properties were useful for a few things before traits had a better integration story, but don't really carry their weight well these days. Most of these properties are already checked via traits in most of the code. It is better to align the system around traits, and improve the performance/cost of traits in general.

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

show more ...

[mlir] Mark LogicalResult as LLVM_NODISCARD

This makes ignoring a result explicit by the user, and helps to prevent accidental errors with dropped results. Marking LogicalResult as no discard was al

[mlir] Mark LogicalResult as LLVM_NODISCARD

This makes ignoring a result explicit by the user, and helps to prevent accidental errors with dropped results. Marking LogicalResult as no discard was always the intention from the beginning, but got lost along the way.

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

show more ...

[mlir] Remove the MutableDictionaryAttr class

This class used to serve a few useful purposes:
* Allowed containing a null DictionaryAttr
* Provided some simple mutable API around a DictionaryAttr

T

[mlir] Remove the MutableDictionaryAttr class

This class used to serve a few useful purposes:
* Allowed containing a null DictionaryAttr
* Provided some simple mutable API around a DictionaryAttr

The first of which is no longer an issue now that there is much better caching support for attributes in general, and a cache in the context for empty dictionaries. The second results in more trouble than it's worth because it mutates the internal dictionary on every action, leading to a potentially large number of dictionary copies. NamedAttrList is a much better alternative for the second use case, and should be modified as needed to better fit it's usage as a DictionaryAttrBuilder.

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

show more ...

[mlir][SCCP] Don't visit private callables unless they are used when tracking interprocedural arguments/results

This fixes a subtle bug where SCCP could incorrectly optimize a private callable while

[mlir][SCCP] Don't visit private callables unless they are used when tracking interprocedural arguments/results

This fixes a subtle bug where SCCP could incorrectly optimize a private callable while waiting for its arguments to be resolved.

Fixes PR#48457

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

show more ...

Add `Operation* OpState::operator->()` to provide more convenient access to members of Operation.

Given that OpState already implicit converts to Operator*, this seems reasonable.

The alternative w

Add `Operation* OpState::operator->()` to provide more convenient access to members of Operation.

Given that OpState already implicit converts to Operator*, this seems reasonable.

The alternative would be to add more functions to OpState which forward to Operation.

Reviewed By: rriddle, ftynse

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

show more ...

[mlir] NFC: fix trivial typos
fix typos in comments and documents

Reviewed By: jpienaar

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

[mlir] Update SCCP and the Inliner to use SymbolTableCollection for symbol lookups

This transforms the symbol lookups to O(1) from O(NM), greatly speeding up both passes. For a large MLIR module thi

[mlir] Update SCCP and the Inliner to use SymbolTableCollection for symbol lookups

This transforms the symbol lookups to O(1) from O(NM), greatly speeding up both passes. For a large MLIR module this shaved seconds off of the compilation time.

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

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] Continue renaming of "SideEffects"

MLIRSideEffects -> MLIRSideEffectInterfaces
SideEffects.h -> SideEffectInterfaces.h
SideEffects.cpp -> SideEffectInterface.cpp

Note that I haven't renamed

[MLIR] Continue renaming of "SideEffects"

MLIRSideEffects -> MLIRSideEffectInterfaces
SideEffects.h -> SideEffectInterfaces.h
SideEffects.cpp -> SideEffectInterface.cpp

Note that I haven't renamed TableGen/SideEffects.h or TableGen/SideEffects.cpp

find -name "*.h" -exec sed -i "s/SideEffects.h/SideEffectInterfaces.h/" "{}" \;
find -name "CMakeLists.txt" -exec sed -i "s/MLIRSideEffects/MLIRSideEffectInterfaces/" "{}" \;

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

show more ...

Rename NamedAttributeList to MutableDictionaryAttr

Makes the relationship and function clearer. Accordingly rename getAttrList to getMutableAttrDict.

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

Rename NamedAttributeList to MutableDictionaryAttr

Makes the relationship and function clearer. Accordingly rename getAttrList to getMutableAttrDict.

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

show more ...

[mlir][SCCP] Add support for propagating across symbol based calls

This revision adds support for propagating constants across symbol-based callgraph edges. It uses the existing Call/CallableOpInter

[mlir][SCCP] Add support for propagating across symbol based calls

This revision adds support for propagating constants across symbol-based callgraph edges. It uses the existing Call/CallableOpInterfaces to detect the dataflow edges, and propagates constants through arguments and out of returns.

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

show more ...

[mlir][SCCP] Add support for propagating constants across inter-region control flow.

This is possible by adding two new ControlFlowInterface additions:

- A new interface, RegionBranchOpInterface
Th

[mlir][SCCP] Add support for propagating constants across inter-region control flow.

This is possible by adding two new ControlFlowInterface additions:

- A new interface, RegionBranchOpInterface
This interface allows for region holding operations to describe how control flows between regions. This interface initially contains two methods:

* getSuccessorEntryOperands
Returns the operands of this operation used as the entry arguments when entering the region at `index`, which was specified as a successor by `getSuccessorRegions`. when entering. These operands should correspond 1-1 with the successor inputs specified in `getSuccessorRegions`, and may be a subset of the entry arguments for that region.

* getSuccessorRegions
Returns the viable successors of a region, or the possible successor when branching from the parent op. This allows for describing which regions may be executed when entering an operation, and which regions are executed after having executed another region of the parent op. For example, a structured loop operation may always enter into the loop body region. The loop body region may branch back to itself, or exit to the operation.

- A trait, ReturnLike
This trait signals that a terminator exits a region and forwards all of its operands as "exiting" values.

These additions allow for performing more general dataflow analysis in the presence of region holding operations.

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

show more ...

[mlir][Transforms] Add pass to perform sparse conditional constant propagation

This revision adds the initial pass for performing SCCP generically in MLIR. SCCP is an algorithm for propagating const

[mlir][Transforms] Add pass to perform sparse conditional constant propagation

This revision adds the initial pass for performing SCCP generically in MLIR. SCCP is an algorithm for propagating constants across control flow, and optimistically assumes all values to be constant unless proven otherwise. It currently supports branching control, with support for regions and inter-procedural propagation being added in followups.

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

show more ...