llvm-project.git/mlir/test/lib/Analysis/TestMemRefDependenceCheck.cpp, branch main

[mlir][Affine][NFC] Wrap dialect in "affine" namespace

2023-04-20T02:19:21+00:00

This cleanup aligns the affine dialect with all the other dialects.

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

[mlir][affine][analysis][NFC] Simplify FlatAffineConstraints API

2023-03-15T08:22:53+00:00

* Remove `reset` function. Use copy assignment directly (instead of within `reset`).
* Fix potential `nullptr` dereference in `getFlattenedAffineExprs`.
* Make constraint set optional in `checkMemrefAccessDependence`.

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

[mlir] llvm::Optional::value => operator*/operator->

2022-12-17T19:07:38+00:00

std::optional::value() has undesired exception checking semantics and is
unavailable in older Xcode (see _LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS). The
call sites block std::optional migration.

[mlir][affine] Support affine.parallel in the index set analysis

2022-12-04T11:36:48+00:00

Support affine.parallel in the index set analysis. It allows us to do dependence analysis containing affine.parallel in addition to affine.for and affine.if. This change only supports the constant lower/upper bound in affine.parallel. Other complicated affine map bounds will be supported in further commits.

See https://github.com/llvm/llvm-project/issues/57327

Reviewed By: bondhugula

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

[mlir] Use value instead of getValue (NFC)

2022-07-14T07:19:59+00:00

[mlir] Use has_value instead of hasValue (NFC)

2022-07-13T07:57:02+00:00

Revert "Don't use Optional::hasValue (NFC)"

2022-06-25T18:56:50+00:00

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

2022-06-25T18:55:57+00:00

[mlir] Rework the implementation of TypeID

2022-04-04T20:52:26+00:00

This commit restructures how TypeID is implemented to ideally avoid
the current problems related to shared libraries. This is done by changing
the "implicit" fallback path to use the name of the type, instead of using
a static template variable (which breaks shared libraries). The major downside to this
is that it adds some additional initialization costs for the implicit path. Given the
use of type names for uniqueness in the fallback, we also no longer allow types
defined in anonymous namespaces to have an implicit TypeID. To simplify defining
an ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macro
was added to allow for explicitly defining a TypeID directly on an internal class.

To help identify when types are using the fallback, `-debug-only=typeid` can be
used to log which types are using implicit ids.

This change generally only requires changes to the test passes, which are all defined
in anonymous namespaces, and thus can't use the fallback any longer.

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

[mlir][test] Generalize a bunch of FuncOp based passes to run on any operation/interfaces

2022-03-08T20:25:32+00:00

A lot of test passes are currently anchored on FuncOp, but this
dependency
is generally just historical. A majority of these test passes can run on
any operation, or can operate on a specific interface
(FunctionOpInterface/SymbolOpInterface).
This allows for greatly reducing the API dependency on FuncOp, which
is slated to be moved out of the Builtin dialect.

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