| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir][python] improve usability of Python affine construct bindings - Provide the operator overloads for constructing (semi-)affine expressions in Python by combining existing expressions with constants. - Make AffineExpr, AffineMap and IntegerSet hashable in Python. - Expose the AffineExpr composition functionality. Reviewed By: gysit, aoyal Differential Revision: https://reviews.llvm.org/D113010 | 4 年前 | |
[mlir][linalg][python] Add attribute support to the OpDSL. Extend the OpDSL with index attributes. After tensors and scalars, index attributes are the third operand type. An index attribute represents a compile-time constant that is limited to index expressions. A use cases are the strides and dilations defined by convolution and pooling operations. The patch only updates the OpDSL. The C++ yaml codegen is updated by a followup patch. Differential Revision: https://reviews.llvm.org/D104711 | 4 年前 | |
[MLIR] Add function to create Float16 array attribute This patch adds a new function mlirDenseElementsAttrFloat16Get(), which accepts the shaped type, the number of Float16 values, and a pointer to an array of Float16 values, each of which is a uint16_t value. This commit is repeating https://reviews.llvm.org/D123981 + #761 but for Float16 Differential Revision: https://reviews.llvm.org/D130069 | 3 年前 | |
[mlir] Structured transforms: introduce op splitting Introduce a new transformation on structured ops that splits the iteration space into two parts along the specified dimension. The index at which the splitting happens may be static or dynamic. This transformation can be seen as a rudimentary form of index-set splitting that only supports the splitting along hyperplanes parallel to the iteration space hyperplanes, and is therefore decomposable into per-dimension application. It is a key low-level transformation that enables independent scheduling for different parts of the iteration space of the same op, which hasn't been possible previously. It may be used to implement, e.g., multi-sized tiling. In future, peeling can be implemented as a combination of split-off amount computation and splitting. The transformation is conceptually close to tiling in its separation of the iteration and data spaces, but cannot be currently implemented on top of TilingInterface as the latter does not properly support linalg.index offsetting. Note that the transformation intentionally bypasses folding of tensor.extract_slice operations when creating them as this folding was found to prevent repeated splitting of the same operation because due to internal assumptions about extract/insert_slice combination in dialect utilities. Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D129090 | 3 年前 | |
[mlir] Add MLIR-C dylib. Per discussion on discord and various feature requests across bindings (Haskell and Rust bindings authors have asked me directly), we should be building a link-ready MLIR-C dylib which exports the C API and can be used without linking to anything else. This patch: * Adds a new MLIR-C aggregate shared library (libMLIR-C.so), which is similar in name and function to libLLVM-C.so. * It is guarded by the new CMake option MLIR_BUILD_MLIR_C_DYLIB, which has a similar purpose/name to the LLVM_BUILD_LLVM_C_DYLIB option. * On all platforms, this will work with both static, BUILD_SHARED_LIBS, and libMLIR builds, if supported: * In static builds: libMLIR-C.so will export the CAPI symbols and statically link all dependencies into itself. * In BUILD_SHARED_LIBS: libMLIR-C.so will export the CAPI symbols and have dynamic dependencies on implementation shared libraries. * In libMLIR.so mode: same as static. libMLIR.so was not finished for actual linking use within the project. An eventual relayering so that libMLIR-C.so depends on libMLIR.so is possible but requires first re-engineering the latter to use the aggregate facility. * On Linux, exported symbols are filtered to only the CAPI. On others (MacOS, Windows), all symbols are exported. A CMake status is printed unless if global visibility is hidden indicating that this has not yet been implemented. The library should still work, but it will be larger and more likely to conflict until fixed. Someone should look at lifting the corresponding support from libLLVM-C.so and adapting. Or, for special uses, just build with -DCMAKE_CXX_VISIBILITY_PRESET=hidden -DCMAKE_C_VISIBILITY_PRESET=hidden. * Includes fixes to execution engine symbol export macros to enable default visibility. Without this, the advice to use hidden visibility would have resulted in test failures and unusable execution engine support libraries. Differential Revision: https://reviews.llvm.org/D113731 | 4 年前 | |
[mlir] Move diagnostic handlers instead of copying This also allows using unique_ptr instead of shared_ptr for the CAPI user data. NFCI. | 4 年前 | |
[mlir][capi] Add DialectRegistry to MLIR C-API Exposes mlir::DialectRegistry to the C API as MlirDialectRegistry along with helper functions. A hook has been added to MlirDialectHandle that inserts the dialect into a registry. A future possible change is removing mlirDialectHandleRegisterDialect in favor of using mlirDialectHandleInsertDialect, which it is now implemented with. Differential Revision: https://reviews.llvm.org/D118293 | 4 年前 | |
[mlir] Refactor the Parser library in preparation for an MLIR binary format The current Parser library is solely focused on providing API for the textual MLIR format, but MLIR will soon also provide a binary format. This commit renames the current Parser library to AsmParser to better correspond to what the library is actually intended for. A new Parser library is added which will act as a unified parser interface between both text and binary formats. Most parser clients are unaffected, given that the unified interface is essentially the same as the current interface. Only clients that rely on utilizing the AsmParserState, or those that want to parse Attributes/Types need to be updated to point to the AsmParser library. Differential Revision: https://reviews.llvm.org/D129605 | 3 年前 | |
[mlir] Add C API for IntegerSet Depends On D95357 Reviewed By: stellaraccident Differential Revision: https://reviews.llvm.org/D95368 | 5 年前 | |
[mlir][capi] Add external pass creation to MLIR C-API Adds the ability to create external passes using the C-API. This allows passes to be written in C or languages that use the C-bindings. Differential Revision: https://reviews.llvm.org/D121866 | 4 年前 | |
[mlir][capi] Add external pass creation to MLIR C-API Adds the ability to create external passes using the C-API. This allows passes to be written in C or languages that use the C-bindings. Differential Revision: https://reviews.llvm.org/D121866 | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 5 年前 | ||
| 4 年前 | ||
| 4 年前 |