| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Expose callbacks for encoding of types/attributes [mlir] Expose a mechanism to provide a callback for encoding types and attributes in MLIR bytecode. Two callbacks are exposed, respectively, to the BytecodeWriterConfig and to the ParserConfig. At bytecode parsing/printing, clients have the ability to specify a callback to be used to optionally read/write the encoding. On failure, fallback path will execute the default parsers and printers for the dialect. Testing shows how to leverage this functionality to support back-deployment and backward-compatibility usecases when roundtripping to bytecode a client dialect with type/attributes dependencies on upstream. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D153383 | 2 年前 | |
Add support for versioning properties in MLIR bytecode [mlir] Add support for custom readProperties/writeProperties methods. Currently, operations that opt-in to adopt properties will see auto-generated readProperties/writeProperties methods to emit and parse bytecode. If a dialects opts in to use usePropertiesForAttributes, those definitions will be generated for the current definition of the op without the possibility to handle attribute versioning. The patch adds the capability for an operation to define its own read/write methods for the encoding of properties so that versioned operations can handle upgrading properties encodings. In addition to this, the patch adds an example showing versioning on NamedProperties through the dialect version API exposed by the reader. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D155340 | 2 年前 | |
[mlir:bytecode] Support lazy loading dynamically isolated regions We currently only support lazy loading for regions that statically implement the IsolatedFromAbove trait, but that limits the amount of operations that can be lazily loaded. This review lifts that restriction by computing which operations have isolated regions when numbering, allowing any operation to be lazily loaded as long as it doesn't use values defined above. Differential Revision: https://reviews.llvm.org/D156199 | 2 年前 | |
[mlir][bytecode] Implements back deployment capability for MLIR dialects (#70724) When emitting bytecode, clients can specify a target dialect version to emit in BytecodeWriterConfig. This exposes a target dialect version to the DialectBytecodeWriter, which can be queried by name and used to back-deploy attributes, types, and properties. | 2 年前 | |
[mlir][bytecode] Implements back deployment capability for MLIR dialects (#70724) When emitting bytecode, clients can specify a target dialect version to emit in BytecodeWriterConfig. This exposes a target dialect version to the DialectBytecodeWriter, which can be queried by name and used to back-deploy attributes, types, and properties. | 2 年前 | |
[mlir][bytecode] Implements back deployment capability for MLIR dialects (#70724) When emitting bytecode, clients can specify a target dialect version to emit in BytecodeWriterConfig. This exposes a target dialect version to the DialectBytecodeWriter, which can be queried by name and used to back-deploy attributes, types, and properties. | 2 年前 | |
[mlir][bytecode] Implements back deployment capability for MLIR dialects (#70724) When emitting bytecode, clients can specify a target dialect version to emit in BytecodeWriterConfig. This exposes a target dialect version to the DialectBytecodeWriter, which can be queried by name and used to back-deploy attributes, types, and properties. | 2 年前 | |
[mlir][bytecode] Implements back deployment capability for MLIR dialects (#70724) When emitting bytecode, clients can specify a target dialect version to emit in BytecodeWriterConfig. This exposes a target dialect version to the DialectBytecodeWriter, which can be queried by name and used to back-deploy attributes, types, and properties. | 2 年前 | |
Fix MLIR bytecode reading of i0 IntegerAttr The move of the bytecode serialization to be tablegen driven in https://reviews.llvm.org/D144820 added a new condition in the reading path that forbid 0-sized integer, even though we still produce them. Fix #62920 Differential Revision: https://reviews.llvm.org/D151372 | 3 年前 | |
[mlir][bytecode] Fix external resource bytecode parsing (#97650) The key was being dropped for external resources because they aren't present in the dialect resource name mapper. | 2 年前 | |
Fix bytecode reader/writer on big-endian platforms This makes the bytecode reader/writer work on big-endian platforms. The only problem was related to encoding of multi-byte integers, where both reader and writer code make implicit assumptions about endianness of the host platform. This fixes the current test failures on s390x, and in addition allows to remove the UNSUPPORTED markers from all other bytecode-related test cases - they now also all pass on s390x. Also adding a GFAIL_SKIP to the MultiModuleWithResource unit test, as this still fails due to an unrelated endian bug regarding decoding of external resources. Differential Revision: https://reviews.llvm.org/D153567 Reviewed By: mehdi_amini, jpienaar, rriddle | 3 年前 | |
Finish renaming getOperandSegmentSizeAttr() from operand_segment_sizes to operandSegmentSizes This renaming started with the native ODS support for properties, this is completing it. A mass automated textual rename seems safe for most codebases. Drop also the ods prefix to keep the accessors the same as they were before this change: properties.odsOperandSegmentSizes reverts back to: properties.operandSegementSizes The ODS prefix was creating divergence between all the places and make it harder to be consistent. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D157173 | 2 年前 | |
[MLIR] print/parse resource handle key quoted and escaped (#119746) resource keys have the problem that you can’t parse them from mlir assembly if they have special or non-printable characters, but nothing prevents you from specifying such a key when you create e.g. a DenseResourceElementsAttr, and it works fine in other ways, including bytecode emission and parsing this PR solves the parsing by quoting and escaping keys with special or non-printable characters in mlir assembly, in the same way as symbols, e.g.: module attributes { fst = dense_resource<resource_fst> : tensor<2xf16>, snd = dense_resource<"resource\09snd"> : tensor<2xf16> } {} {-# dialect_resources: { builtin: { resource_fst: "0x0200000001000200", "resource\09snd": "0x0200000008000900" } } #-} by not quoting keys without special or non-printable characters, the change is effectively backwards compatible the change is tested by: 1. adding a test with a dense resource handle key with special characters to dense-resource-elements-attr.mlir 2. adding special and unprintable characters to some resource keys in the existing lit tests pretty-resources-print.mlir and mlir/test/Bytecode/resources.mlir | 1 年前 | |
[mlir][bytecode] Add bytecode writer config API to skip serialization of resources (#71991) When serializing to bytecode, users can select the option to elide resources from the bytecode file. This will instruct the bytecode writer to serialize only the key and resource kind, while skipping serialization of the data buffer. At parsing, the IR is built in memory with valid (but empty) resource handlers. | 2 年前 | |
Fix MLIR bytecode reader for unregistered dialects At the moment we accept (in tests) unregistered dialects and in particular: "new_processor_id_and_range"() where there is no . separator. We probably will remove support for this from the parser, but for now we're adding compatibility support in the reader. Differential Revision: https://reviews.llvm.org/D151386 | 3 年前 | |
Preserve use-list orders in mlir bytecode This patch implements a mechanism to read/write use-list orders from/to the mlir bytecode format. When producing bytecode, use-list orders are appended to each value of the IR. When reading bytecode, use-lists orders are loaded in memory and used at the end of parsing to sort the existing use-list chains. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D149755 | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 |