| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir] Remove unused includes (NFC) (#148119) These are identified by misc-include-cleaner. I've filtered out those that break builds. Also, I'm staying away from llvm-config.h, config.h, and Compiler.h, which likely cause platform- or compiler-specific build failures. | 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. | 9 个月前 | |
[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 年前 | |
[mlir] Adopt cast function objects. NFC. (#168228) These were added in https://github.com/llvm/llvm-project/pull/165803. | 8 个月前 | |
[mlir] Remove unused includes (NFC) (#148119) These are identified by misc-include-cleaner. I've filtered out those that break builds. Also, I'm staying away from llvm-config.h, config.h, and Compiler.h, which likely cause platform- or compiler-specific build failures. | 1 年前 | |
[mlir][nfc] Remove TrivialPatternRewriters (#155248) These are relics from the times when PatternRewriter was not instantiable directly, I suppose. | 11 个月前 | |
[MLIR][Transform][SMT] Allow for declarative computations in schedules (#160895) By allowing transform.smt.constrain_params's region to yield SMT-vars, op instances can declare relationships, through constraints, on incoming params-as-SMT-vars and outgoing SMT-vars-as-params. This makes it possible to declare that computations on params should be performed. The semantics are that the yielded SMT-vars should be from any valid satisfying assignment/model of the constraints in the region. | 9 个月前 | |
[MLIR][Transform] Prefer entry points in current module (#151323) The transform interpreter previously looked for the entry point using a recursive walk in pre-order. This makes it so that any named_sequence operation with an arbitrary level of nested-ness will be used as the entry point for the transform interpreter as long as it is placed before another one. This change makes it so that code like the one reported in https://github.com/llvm/llvm-project/issues/119578 works as expected. Closes #119578 Some comments: alternatively, it would also be possible to solve this issue in a slightly more elegant manner. We could define a new walker iterator that iterates through the operations in a breadth first search. --------- Co-authored-by: Jakub Kuderski <kubakuderski@gmail.com> | 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. | 9 个月前 | |
[mlir][transform] Consistent linalg transform op syntax for dynamic index lists (#90897) This patch is a first pass at making consistent syntax across the LinalgTransformOps that use dynamic index lists for size parameters. Previously, there were two different forms: inline types in the list, or place them in the functional style tuple. This patch goes for the latter. In order to do this, the printPackedOrDynamicIndexList, printDynamicIndexList and their parse counterparts were modified so that the types can be optionally provided to the corresponding custom directives. All affected ops now use tablegen assemblyFormat, so custom parse/print functions have been removed. There are a couple ops that will likely add dynamic size support, and once that happens it should be made sure that the assembly remains consistent with the changes in this patch. The affected ops are as follows: pack, pack_greedily, tile_using_forall. The tile_using_for and vectorize ops already used this syntax, but their custom assembly was removed. --------- Co-authored-by: Oleksandr "Alex" Zinenko <ftynse@gmail.com> | 2 年前 | |
[MLIR][Transform][SMT] Introduce transform.smt.constrain_params (#159450) Introduces a Transform-dialect SMT-extension so that we can have an op to express constrains on Transform-dialect params, in particular when these params are knobs -- see transform.tune.knob -- and can hence be seen as symbolic variables. This op allows expressing joint constraints over multiple params/knobs together. While the op's semantics are clearly defined, per SMTLIB, the interpreted semantics -- i.e. the apply() method -- for now just defaults to failure. In the future we should support attaching an implementation so that users can Bring Your Own Solver and thereby control performance of interpreting the op. For now the main usage is to walk schedule IR and collect these constraints so that knobs can be rewritten to constants that satisfy the constraints. | 10 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 年前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 11 个月前 | ||
| 9 个月前 | ||
| 1 年前 | ||
| 9 个月前 | ||
| 2 年前 | ||
| 10 个月前 |