| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[MLIR] Revamp RegionBranchOpInterface (#165429) This is still somehow a WIP, we have some issues with this interface that are not trivial to solve. This patch tries to make the concepts of RegionBranchPoint and RegionSuccessor more robust and aligned with their definition: - A RegionBranchPoint is either the parent (RegionBranchOpInterface) op or a RegionBranchTerminatorOpInterface operation in a nested region. - A RegionSuccessor is either one of the nested region or the parent RegionBranchOpInterface Some new methods with reasonnable default implementation are added to help resolving the flow of values across the RegionBranchOpInterface. It is still not trivial in the current state to walk the def-use chain backward with this interface. For example when you have the 3rd block argument in the entry block of a for-loop, finding the matching operands requires to know about the hidden loop iterator block argument and where the iterargs start. The API is designed around forward-tracking of the chain unfortunately. Try to reland #161575 ; I suspect a buildbot incremental build issue. | 8 个月前 | |
Reland "[mlir] Add strided metadata range dataflow analysis" (#163403)" (#163408) This relands commit aa8499863ad23350da0912d99d189f306d0ea139. That commit was originally reverted because it caused failures in shared lib builds due to missing link dependencies. This patch relands the commit with the missing libs added. Signed-off-by: Fabian Mora <fabian.mora-cordero@amd.com> | 9 个月前 | |
Update some uses of getAttr() to be explicit about Inherent vs Discardable (NFC) | 2 年前 | |
Alias Analysis infra in Flang Differential revision: https://reviews.llvm.org/D136889 | 3 年前 | |
[mlir][NFC] Use hasOneBlock instead of llvm::hasSingleElement(region) (#149809) | 1 年前 | |
Update some uses of getAttr() to be explicit about Inherent vs Discardable (NFC) | 2 年前 | |
[mlir] [dataflow] unify semantics of program point (#110344) The concept of a 'program point' in the original data flow framework is ambiguous. It can refer to either an operation or a block itself. This representation has different interpretations in forward and backward data-flow analysis. In forward data-flow analysis, the program point of an operation represents the state after the operation, while in backward data flow analysis, it represents the state before the operation. When using forward or backward data-flow analysis, it is crucial to carefully handle this distinction to ensure correctness. This patch refactors the definition of program point, unifying the interpretation of program points in both forward and backward data-flow analysis. How to integrate this patch? For dense forward data-flow analysis and other analysis (except dense backward data-flow analysis), the program point corresponding to the original operation can be obtained by getProgramPointAfter(op), and the program point corresponding to the original block can be obtained by getProgramPointBefore(block). For dense backward data-flow analysis, the program point corresponding to the original operation can be obtained by getProgramPointBefore(op), and the program point corresponding to the original block can be obtained by getProgramPointAfter(block). NOTE: If you need to get the lattice of other data-flow analyses in dense backward data-flow analysis, you should still use the dense forward data-flow approach. For example, to get the Executable state of a block in dense backward data-flow analysis and add the dependency of the current operation, you should write: getOrCreateFor<Executable>(getProgramPointBefore(op), getProgramPointBefore(block)) In case above, we use getProgramPointBefore(op) because the analysis we rely on is dense backward data-flow, and we use getProgramPointBefore(block) because the lattice we query is the result of a non-dense backward data flow computation. related dsscussion: https://discourse.llvm.org/t/rfc-unify-the-semantics-of-program-points/80671/8 corresponding PSA: https://discourse.llvm.org/t/psa-program-point-semantics-change/81479 | 1 年前 | |
[mlir][NFC] Drop a few unnecessary includes from Pass.h | 4 年前 | |
[mlir] Move FunctionInterfaces to Interfaces directory and inherit from CallableOpInterface Functions are always callable operations and thus every operation implementing the FunctionOpInterface also implements the CallableOpInterface. The only exception was the FuncOp in the toy example. To make implementation of the FunctionOpInterface easier, this commit lets FunctionOpInterface inherit from CallableOpInterface and merges some of their methods. More precisely, the CallableOpInterface has methods to get the argument and result attributes and a method to get the result types of the callable region. These methods are always implemented the same way as their analogues in FunctionOpInterface and thus this commit moves all the argument and result attribute handling methods to the callable interface as well as the methods to get the argument and result types. The FuntionOpInterface then does not have to declare them as well, but just inherits them from the CallableOpInterface. Adding the inheritance relation also required to move the FunctionOpInterface from the IR directory to the Interfaces directory since IR should not depend on Interfaces. Reviewed By: jpienaar, springerm Differential Revision: https://reviews.llvm.org/D157988 | 2 年前 | |
[mlir][Affine][NFC] Wrap dialect in "affine" namespace This cleanup aligns the affine dialect with all the other dialects. Differential Revision: https://reviews.llvm.org/D148687 | 3 年前 | |
[mlir][Affine][NFC] Wrap dialect in "affine" namespace This cleanup aligns the affine dialect with all the other dialects. Differential Revision: https://reviews.llvm.org/D148687 | 3 年前 | |
[mlir][IR][NFC] Move free-standing functions to MemRefType (#123465) Turn free-standing MemRefType-related helper functions in BuiltinTypes.h into member functions. | 1 年前 | |
[MLIR][Analysis] Consolidate topological sort utilities (#92563) This PR attempts to consolidate the different topological sort utilities into one place. It adds them to the analysis folder because the SliceAnalysis uses some of these. There are now two different sorting strategies: 1. Sort only according to SSA use-def chains 2. Sort while taking regions into account. This requires a much more elaborate traversal and cannot be applied on graph regions that easily. This additionally reimplements the region aware topological sorting because the previous implementation had an exponential space complexity. I'm open to suggestions on how to combine this further or how to fuse the test passes. | 2 年前 | |
[mlir] Use llvm::is_contained (NFC) (#140986) | 1 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 8 个月前 | ||
| 9 个月前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 1 年前 |