| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Add an action for each iteration of the GreedyPatternRewriteDriver Differential Revision: https://reviews.llvm.org/D149101 | 3 年前 | |
Add an action for each iteration of the GreedyPatternRewriteDriver Differential Revision: https://reviews.llvm.org/D149101 | 3 年前 | |
[mlir] Add an Observer for profiling actions to a stream. (#67251) The profile is stored in the Chrome trace event format. Added the --profile-action-to=<file> option to mlir-opt. | 2 年前 | |
[MLIR][Pass] Full & deterministic diagnostics (#110311) Today, when the pass infra schedules a pass/nested-pipeline on a set of ops, it exits early as soon as it fails on one of the ops. This leads to non-exhaustive, and more importantly, non-deterministic error reporting (under async). This PR removes the early termination behavior so that all ops have a chance to run through the current pass/nested-pipeline, and all errors are reported (async diagnostics are already ordered). This guarantees deterministic & full error reporting. As a result, it's also no longer necessary to -split-input-file with one error per split when testing with -verify-diagnostics. | 1 年前 | |
[LSAN] Disable leaks in test using environment variables instead of not running them with ASAN. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D145615 | 3 年前 | |
[mlir][Pass] Enable the option for reproducer generation without crashing (#75421) This PR adds API makeReproducer and cl::opt flag --mlir-generate-reproducer=<filename> in order to allow for mlir reproducer dumps even when the pipeline doesn't crash. This PR also decouples the code that handles generation of an MLIR reproducer from the crash recovery portion. The purpose is to allow for generating reproducers outside of the context of a compiler crash. This will be useful for frameworks and runtimes that use MLIR where it is needed to reproduce the pipeline behavior for reasons outside of diagnosing crashes. An example is for diagnosing performance issues using offline tools, where being able to dump the reproducer from a runtime compiler would be helpful. | 2 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir] implement -verify-diagnostics=only-expected (#135131) This PR implements verify-diagnostics=only-expected which is a "best effort" verification - i.e., unexpecteds and near-misses will not be considered failures. The purpose is to enable narrowly scoped checking of verification remarks (just as we have for lit where only a subset of lines get CHECKed). | 1 年前 | |
[mlir] implement -verify-diagnostics=only-expected (#135131) This PR implements verify-diagnostics=only-expected which is a "best effort" verification - i.e., unexpecteds and near-misses will not be considered failures. The purpose is to enable narrowly scoped checking of verification remarks (just as we have for lit where only a subset of lines get CHECKed). | 1 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir] Catch the case using ir print without disabling multithread -mlir-print-ir-module-scope option cannot be used without disabling multithread for pass manager. For the usability, we can throw a validation error in mlir-opt instead of assertion failure. Issue: https://github.com/llvm/llvm-project/issues/61578 Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D146785 | 3 年前 | |
[mlir][Pass] Fix crash when applying a pass to an optional interface (#169262) Interfaces can be optional: whether an op implements an interface or not can depend on the state of the operation. `` // An optional code block for adding additional "classof" logic. This can // be used to better enable "optional" interfaces, where an entity only // implements the interface if some dynamic characteristic holds. // $_attr/$_op/$_type may be used to refer to an instance of the // interface instance being checked. code extraClassOf = ""; ` The current Pass::canScheduleOn(RegisteredOperationName) is insufficient. This commit adds an additional overload to inspect Operation *. This commit fixes a crash when scheduling an InterfacePass` for an optional interface on an operation that does not actually implement the interface. This is a re-upload of #168499, which was reverted. | 8 个月前 | |
| 1 年前 | ||
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[mlir] Enhance TimingManager Printing Flexibility (#85821) Revise the printing functionality of TimingManager to accommodate various output formats. At present, TimingManager is limited to outputting data solely in plain text format. To overcome this limitation, I have introduced an abstract class that serves as the foundation for printing. This approach allows users to implement additional output formats by extending this abstract class. As part of this update, I have integrated support for JSON as a new output format, enhancing the ease of parsing for subsequent processing scripts. | 2 年前 | |
[mlir][Pass] Fix crash when applying a pass to an optional interface (#169262) Interfaces can be optional: whether an op implements an interface or not can depend on the state of the operation. `` // An optional code block for adding additional "classof" logic. This can // be used to better enable "optional" interfaces, where an entity only // implements the interface if some dynamic characteristic holds. // $_attr/$_op/$_type may be used to refer to an instance of the // interface instance being checked. code extraClassOf = ""; ` The current Pass::canScheduleOn(RegisteredOperationName) is insufficient. This commit adds an additional overload to inspect Operation *. This commit fixes a crash when scheduling an InterfacePass` for an optional interface on an operation that does not actually implement the interface. This is a re-upload of #168499, which was reverted. | 8 个月前 | |
[MLIR] Make PassPipelineOptions virtually inheriting from PassOptions to allow diamond inheritance (#146370) ## Problem Given 3 pipelines, A, B, and a superset pipeline AB that runs both the A & B pipelines, it is not easy to manage their options - one needs to manually recreate all options from A and B into AB, and maintain them. This is tedious. ## Proposed solution Ideally, AB options class inherits from both A and B options, making the maintenance effortless. Today though, this causes problems as their base classes PassPipelineOptions<A> and PassPipelineOptions<B> both inherit from mlir::detail::PassOptions, leading to the so called "diamond inheritance problem", i.e. multiple definitions of the same symbol, in this case parseFromString that is defined in mlir::detail::PassOptions. Visually, the inheritance looks like this: mlir::detail::PassOptions ↑ ↑ | | PassPipelineOptions<A> PassPipelineOptions<B> ↑ ↑ | | AOptions BOptions ↑ ↑ +---------+--------+ | ABOptions A proposed fix is to use the common solution to the diamond inheritance problem - virtual inheritance. | 11 个月前 | |
Pretty print on -dump-pass-pipeline (#143223) This PR makes dump-pass-pipeline pretty-print the dumped pipeline. For large pipelines the current behavior produces a wall of text that is hard to visually navigate. For the command bash mlir-opt --pass-pipeline="builtin.module(flatten-memref, expand-strided-metadata,func.func(arith-expand,func.func(affine-scalrep)))" --dump-pass-pipeline Before: bash Pass Manager with 3 passes: builtin.module(flatten-memref,expand-strided-metadata,func.func(arith-expand{include-bf16=false include-f8e8m0=false},func.func(affine-scalrep))) After: bash Pass Manager with 3 passes: builtin.module( flatten-memref, expand-strided-metadata, func.func( arith-expand{include-bf16=false include-f8e8m0=false}, func.func( affine-scalrep ) ) ) Another nice feature of this is that the pretty-printed string can still be copy/pasted into -pass-pipeline using a quote: bash $ bin/mlir-opt --dump-pass-pipeline test.mlir --pass-pipeline=' builtin.module( flatten-memref, expand-strided-metadata, func.func( arith-expand{include-bf16=false include-f8e8m0=false}, func.func( affine-scalrep ) ) )' --------- Co-authored-by: Jeremy Kun <j2kun@users.noreply.github.com> | 1 年前 | |
[mlir][Pass] Fix dropped statistics with nested adaptors. When running in parallel, nesting more than once caused statistics to be dropped. Fix by also preparing "async" pass managers before merging, as they may also have "async" pass managers within. Add test checking reported statistics have expected values with and without threading enabled. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D139459 | 3 年前 | |
[mlir][Pass] Include anchor op in -pass-pipeline In D134622 the printed form of a pass manager is changed to include the name of the op that the pass manager is anchored on. This updates the -pass-pipeline argument format to include the anchor op as well, so that the printed form of a pipeline can be directly passed to -pass-pipeline. In most cases this requires updating -pass-pipeline='pipeline' to -pass-pipeline='builtin.module(pipeline)'. This also fixes an outdated assert that prevented running a PassManager anchored on 'any'. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D134900 | 3 年前 | |
[MLIR] Implement remark emitting policies in MLIR (#161202) This update introduces two new remark emitting policies: 1. RemarkEmittingPolicyAll, which emits all remarks, 2. RemarkEmittingPolicyFinal, which only emits final remarks after processing. The RemarkEngine is modified to support these policies, allowing for more flexible remark handling based on user configuration. PR also adds flag to mlir-opt --remark-policy=<value> - Specify the policy for remark output. =all - Print all remarks =final - Print final remarks Relanding https://github.com/llvm/llvm-project/pull/160526 This PR requires RemarkEngine to be finalize manually. So here is usage: MLIRContext ctx; ctx.setRemarkEngine(...) ... ctx.getRemarkEngine().shutdown() <-- PR adds this, it is required when the emission policy is final | 9 个月前 | |
[MLIR] Add remark flags to mlir-opt (#156825) | 10 个月前 | |
Pretty print on -dump-pass-pipeline (#143223) This PR makes dump-pass-pipeline pretty-print the dumped pipeline. For large pipelines the current behavior produces a wall of text that is hard to visually navigate. For the command bash mlir-opt --pass-pipeline="builtin.module(flatten-memref, expand-strided-metadata,func.func(arith-expand,func.func(affine-scalrep)))" --dump-pass-pipeline Before: bash Pass Manager with 3 passes: builtin.module(flatten-memref,expand-strided-metadata,func.func(arith-expand{include-bf16=false include-f8e8m0=false},func.func(affine-scalrep))) After: bash Pass Manager with 3 passes: builtin.module( flatten-memref, expand-strided-metadata, func.func( arith-expand{include-bf16=false include-f8e8m0=false}, func.func( affine-scalrep ) ) ) Another nice feature of this is that the pretty-printed string can still be copy/pasted into -pass-pipeline using a quote: bash $ bin/mlir-opt --dump-pass-pipeline test.mlir --pass-pipeline=' builtin.module( flatten-memref, expand-strided-metadata, func.func( arith-expand{include-bf16=false include-f8e8m0=false}, func.func( affine-scalrep ) ) )' --------- Co-authored-by: Jeremy Kun <j2kun@users.noreply.github.com> | 1 年前 | |
[MLIR][Operation] Fix isBeforeInBlock crash bug mentioned in https://github.com/llvm/llvm-project/issues/60909 (#101172) # summary This MR fix isBeforeInBlock crash bug mentioned in https://github.com/llvm/llvm-project/issues/60909. Fixes #60909. # Trigger condition 1. A block only have one operation. 2. block->isOpOrderValid() is true, but op->hasValidOrder() is false. 3. call: op->isBeforeInBlock(op), compared with op itself. Will crash on assert(blockFront != blockBack && "expected more than one operation"); # Case study Simplified repro case in mlir/test/Pass/scf2cf-print-liveness-crash.mlir When put -convert-scf-to-cf -test-print-liveness together in one cmd line, the first pass will work normally and crash on the second pass. Details please refer https://github.com/llvm/llvm-project/issues/60909 # Solutions option1. in isBeforeInBlock, check if block only have one operation before step into updateOrderIfNecessary, if have only one, it must return false option2. in isBeforeInBlock, check if this == other, if true return false option3. fix addNodeToList logic I prefer option3: When a block contains only one operation and the user calls op->isBeforeInBlock(op), if block->isOpOrderValid() returns true, updateOrderIfNecessary is called. If op->hasValidOrder() is false, it will crash at the assertion assert(blockFront != blockBack && "expected more than one operation");. This behavior is abnormal and needs fixing. I discovered that after the first pass of -convert-scf-to-cf, there is a block with only one operation where the block order is valid but the operation order is invalid, leading to a crash when -test-print-liveness pass runs. --------- Co-authored-by: isaacw <isaacw@nvidia.com> | 1 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 9 个月前 | ||
| 10 个月前 | ||
| 1 年前 | ||
| 1 年前 |