Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5
# a5757c5b 19-Apr-2024 Christian Sigg <chsigg@users.noreply.github.com>

Switch member calls to `isa/dyn_cast/cast/...` to free function calls. (#89356)

This change cleans up call sites. Next step is to mark the member
functions deprecated.

See https://mlir.llvm.org/

Switch member calls to `isa/dyn_cast/cast/...` to free function calls. (#89356)

This change cleans up call sites. Next step is to mark the member
functions deprecated.

See https://mlir.llvm.org/deprecation and
https://discourse.llvm.org/t/preferred-casting-style-going-forward.

show more ...


Revision tags: llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1
# a9304edf 05-Mar-2024 Thomas Preud'homme <thomas.preudhomme@arm.com>

Fix remaining build failures with GCC 8.3 (#83266)

When compiling for GCC 8.x (< 8.4), SFINAE is disabled for
iterator_range constructor causing ambiguous resolution to construct an
OperandRange f

Fix remaining build failures with GCC 8.3 (#83266)

When compiling for GCC 8.x (< 8.4), SFINAE is disabled for
iterator_range constructor causing ambiguous resolution to construct an
OperandRange from a MutableOperatorRange, even in the presence of a
static_cast<OperatorRange>. This adds an explicit conversion method to
lift the ambiguity.

Tested with a full MLIR build with GCC 8.3.

show more ...


Revision tags: 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, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1
# 6923a315 19-Sep-2023 Matthias Springer <me@m-sp.org>

[mlir][IR] Change `MutableArrayRange` to enumerate `OpOperand &` (#66622)

In line with #66515, change `MutableArrayRange::begin`/`end` to
enumerate `OpOperand &` instead of `Value`. Also remove
`F

[mlir][IR] Change `MutableArrayRange` to enumerate `OpOperand &` (#66622)

In line with #66515, change `MutableArrayRange::begin`/`end` to
enumerate `OpOperand &` instead of `Value`. Also remove
`ForOp::getIterOpOperands`/`setIterArg`, which are now redundant.

Note: `MutableOperandRange` cannot be made a derived class of
`indexed_accessor_range_base` (like `OperandRange`), because
`MutableOperandRange::assign` can change the number of operands in the
range.

show more ...


Revision tags: 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 ...


# 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 ...