[mlir] (NFC) Clean up bazel and CMake target namesAll dialect targets in bazel have been named *Dialect and all dialecttargets in CMake have been named MLIR*Dialect.
[mlir] Add shape.funcAdd shape func op for use (primarily) in shape function_library op. Allowssetting default dialect for some simpler authoring. This is a minimal versionof the ops needed.Dif
[mlir] Add shape.funcAdd shape func op for use (primarily) in shape function_library op. Allowssetting default dialect for some simpler authoring. This is a minimal versionof the ops needed.Differential Revision: https://reviews.llvm.org/D124055
show more ...
[mlir:NFC] Remove the forward declaration of FuncOp in the mlir namespaceFuncOp has been moved to the `func` namespace for a little over a month, theusing directive can be dropped now.
[mlir] Rework the implementation of TypeIDThis commit restructures how TypeID is implemented to ideally avoidthe current problems related to shared libraries. This is done by changingthe "implici
[mlir] Rework the implementation of TypeIDThis commit restructures how TypeID is implemented to ideally avoidthe current problems related to shared libraries. This is done by changingthe "implicit" fallback path to use the name of the type, instead of usinga static template variable (which breaks shared libraries). The major downside to thisis that it adds some additional initialization costs for the implicit path. Given theuse of type names for uniqueness in the fallback, we also no longer allow typesdefined in anonymous namespaces to have an implicit TypeID. To simplify definingan ID for these classes, a new `MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID` macrowas added to allow for explicitly defining a TypeID directly on an internal class.To help identify when types are using the fallback, `-debug-only=typeid` can beused to log which types are using implicit ids.This change generally only requires changes to the test passes, which are all definedin anonymous namespaces, and thus can't use the fallback any longer.Differential Revision: https://reviews.llvm.org/D122775
Adjust "end namespace" comment in MLIR to match new agree'd coding styleSee D115115 and this mailing list discussion:https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.htmlDifferenti
Adjust "end namespace" comment in MLIR to match new agree'd coding styleSee D115115 and this mailing list discussion:https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.htmlDifferential Revision: https://reviews.llvm.org/D115309
[mlir][NFC] Replace references to Identifier with StringAttrThis is part of the replacement of Identifier with StringAttr.Differential Revision: https://reviews.llvm.org/D113953
Migrate MLIR test passes to the new registration APIMake sure they all define getArgument()/getDescription().Depends On D104421Differential Revision: https://reviews.llvm.org/D104426
[mlir][IR] Remove the concept of `OperationProperties`These properties were useful for a few things before traits had a better integration story, but don't really carry their weight well these days
[mlir][IR] Remove the concept of `OperationProperties`These properties were useful for a few things before traits had a better integration story, but don't really carry their weight well these days. Most of these properties are already checked via traits in most of the code. It is better to align the system around traits, and improve the performance/cost of traits in general.Differential Revision: https://reviews.llvm.org/D96088
[mlir] Remove a number of methods from mlir::OpState that just forward to mlir::Operation. All call sites have been converted in previous changes.
[mlir][shape] Add shape.lib attributeEnable querying shape function library ops from the module. Currentlysupports singular or array of them (as long as array has all unique opsin mappings). The
[mlir][shape] Add shape.lib attributeEnable querying shape function library ops from the module. Currentlysupports singular or array of them (as long as array has all unique opsin mappings). The preferred canonical form would have one library, butgiven the invariant on the mapping, this can easily be achieved by asimple merging pass.Preferred the attribute approach vs naming convention as these could beadded in multiple different ways.
[mlir] Use mlir::OpState::operator->() to get to methods of mlir::Operation. This is a preparation step to remove the corresponding methods from OpState.Reviewed By: silvas, rriddleDifferential R
[mlir] Use mlir::OpState::operator->() to get to methods of mlir::Operation. This is a preparation step to remove the corresponding methods from OpState.Reviewed By: silvas, rriddleDifferential Revision: https://reviews.llvm.org/D92878
[mlir] Add a shape function library opOp with mapping from ops to corresponding shape functions for those opin the library and mechanism to associate shape functions to functions.The mapping of o
[mlir] Add a shape function library opOp with mapping from ops to corresponding shape functions for those opin the library and mechanism to associate shape functions to functions.The mapping of operand to shape function is kept separate from the shapefunctions themselves as the operation is associated to the shapefunction and not vice versa, and one could have a common library ofshape functions that can be used in different contexts.Use fully qualified names and require a name for shape fn lib ops fornow and an explicit print/parse (based around the generated one & GPUmodule op ones).This commit reverts d9da4c3e73720badfcac5c0dc63c0285bb690770. Fixesmissing headers (don't know how that was working locally).Differential Revision: https://reviews.llvm.org/D91672
Revert "[mlir] Add a shape function library op"This reverts commit 6dd9596b19d7679c562f8e866be6d0c3d7c21994.Build is broken.
[mlir] Add a shape function library opOp with mapping from ops to corresponding shape functions for those opin the library and mechanism to associate shape functions to functions.The mapping of operand to shape function is kept separate from the shapefunctions themselves as the operation is associated to the shapefunction and not vice versa, and one could have a common library ofshape functions that can be used in different contexts.Use fully qualified names and require a name for shape fn lib ops fornow and an explicit print/parse (based around the generated one & GPUmodule op ones).Differential Revision: https://reviews.llvm.org/D91672