| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[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] 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 个月前 | |
[mlir] Use *Set::insert_range (NFC) (#132326) DenseSet, SmallPtrSet, SmallSet, SetVector, and StringSet recently gained C++23-style insert_range. This patch replaces: Dest.insert(Src.begin(), Src.end()); with: Dest.insert_range(Src); This patch does not touch custom begin like succ_begin for now. | 1 年前 | |
Define a DataFlowSolver helper that loads sensible default analyses (#143415) Cf. https://discourse.llvm.org/t/mlir-dead-code-analysis/67568/10 Custom analysis passes will not work properly unless both DeadCodeAnalysis and SparseConstantPropagation are loaded to the DataFlowSolver. This is intended behavior, but surprising to many users as shown in the thread. In lieu of a longer-term fix (which I am not knowledgeable enough to implement myself, yet), this commit adds a helper function that loads these two analyses, as well as providing breadcrumbs for an explanation of the problem. The existing places in the codebase where these two analyses are loaded for the purpose of running other unrelated analyses are replaced by the use of the helper. --------- Co-authored-by: Jeremy Kun <j2kun@users.noreply.github.com> Co-authored-by: Oleksandr "Alex" Zinenko <azinenko@amd.com> | 1 年前 | |
[MLIR] Fix Liveness analysis handling of unreachable code (#153973) This patch is forcing all values to be initialized by the LivenessAnalysis, even in dead blocks. The dataflow framework will skip visiting values when its already knows that a block is dynamically unreachable, so this requires specific handling. Downstream code could consider that the absence of liveness is the same a "dead". However as the code is mutated, new value can be introduced, and a transformation like "RemoveDeadValue" must conservatively consider that the absence of liveness information meant that we weren't sure if a value was dead (it could be a newly introduced value. Fixes #153906 | 11 个月前 | |
Define a DataFlowSolver helper that loads sensible default analyses (#143415) Cf. https://discourse.llvm.org/t/mlir-dead-code-analysis/67568/10 Custom analysis passes will not work properly unless both DeadCodeAnalysis and SparseConstantPropagation are loaded to the DataFlowSolver. This is intended behavior, but surprising to many users as shown in the thread. In lieu of a longer-term fix (which I am not knowledgeable enough to implement myself, yet), this commit adds a helper function that loads these two analyses, as well as providing breadcrumbs for an explanation of the problem. The existing places in the codebase where these two analyses are loaded for the purpose of running other unrelated analyses are replaced by the use of the helper. --------- Co-authored-by: Jeremy Kun <j2kun@users.noreply.github.com> Co-authored-by: Oleksandr "Alex" Zinenko <azinenko@amd.com> | 1 年前 | |
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 个月前 |