| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir][VectorOps] Support string literals in vector.print (#68695) Printing strings within integration tests is currently quite annoyingly verbose, and can't be tucked into shared helpers as the types depend on the length of the string: llvm.mlir.global internal constant @hello_world("Hello, World!\0") func.func @entry() { %0 = llvm.mlir.addressof @hello_world : !llvm.ptr<array<14 x i8>> %1 = llvm.mlir.constant(0 : index) : i64 %2 = llvm.getelementptr %0[%1, %1] : (!llvm.ptr<array<14 x i8>>, i64, i64) -> !llvm.ptr<i8> llvm.call @printCString(%2) : (!llvm.ptr<i8>) -> () return } So this patch adds a simple extension to vector.print to simplify this: func.func @entry() { // Print a vector of characters ;) vector.print str "Hello, World!" return } Most of the logic for this is now shared with cf.assert which already does something similar. Depends on #68694 | 2 年前 | |
[mlir] replace llvm.mlir.cast with unrealized_conversion_cast The dialect-specific cast between builtin (ex-standard) types and LLVM dialect types was introduced long time before built-in support for unrealized_conversion_cast. It has a similar purpose, but is restricted to compatible builtin and LLVM dialect types, which may hamper progressive lowering and composition with types from other dialects. Replace llvm.mlir.cast with unrealized_conversion_cast, and drop the operation that became unnecessary. Also make unrealized_conversion_cast legal by default in LLVMConversionTarget as the majority of convesions using it are partial conversions that actually want the casts to persist in the IR. The standard-to-llvm conversion, which is still expected to run last, cleans up the remaining casts standard-to-llvm conversion, which is still expected to run last, cleans up the remaining casts Reviewed By: nicolasvasilache Differential Revision: https://reviews.llvm.org/D105880 | 5 年前 | |
[mlir] factor out common parts of the converstion to the LLVM dialect "Standard-to-LLVM" conversion is one of the oldest passes in existence. It has become quite large due to the size of the Standard dialect itself, which is being split into multiple smaller dialects. Furthermore, several conversion features are useful for any dialect that is being converted to the LLVM dialect, which, without this refactoring, creates a dependency from those conversions to the "standard-to-llvm" one. Put several of the reusable utilities from this conversion to a separate library, namely: - type converter from builtin to LLVM dialect types; - utility for building and accessing values of LLVM structure type; - utility for building and accessing values that represent memref in the LLVM dialect; - lowering options applicable everywhere. Additionally, remove the type wrapping/unwrapping notion from the type converter that is no longer relevant since LLVM types has been reimplemented as first-class MLIR types. Reviewed By: pifon2a Differential Revision: https://reviews.llvm.org/D105534 | 5 年前 | |
[mlir][LLVM][NFC] Simplify computeSizes function (#153588) Rename computeSizes to computeSize and make it compute just a single size. This is in preparation of adding 1:N support to the Func->LLVM lowering patterns. | 1 年前 | |
[mlir] factor out common parts of the converstion to the LLVM dialect "Standard-to-LLVM" conversion is one of the oldest passes in existence. It has become quite large due to the size of the Standard dialect itself, which is being split into multiple smaller dialects. Furthermore, several conversion features are useful for any dialect that is being converted to the LLVM dialect, which, without this refactoring, creates a dependency from those conversions to the "standard-to-llvm" one. Put several of the reusable utilities from this conversion to a separate library, namely: - type converter from builtin to LLVM dialect types; - utility for building and accessing values of LLVM structure type; - utility for building and accessing values that represent memref in the LLVM dialect; - lowering options applicable everywhere. Additionally, remove the type wrapping/unwrapping notion from the type converter that is no longer relevant since LLVM types has been reimplemented as first-class MLIR types. Reviewed By: pifon2a Differential Revision: https://reviews.llvm.org/D105534 | 5 年前 | |
Add 'exact' flag to arith.shrui/shrsi/divsi/divui operations (#165923) This MR adds support for the exact flag to the arith.shrui/shrsi/divsi/divui operations. The semantics are identical to those of the LLVM dialect and the LLVM language reference. This MR also modifies the mechanism for converting arith dialect **attributes** to corresponding **properties** in the LLVM dialect. (As a specific example, the integer overflow flags nsw/nuw are **properties** in the LLVM dialect, as opposed to attributes.) Previously, attribute converter classes were required to have a specific method to support integer overflow flags: C++ template <typename SourceOp, typename TargetOp> class AttrConvertPassThrough { public: ... LLVM::IntegerOverflowFlags getOverflowFlags() const { return LLVM::IntegerOverflowFlags::none; } }; This method was required, even for arith source operations that did not use integer overflow flags (e.g. AttrConvertFastMathToLLVM). This MR modifies the interface required by arith dialect attribute converters to instead provide a (possibly NULL) properties attribute: C++ template <typename SourceOp, typename TargetOp> class AttrConvertPassThrough { public: ... Attribute getPropAttr() const { return {}; } }; For arith operations with attributes that map to LLVM dialect **properties**, the attribute converter can create a DictionaryAttr containing target properties and return that attribute from the attribute converter's getPropAttr() method. The arith attribute conversion framework will set the propertiesAttr of an OperationState, and the target operation's setPropertiesFromAttr() method will be invoked to set the properties when the target operation is created. The AttrConvertOverflowToLLVM class in this MR uses the new approach. | 9 个月前 | |
[MLIR] Apply clang-tidy fixes for bugprone-argument-comment in PrintCallHelper.cpp (NFC) | 10 个月前 | |
[mlir][NFC] update Conversion create APIs (6/n) (#149888) See https://github.com/llvm/llvm-project/pull/147168 for more info. | 1 年前 | |
[mlir][LLVM] FuncToLLVM: Add 1:N type conversion support (#153823) Add support for 1:N type conversions to the FuncToLLVM lowering patterns. This commit does not change the lowering of any types (such as MemRefType). It just sets up the infrastructure, such that 1:N type conversions can be used during FuncToLLVM. Note: When the converted result types of a func.func have more than 1 type, then the results are wrapped in an llvm.struct. That's because llvm.func does not support multiple result values. This "wrapping" was already implemented for cases where the original func.func has multiple results. With 1:N conversions, even a single result can now expand to multiple converted results, triggering the same wrapping mechanism. The test cases are exercised with both the old and the new no-rollback conversion driver. | 1 年前 | |
Add 'exact' flag to arith.shrui/shrsi/divsi/divui operations (#165923) This MR adds support for the exact flag to the arith.shrui/shrsi/divsi/divui operations. The semantics are identical to those of the LLVM dialect and the LLVM language reference. This MR also modifies the mechanism for converting arith dialect **attributes** to corresponding **properties** in the LLVM dialect. (As a specific example, the integer overflow flags nsw/nuw are **properties** in the LLVM dialect, as opposed to attributes.) Previously, attribute converter classes were required to have a specific method to support integer overflow flags: C++ template <typename SourceOp, typename TargetOp> class AttrConvertPassThrough { public: ... LLVM::IntegerOverflowFlags getOverflowFlags() const { return LLVM::IntegerOverflowFlags::none; } }; This method was required, even for arith source operations that did not use integer overflow flags (e.g. AttrConvertFastMathToLLVM). This MR modifies the interface required by arith dialect attribute converters to instead provide a (possibly NULL) properties attribute: C++ template <typename SourceOp, typename TargetOp> class AttrConvertPassThrough { public: ... Attribute getPropAttr() const { return {}; } }; For arith operations with attributes that map to LLVM dialect **properties**, the attribute converter can create a DictionaryAttr containing target properties and return that attribute from the attribute converter's getPropAttr() method. The arith attribute conversion framework will set the propertiesAttr of an OperationState, and the target operation's setPropertiesFromAttr() method will be invoked to set the properties when the target operation is created. The AttrConvertOverflowToLLVM class in this MR uses the new approach. | 9 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 年前 | ||
| 5 年前 | ||
| 5 年前 | ||
| 1 年前 | ||
| 5 年前 | ||
| 9 个月前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 9 个月前 |