JJacques Pienaar[mlir] SCCP add missing pessimistic setting
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir] Support getSuccessorInputs from parent op Ops that implement RegionBranchOpInterface are allowed to indicate that they can branch back to themselves in getSuccessorRegions, but there is no API that allows them to specify the forwarded operands. This patch enables that by changing getSuccessorEntryOperands to accept None. Fixes #54928 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D127239 | 3 年前 | |
[mlir] SCCP add missing pessimistic setting When this was updated in D127139 the update in-place case was no longer marked as pessimistic. Add back in. Differential Revision: https://reviews.llvm.org/D130453 | 3 年前 | |
[MLIR][Presburger] Provide functions to convert between arrays of MPInt and int64_t Reviewed By: Groverkss Differential Revision: https://reviews.llvm.org/D129509 | 3 年前 | |
[mlir] Add support for querying the ModRef behavior from the AliasAnalysis class This allows for checking if a given operation may modify/reference/or both a given value. Right now this API is limited to Value based memory locations, but we should expand this to include attribute based values at some point. This is left for future work because the rest of the AliasAnalysis API also has this restriction. Differential Revision: https://reviews.llvm.org/D101673 | 5 年前 | |
[mlir] Add support for operation-produced successor arguments in BranchOpInterface This patch revamps the BranchOpInterface a bit and allows a proper implementation of what was previously getMutableSuccessorOperands for operations, which internally produce arguments to some of the block arguments. A motivating example for this would be an invoke op with a error handling path: invoke %function(%0) label ^success ^error(%1 : i32) ^error(%e: !error, %arg0 : i32): ... The advantages of this are that any users of BranchOpInterface can still argue over remaining block argument operands (such as %1 in the example above), as well as make use of the modifying capabilities to add more operands, erase an operand etc. The way this patch implements that functionality is via a new class called SuccessorOperands, which is now returned by getSuccessorOperands. It basically contains an unsigned denoting how many operator produced operands exist, as well as a MutableOperandRange, which are the usual forwarded operands we are used to. The produced operands are assumed to the first few block arguments, followed by the forwarded operands afterwards. The role of SuccessorOperands is to provide various utility functions to modify and query the successor arguments from a BranchOpInterface. Differential Revision: https://reviews.llvm.org/D123062 | 4 年前 | |
[mlir] Delete ForwardDataFlowAnalysis With SCCP and integer range analysis ported to the new framework, this old framework is redundant. Delete it. Depends on D128866 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D128867 | 3 年前 | |
[mlir] Update SCCP and the Inliner to use SymbolTableCollection for symbol lookups This transforms the symbol lookups to O(1) from O(NM), greatly speeding up both passes. For a large MLIR module this shaved seconds off of the compilation time. Differential Revision: https://reviews.llvm.org/D89522 | 5 年前 | |
[mlir] Delete ForwardDataFlowAnalysis With SCCP and integer range analysis ported to the new framework, this old framework is redundant. Delete it. Depends on D128866 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D128867 | 3 年前 | |
[mlir] Swap integer range inference to the new framework Integer range inference has been swapped to the new framework. The integer value range lattices automatically updates the corresponding constant value on update. Depends on D127173 Reviewed By: krzysz00, rriddle Differential Revision: https://reviews.llvm.org/D128866 | 3 年前 | |
[mlir] support memref of memref in standard-to-llvm conversion Now that memref supports arbitrary element types, add support for memref of memref and make sure it is properly converted to the LLVM dialect. The type support itself avoids adding the interface to the memref type itself similarly to other built-in types. This allows the shape, and therefore byte size, of the memref descriptor to remain a lowering aspect that is easier to customize and evolve as opposed to sanctifying it in the data layout specification for the memref type itself. Factor out the code previously in a testing pass to live in a dedicated data layout analysis and use that analysis in the conversion to compute the allocation size for memref of memref. Other conversions will be ported separately. Depends On D103827 Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D103828 | 4 年前 | |
Use llvm::sort instead of std::sort where possible llvm::sort is beneficial even when we use the iterator-based overload, since it can optionally shuffle the elements (to detect non-determinism). However llvm::sort is not usable everywhere, for example, in compiler-rt. Reviewed By: nhaehnle Differential Revision: https://reviews.llvm.org/D130406 | 3 年前 | |
[mlir:Analysis] Move the LoopAnalysis library to Dialect/Affine/Analysis The current state of the top level Analysis/ directory is that it contains two libraries; a generic Analysis library (free from dialect dependencies), and a LoopAnalysis library that contains various analysis utilities that originated from Affine loop transformations. This commit moves the LoopAnalysis to the more appropriate home of Dialect/Affine/Analysis/, given the use and intention of the majority of the code within it. After the move, if there are generic utilities that would fit better in the top-level Analysis/ directory, we can move them. Differential Revision: https://reviews.llvm.org/D117351 | 4 年前 |