History log of /llvm-project/mlir/lib/Dialect/Bufferization/Transforms/BufferUtils.cpp (Results 1 – 25 of 27)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5
# 2ff2e871 27-Nov-2024 Matthias Springer <me@m-sp.org>

[mlir][bufferization] Remove remaining dialect conversion-based infra parts (#114155)

This commit removes the last remaining components of the dialect
conversion-based bufferization passes.

Note

[mlir][bufferization] Remove remaining dialect conversion-based infra parts (#114155)

This commit removes the last remaining components of the dialect
conversion-based bufferization passes.

Note for LLVM integration: If you depend on these components, migrate to
One-Shot Bufferize or copy them to your codebase.

show more ...


Revision tags: llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init
# dd450f08 07-Jan-2024 Matthias Springer <me@m-sp.org>

[mlir][Interfaces][NFC] Move region loop detection to `RegionBranchOpInterface` (#77090)

`BufferPlacementTransformationBase::isLoop` checks if there a loop in
the region branching graph of an opera

[mlir][Interfaces][NFC] Move region loop detection to `RegionBranchOpInterface` (#77090)

`BufferPlacementTransformationBase::isLoop` checks if there a loop in
the region branching graph of an operation. This algorithm is similar to
`isRegionReachable` in the `RegionBranchOpInterface`. To avoid duplicate
code, `isRegionReachable` is generalized, so that it can be used to
detect region loops. A helper function
`RegionBranchOpInterface::hasLoop` is added.

This change also turns a recursive implementation into an iterative one,
which is the preferred implementation strategy in LLVM.

Also move the `isLoop` to `BufferOptimizations.cpp`, so that we can
gradually retire `BufferPlacementTransformationBase`. (This is so that
proper error handling can be added to `BufferViewFlowAnalysis`.)

show more ...


Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0
# 8160bce9 14-Sep-2023 Martin Erhart <merhart@google.com>

[mlir][bufferization][NFC] Introduce BufferDeallocationOpInterface (#66349)

This new interface allows operations to implement custom handling of ownership values and insertion of dealloc operations

[mlir][bufferization][NFC] Introduce BufferDeallocationOpInterface (#66349)

This new interface allows operations to implement custom handling of ownership values and insertion of dealloc operations which is useful when an op cannot implement the interfaces supported by default by the buffer deallocation pass (e.g., because they are not exactly compatible or because there are some additional semantics to it that would render the default implementations in buffer deallocation invalid, or because no interfaces exist for this
kind of behavior and it's not worth introducing one plus a default implementation in buffer deallocation). Additionally, it can also be used to provide more efficient handling for a specific op than the interface based default
implementations can.

show more ...


# 01334d1a 14-Sep-2023 Martin Erhart <merhart@google.com>

[mlir][bufferization] Add an ownership based buffer deallocation pass (#66337)

Add a new Buffer Deallocation pass with the intend to replace the old
one. For now it is added as a separate pass alon

[mlir][bufferization] Add an ownership based buffer deallocation pass (#66337)

Add a new Buffer Deallocation pass with the intend to replace the old
one. For now it is added as a separate pass alongside in order to allow
downstream users to migrate over gradually. This new pass has the goal
of inserting fewer clone operations and supporting additional use-cases.
Please refer to the Buffer Deallocation section in the updated
Bufferization.md file for more information on how this new pass works.

show more ...


# 520407a7 13-Sep-2023 Martin Erhart <merhart@google.com>

Revert "[mlir][bufferization] Improve buffer deallocation pass"

This reverts commit 1bebb60a7565e5197d23120528f544b886b4d905.

This caused problems in downstream projects. We are reverting to give
t

Revert "[mlir][bufferization] Improve buffer deallocation pass"

This reverts commit 1bebb60a7565e5197d23120528f544b886b4d905.

This caused problems in downstream projects. We are reverting to give
them more time for integration.

show more ...


# 792caac0 13-Sep-2023 Martin Erhart <merhart@google.com>

Revert "[mlir][bufferization][NFC] Introduce BufferDeallocationOpInterface"

This reverts commit 29d86175e6a5fe956147734229dca88822415b21.

This caused problems in downstream projects. We are reverti

Revert "[mlir][bufferization][NFC] Introduce BufferDeallocationOpInterface"

This reverts commit 29d86175e6a5fe956147734229dca88822415b21.

This caused problems in downstream projects. We are reverting to give
them more time for integration.

show more ...


# 29d86175 12-Sep-2023 Martin Erhart <merhart@google.com>

[mlir][bufferization][NFC] Introduce BufferDeallocationOpInterface

This new interface allows operations to implement custom handling of ownership
values and insertion of dealloc operations which is

[mlir][bufferization][NFC] Introduce BufferDeallocationOpInterface

This new interface allows operations to implement custom handling of ownership
values and insertion of dealloc operations which is useful when an op cannot
implement the interfaces supported by default by the buffer deallocation pass
(e.g., because they are not exactly compatible or because there are some
additional semantics to it that would render the default implementations in
buffer deallocation invalid, or because no interfaces exist for this kind of
behavior and it's not worth introducing one plus a default implementation in
buffer deallocation). Additionally, it can also be used to provide more
efficient handling for a specific op than the interface based default
implementations can.

Reviewed By: springerm

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

show more ...


# 1bebb60a 12-Sep-2023 Martin Erhart <merhart@google.com>

[mlir][bufferization] Improve buffer deallocation pass

Add a new Buffer Deallocation pass replacing the old one with the goal of
inserting fewer clone operations and supporting additional use-cases.

[mlir][bufferization] Improve buffer deallocation pass

Add a new Buffer Deallocation pass replacing the old one with the goal of
inserting fewer clone operations and supporting additional use-cases.
Please refer to the Buffer Deallocation section in the updated
Bufferization.md file for more information on how this new pass works.

Reviewed By: springerm

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

show more ...


Revision tags: llvmorg-17.0.0-rc4
# 4dd744ac 30-Aug-2023 Markus Böck <markus.bock+llvm@nextsilicon.com>

Reland "[mlir] Use a type for representing branch points in `RegionBranchOpInterface`"

This reverts commit b26bb30b467b996c9786e3bd426c07684d84d406.


# b26bb30b 29-Aug-2023 Markus Böck <markus.boeck02@gmail.com>

Revert "[mlir] Use a type for representing branch points in `RegionBranchOpInterface`"

This reverts commit 024f562da67180b7be1663048c960b26c2cc16f8.

Forgot to update flang


# 024f562d 29-Aug-2023 Markus Böck <markus.boeck02@gmail.com>

[mlir] Use a type for representing branch points in `RegionBranchOpInterface`

The current implementation is not very ergonomic or descriptive: It uses `std::optional<unsigned>` where `std::nullopt`

[mlir] Use a type for representing branch points in `RegionBranchOpInterface`

The current implementation is not very ergonomic or descriptive: It uses `std::optional<unsigned>` where `std::nullopt` represents the parent op and `unsigned` is the region number.
This doesn't give us any useful methods specific to region control flow and makes the code fragile to changes due to now taking the region number into account.

This patch introduces a new type called `RegionBranchPoint`, replacing all uses of `std::optional<unsigned>` in the interface. It can be implicitly constructed from a region or a `RegionSuccessor`, can be compared with a region to check whether the branch point is branching from the parent, adds `isParent` to check whether we are coming from a parent op and adds `RegionSuccessor::parent` as a descriptive way to indicate branching from the parent.

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

show more ...


Revision tags: llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4
# 5550c821 08-May-2023 Tres Popp <tpopp@google.com>

[mlir] Move casting calls from methods to function calls

The MLIR classes Type/Attribute/Operation/Op/Value support
cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast
functionali

[mlir] Move casting calls from methods to function calls

The MLIR classes Type/Attribute/Operation/Op/Value support
cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast
functionality in addition to defining methods with the same name.
This change begins the migration of uses of the method to the
corresponding function call as has been decided as more consistent.

Note that there still exist classes that only define methods directly,
such as AffineExpr, and this does not include work currently to support
a functional cast/isa call.

Caveats include:
- This clang-tidy script probably has more problems.
- This only touches C++ code, so nothing that is being generated.

Context:
- https://mlir.llvm.org/deprecation/ at "Use the free function variants
for dyn_cast/cast/isa/…"
- Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443

Implementation:
This first patch was created with the following steps. The intention is
to only do automated changes at first, so I waste less time if it's
reverted, and so the first mass change is more clear as an example to
other teams that will need to follow similar steps.

Steps are described per line, as comments are removed by git:
0. Retrieve the change from the following to build clang-tidy with an
additional check:
https://github.com/llvm/llvm-project/compare/main...tpopp:llvm-project:tidy-cast-check
1. Build clang-tidy
2. Run clang-tidy over your entire codebase while disabling all checks
and enabling the one relevant one. Run on all header files also.
3. Delete .inc files that were also modified, so the next build rebuilds
them to a pure state.
4. Some changes have been deleted for the following reasons:
- Some files had a variable also named cast
- Some files had not included a header file that defines the cast
functions
- Some files are definitions of the classes that have the casting
methods, so the code still refers to the method instead of the
function without adding a prefix or removing the method declaration
at the same time.

```
ninja -C $BUILD_DIR clang-tidy

run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\
-header-filter=mlir/ mlir/* -fix

rm -rf $BUILD_DIR/tools/mlir/**/*.inc

git restore mlir/lib/IR mlir/lib/Dialect/DLTI/DLTI.cpp\
mlir/lib/Dialect/Complex/IR/ComplexDialect.cpp\
mlir/lib/**/IR/\
mlir/lib/Dialect/SparseTensor/Transforms/SparseVectorization.cpp\
mlir/lib/Dialect/Vector/Transforms/LowerVectorMultiReduction.cpp\
mlir/test/lib/Dialect/Test/TestTypes.cpp\
mlir/test/lib/Dialect/Transform/TestTransformDialectExtension.cpp\
mlir/test/lib/Dialect/Test/TestAttributes.cpp\
mlir/unittests/TableGen/EnumsGenTest.cpp\
mlir/test/python/lib/PythonTestCAPI.cpp\
mlir/include/mlir/IR/
```

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

show more ...


Revision tags: llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1
# 8bb5ca58 19-Mar-2023 Maya Amrami <mayaam88@gmail.com>

[mlir] Support bufferization of arith.constant to memref.global with memory space

Reviewed By: springerm

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


Revision tags: llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init
# 0a81ace0 14-Jan-2023 Kazu Hirata <kazu@google.com>

[mlir] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is pa

[mlir] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to remove #include "llvm/ADT/Optional.h".

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...


# a1fe1f5f 14-Jan-2023 Kazu Hirata <kazu@google.com>

[mlir] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optiona

[mlir] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...


Revision tags: llvmorg-15.0.7
# 1a36588e 04-Dec-2022 Kazu Hirata <kazu@google.com>

[mlir] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of ma

[mlir] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...


Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init
# 3b0dce5b 16-Jul-2022 Kazu Hirata <kazu@google.com>

Use value_or (NFC)


# c27d8152 14-Jul-2022 Kazu Hirata <kazu@google.com>

[mlir] Use value instead of getValue (NFC)


# 491d2701 13-Jul-2022 Kazu Hirata <kazu@google.com>

[mlir] Use has_value instead of hasValue (NFC)


# 136d746e 11-Jul-2022 Jacques Pienaar <jpienaar@google.com>

[mlir] Flip accessors to prefixed form (NFC)

Another mechanical sweep to keep diff small for flip to _Prefixed.


# 3b7c3a65 25-Jun-2022 Kazu Hirata <kazu@google.com>

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

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.


# aa8feeef 25-Jun-2022 Kazu Hirata <kazu@google.com>

Don't use Optional::hasValue (NFC)


Revision tags: llvmorg-14.0.6
# 037f0995 20-Jun-2022 Kazu Hirata <kazu@google.com>

[mlir] Don't use Optional::hasValue (NFC)


Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3
# af9f7d31 09-Mar-2022 Uday Bondhugula <uday@polymagelabs.com>

NFC. Clean up memref utils library

NFC. Clean up memref utils library. This library had a single function
that was completely misplaced. MemRefUtils is expected to be (also per
its comment) a librar

NFC. Clean up memref utils library

NFC. Clean up memref utils library. This library had a single function
that was completely misplaced. MemRefUtils is expected to be (also per
its comment) a library providing analysis/transforms utilities on memref
dialect ops or memref types. However, in reality it had a helper that
was depended upon by the MemRef dialect, i.e., it was a helper for the
dialect ops library and couldn't contain anything that itself depends on
the MemRef dialect. Move the single method to the memref dialect that
will now allow actual utilities depending on the memref dialect to be
placed in it.

Put findDealloc in the `memref` namespace. This is a pure move.

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

show more ...


# 06057248 08-Mar-2022 River Riddle <riddleriver@gmail.com>

[mlir][NFC] Add various includes currently transitively found in
BuiltinOps.h

These includes are going to be removed from BuiltinOps.h in a followup
when FuncOp is moved out of the Builtin dialect.

[mlir][NFC] Add various includes currently transitively found in
BuiltinOps.h

These includes are going to be removed from BuiltinOps.h in a followup
when FuncOp is moved out of the Builtin dialect. This commit
pre-emptively adds those includes to simplify the patch moving FuncOp.

show more ...


12