main

文件	最后提交记录	最后更新时间
IR	[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.	9 个月前
Pipelines	[mlir][SparseTensor] Simplify pipeline (#152908) This refactoring improves compilation time.	11 个月前
TransformOps	[mlir] Support DialectRegistry extension comparison (#101119) PassManager::run loads the dependent dialects for each pass into the current context prior to invoking the individual passes. If the dependent dialect is already loaded into the context, this should be a no-op. However, if there are extensions registered in the DialectRegistry, the dependent dialects are unconditionally registered into the context. This poses a problem for dynamic pass pipelines, however, because they will likely be executing while the context is in an immutable state (because of the parent pass pipeline being run). To solve this, we'll update the extension registration API on DialectRegistry to require a type ID for each extension that is registered. Then, instead of unconditionally registered dialects into a context if extensions are present, we'll check against the extension type IDs already present in the context's internal DialectRegistry. The context will only be marked as dirty if there are net-new extension types present in the DialectRegistry populated by PassManager::getDependentDialects. Note: this PR removes the addExtension overload that utilizes std::function as the parameter. This is because std::function is copyable and potentially allocates memory for the contained function so we can't use the function pointer as the unique type ID for the extension. Downstream changes required: - Existing DialectExtension subclasses will need a type ID to be registered for each subclass. More details on how to register a type ID can be found here: https://github.com/llvm/llvm-project/blob/8b68e06731e0033ed3f8d6fe6292ae671611cfa1/mlir/include/mlir/Support/TypeID.h#L30 - Existing uses of the std::function overload of addExtension will need to be refactored into dedicated DialectExtension classes with associated type IDs. The attached std::function can either be inlined into or called directly from DialectExtension::apply. --------- Co-authored-by: Mehdi Amini <joker.eph@gmail.com>	1 年前
Transforms	[MLIR] Apply clang-tidy fixes for bugprone-argument-comment in SparseBufferRewriting.cpp (NFC)	8 个月前
Utils	[mlir][NFC] update mlir/Dialect create APIs (21/n) (#149928) See https://github.com/llvm/llvm-project/pull/147168 for more info.	1 年前
CMakeLists.txt	[mlir][sparse] cleanup of CMake files Alphabetical order, less whitespace removed some verbose comments for readability (which are preserved in the history if ever needed) Reviewed By: Peiming Differential Revision: https://reviews.llvm.org/D158114	2 年前