KKazu HirataRemove redundant string initialization (NFC)
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir] Refactor the implementation of pass crash reproducers The current implementation has several key limitations and weirdness, e.g local reproducers don't support dynamic pass pipelines, error messages don't include the passes that failed, etc. This revision refactors the implementation to support more use cases, and also be much cleaner. The main change in this revision, aside from moving the implementation out of Pass.cpp and into its own file, is the addition of a crash recovery pass instrumentation. For local reproducers, this instrumentation handles setting up the recovery context before executing each pass. For global reproducers, the instrumentation is used to provide a more detailed error message, containing information about which passes are running and on which operations. Example of new message: `` error: Failures have been detected while processing an MLIR pass pipeline note: Pipeline failed while executing [TestCrashRecoveryPass on 'module' operation: @foo]: reproducer generated at crash-recovery.mlir.tmp `` Differential Revision: https://reviews.llvm.org/D101854 | 5 年前 | |
Example: // -----// IR Dump Before LowerLinalgMicrokernels (iree-vmvx-lower-linalg-microkernels) //----- // I've been meaning to suggest this for a long time, and I think the only reason we don't have it is because we didn't used to have the getArgument() handy when printing these comments. When debugging or putting a pipeline together based on such dumps, I often find myself grepping for the argument name of the pass (which is often related but not universally). | 3 年前 | |
Remove redundant string initialization (NFC) Identified with readability-redundant-string-init. | 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:Pass] Add support for op-agnostic pass managers This commit refactors the current pass manager support to allow for operation agnostic pass managers. This allows for a series of passes to be executed on any viable pass manager root operation, instead of one specific operation type. Op-agnostic/generic pass managers only allow for adding op-agnostic passes. These types of pass managers are extremely useful when constructing pass pipelines that can apply to many different types of operations, e.g., the default inliner simplification pipeline. With the advent of interface/trait passes, this support can be used to define FunctionOpInterface pass managers, or other pass managers that effectively operate on specific interfaces/traits/etc (see #52916 for an example). Differential Revision: https://reviews.llvm.org/D123536 | 4 年前 | |
Revert "[MLIR] Provide a way to print ops in custom form on pass failure" This reverts commit daabcf5f04bbd13ac53f76ca3cc43b0d1ef64f5a. This patch still had on-going discussion that should be closed before committing. | 4 年前 | |
[mlir] (NFC) run clang-format on all files | 3 年前 | |
[mlir] Fixed ordering of pass statistics. The change makes sure the plain C string statistics names are properly ordered. Differential Revision: https://reviews.llvm.org/D130122 | 3 年前 | |
[mlir:Pass] Add support for op-agnostic pass managers This commit refactors the current pass manager support to allow for operation agnostic pass managers. This allows for a series of passes to be executed on any viable pass manager root operation, instead of one specific operation type. Op-agnostic/generic pass managers only allow for adding op-agnostic passes. These types of pass managers are extremely useful when constructing pass pipelines that can apply to many different types of operations, e.g., the default inliner simplification pipeline. With the advent of interface/trait passes, this support can be used to define FunctionOpInterface pass managers, or other pass managers that effectively operate on specific interfaces/traits/etc (see #52916 for an example). Differential Revision: https://reviews.llvm.org/D123536 | 4 年前 |