|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, 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, 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, llvmorg-17.0.0-rc4, 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, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, 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, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, 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, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
| #
14ecafd0 |
| 23-Mar-2022 |
Chia-hung Duan <[email protected]> |
[mlir] Make OpBuilder::createOperation to accept raw inputs
This provides a way to create an operation without manipulating OperationState directly. This is useful for creating unregistered ops.
Re
[mlir] Make OpBuilder::createOperation to accept raw inputs
This provides a way to create an operation without manipulating OperationState directly. This is useful for creating unregistered ops.
Reviewed By: rriddle, mehdi_amini
Differential Revision: https://reviews.llvm.org/D120787
show more ...
|
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
| #
676bfb2a |
| 10-Jan-2022 |
River Riddle <[email protected]> |
[mlir] Refactor ShapedType into an interface
ShapedType was created in a time before interfaces, and is one of the earliest type base classes in the ecosystem. This commit refactors ShapedType into
[mlir] Refactor ShapedType into an interface
ShapedType was created in a time before interfaces, and is one of the earliest type base classes in the ecosystem. This commit refactors ShapedType into an interface, which is what it would have been if interfaces had existed at that time. The API of ShapedType and it's derived classes are essentially untouched by this refactor, with the exception being the API surrounding kDynamicIndex (which requires a sole home).
For now, the API of ShapedType and its name have been kept as consistent to the current state of the world as possible (to help with potential migration churn, among other reasons). Moving forward though, we should look into potentially restructuring its API and possible its name as well (it should really have "Interface" at the end like other interfaces at the very least).
One other potentially interesting note is that I've attached the ShapedType::Trait to TensorType/BaseMemRefType to act as mixins for the ShapedType API. This is kind of weird, but allows for sharing the same API (i.e. preventing API loss from the transition from base class -> Interface). This inheritance doesn't affect any of the derived classes, it is just for API mixin.
Differential Revision: https://reviews.llvm.org/D116962
show more ...
|
| #
cafaa350 |
| 06-Jan-2022 |
Alex Zinenko <[email protected]> |
[mlir] Make it possible to directly supply constant values to LLVM GEPOp
In LLVM IR, the GEP indices that correspond to structures are required to be i32 constants. MLIR models constants as just val
[mlir] Make it possible to directly supply constant values to LLVM GEPOp
In LLVM IR, the GEP indices that correspond to structures are required to be i32 constants. MLIR models constants as just values defined by special operations, and there is no verification that it is the case for structure indices in GEP. Furthermore, some common transformations such as control flow simplification may lead to the operands becoming non-constant. Make it possible to directly supply constant values to LLVM GEPOp to guarantee they remain constant until the translation to LLVM IR. This is not yet a requirement and the verifier is not modified, this will be introduced separately.
Reviewed By: wsmoses
Differential Revision: https://reviews.llvm.org/D116757
show more ...
|
| #
e4853be2 |
| 02-Jan-2022 |
Mehdi Amini <[email protected]> |
Apply clang-tidy fixes for performance-for-range-copy to MLIR (NFC)
|
|
Revision tags: llvmorg-13.0.1-rc1 |
|
| #
e41ebbec |
| 11-Oct-2021 |
Vladislav Vinogradov <[email protected]> |
[mlir][RFC] Refactor layout representation in MemRefType
The change is based on the proposal from the following discussion: https://llvm.discourse.group/t/rfc-memreftype-affine-maps-list-vs-single-i
[mlir][RFC] Refactor layout representation in MemRefType
The change is based on the proposal from the following discussion: https://llvm.discourse.group/t/rfc-memreftype-affine-maps-list-vs-single-item/3968
* Introduce `MemRefLayoutAttr` interface to get `AffineMap` from an `Attribute` (`AffineMapAttr` implements this interface). * Store layout as a single generic `MemRefLayoutAttr`.
This change removes the affine map composition feature and related API. Actually, while the `MemRefType` itself supported it, almost none of the upstream can work with more than 1 affine map in `MemRefType`.
The introduced `MemRefLayoutAttr` allows to re-implement this feature in a more stable way - via separate attribute class.
Also the interface allows to use different layout representations rather than affine maps. For example, the described "stride + offset" form, which is currently supported in ASM parser only, can now be expressed as separate attribute.
Reviewed By: ftynse, bondhugula
Differential Revision: https://reviews.llvm.org/D111553
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init |
|
| #
ed1f149b |
| 12-Jul-2021 |
Frederik Gossen <[email protected]> |
[MLIR][StandardToLLVM] Move `copyUnrankedDescriptors` to pattern
Make the function `copyUnrankedDescriptors` accessible in `ConvertToLLVMPattern`.
Differential Revision: https://reviews.llvm.org/D1
[MLIR][StandardToLLVM] Move `copyUnrankedDescriptors` to pattern
Make the function `copyUnrankedDescriptors` accessible in `ConvertToLLVMPattern`.
Differential Revision: https://reviews.llvm.org/D105810
show more ...
|
| #
684dfe8a |
| 07-Jul-2021 |
Alex Zinenko <[email protected]> |
[mlir] factor out ConvertToLLVMPattern
This class and classes that extend it are general utilities for any dialect that is being converted into the LLVM dialect. They are in no way specific to Stand
[mlir] factor out ConvertToLLVMPattern
This class and classes that extend it are general utilities for any dialect that is being converted into the LLVM dialect. They are in no way specific to Standard-to-LLVM conversion and should not make their users depend on it.
Reviewed By: nicolasvasilache
Differential Revision: https://reviews.llvm.org/D105542
show more ...
|