| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[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:LSP] Add a quickfix code action for inserting expected-* diagnostic checks This allows for automatically inserting expected checks for parser and verifier diagnostics, which simplifies the workflow when building new dialect constructs or extending existing ones. Differential Revision: https://reviews.llvm.org/D130152 | 3 年前 | |
[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] Refactor pass crash reproducer generation to be an assembly resource We currently generate reproducer configurations using a comment placed at the top of the generated .mlir file. This is kind of hacky given that comments have no semantic context in the source file and can easily be dropped. This strategy also wouldn't work if/when we have a bitcode format. This commit switches to using an external assembly resource, which is verifiable/can work with a hypothetical bitcode naturally/and removes the awkward processing from mlir-opt for splicing comments and re-applying command line options. With the removal of command line munging, this opens up new possibilities for executing reproducers in memory. Differential Revision: https://reviews.llvm.org/D126447 | 3 年前 | |
[mlir] Don't use Optional::hasValue (NFC) | 3 年前 | |
[mlir][NFC] Move Parser.h to Parser/ There is no reason for this file to be at the top-level, and its current placement predates the Parser/ folder's existence. Differential Revision: https://reviews.llvm.org/D121024 | 4 年前 | |
[mlir] Add enableSplitting and insertMarkerInOutput options to splitAndProcessBuffer enableSplitting simply enables/disables whether we should split or use the full buffer. insertMarkerInOutput toggles if split markers should be inserted in between prcessed output chunks. These options allow for merging the duplicate code paths we have when splitting is optional. Differential Revision: https://reviews.llvm.org/D128764 | 3 年前 | |
[mlir:LSP] Switch document sync mode to Incremental This is much more efficient over the full mode, as it only requires sending smalls chunks of files. It also works around a weird command ordering issue (full document updates are being sent after other commands like code completion) in newer versions of vscode. Differential Revision: https://reviews.llvm.org/D126032 | 3 年前 | |
[mlir][Tablegen-LSP] Add support for a basic TableGen language server This follows the same general structure of the MLIR and PDLL language servers. This commits adds the basic functionality for setting up the server, and initially only supports providing diagnostics. Followon commits will build out more comprehensive behavior. Realistically this should eventually live in llvm/, but building in MLIR is an easier initial step given that: * All of the necessary LSP functionality is already here * It allows for proving out useful language features (e.g. compilation databases) without affecting wider scale tablegen users * MLIR has a vscode extension that can immediately take advantage of it Differential Revision: https://reviews.llvm.org/D125440 | 4 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 4 年前 |