KKazu Hirata[mlir] Use has_value instead of hasValue (NFC)
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Adjust "end namespace" comment in MLIR to match new agree'd coding style See D115115 and this mailing list discussion: https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html Differential Revision: https://reviews.llvm.org/D115309 | 4 年前 | |
[mlir] Define proper DenseMapInfo for Interfaces Prior to this patch, using any kind of interface (op interface, attr interface, type interface) as the key of a llvm::DenseSet, llvm::DenseMap or other related containers, leads to invalid pointer dereferences, despite compiling. The gist of the problem is that a llvm::DenseMapInfo specialization for the base type (aka one of Operation*, Type or Attribute) are selected when using an interface as a key, which uses getFromOpaquePointer with invalid pointer addresses to construct instances for the empty key and tombstone key values. The interface is then constructed with this invalid base type and an attempt is made to lookup the implementation in the interface map, which then dereferences the invalid pointer address. (For more details and the exact call chain involved see the GitHub issue below) The current workaround is to use the more generic base type (eg. instead of DenseSet<FunctionOpInterface>, DenseSet<Operation*>), but this is strictly worse from a code perspective (doesn't enforce the invariant, code is less self documenting, having to insert casts etc). This patch fixes that issue by defining a DenseMapInfo specialization of Interface subclasses which uses a new constructor to construct an instance without querying a concept. That allows getEmptyKey and getTombstoneKey to construct an interface with invalid pointer values. Fixes https://github.com/llvm/llvm-project/issues/54908 Differential Revision: https://reviews.llvm.org/D129038 | 3 年前 | |
[mlir] Rework the implementation of TypeID This commit restructures how TypeID is implemented to ideally avoid the current problems related to shared libraries. This is done by changing the "implicit" fallback path to use the name of the type, instead of using a static template variable (which breaks shared libraries). The major downside to this is that it adds some additional initialization costs for the implicit path. Given the use of type names for uniqueness in the fallback, we also no longer allow types defined in anonymous namespaces to have an implicit TypeID. To simplify defining an ID for these classes, a new MLIR_DEFINE_EXPLICIT_INTERNAL_INLINE_TYPE_ID macro was 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 be used to log which types are using implicit ids. This change generally only requires changes to the test passes, which are all defined in anonymous namespaces, and thus can't use the fallback any longer. Differential Revision: https://reviews.llvm.org/D122775 | 4 年前 | |
[mlir] Refactor DialectRegistry delayed interface support into a general DialectExtension mechanism The current dialect registry allows for attaching delayed interfaces, that are added to attrs/dialects/ops/etc. when the owning dialect gets loaded. This is clunky for quite a few reasons, e.g. each interface type has a separate tracking structure, and is also quite limiting. This commit refactors this delayed mutation of dialect constructs into a more general DialectExtension mechanism. This mechanism is essentially a registration callback that is invoked when a set of dialects have been loaded. This allows for attaching interfaces directly on the loaded constructs, and also allows for loading new dependent dialects. The latter of which is extremely useful as it will now enable dependent dialects to only apply in the contexts in which they are necessary. For example, a dialect dependency can now be conditional on if a user actually needs the interface that relies on it. Differential Revision: https://reviews.llvm.org/D120367 | 4 年前 | |
[mlir] Define proper DenseMapInfo for Interfaces Prior to this patch, using any kind of interface (op interface, attr interface, type interface) as the key of a llvm::DenseSet, llvm::DenseMap or other related containers, leads to invalid pointer dereferences, despite compiling. The gist of the problem is that a llvm::DenseMapInfo specialization for the base type (aka one of Operation*, Type or Attribute) are selected when using an interface as a key, which uses getFromOpaquePointer with invalid pointer addresses to construct instances for the empty key and tombstone key values. The interface is then constructed with this invalid base type and an attempt is made to lookup the implementation in the interface map, which then dereferences the invalid pointer address. (For more details and the exact call chain involved see the GitHub issue below) The current workaround is to use the more generic base type (eg. instead of DenseSet<FunctionOpInterface>, DenseSet<Operation*>), but this is strictly worse from a code perspective (doesn't enforce the invariant, code is less self documenting, having to insert casts etc). This patch fixes that issue by defining a DenseMapInfo specialization of Interface subclasses which uses a new constructor to construct an instance without querying a concept. That allows getEmptyKey and getTombstoneKey to construct an interface with invalid pointer values. Fixes https://github.com/llvm/llvm-project/issues/54908 Differential Revision: https://reviews.llvm.org/D129038 | 3 年前 | |
[mlir] Use has_value instead of hasValue (NFC) | 3 年前 | |
[mlir][ir] OpRewritePattern should accept generatedNames Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D115514 | 4 年前 | |
[mlir] Refactor ShapedType into an interface ShapedType was created in a time before interfaces, and is one of the earliest type base classes in the ecosystem. This commit refactors ShapedType into an interface, which is what it would have been if interfaces had existed at that time. The API of ShapedType and it's derived classes are essentially untouched by this refactor, with the exception being the API surrounding kDynamicIndex (which requires a sole home). For now, the API of ShapedType and its name have been kept as consistent to the current state of the world as possible (to help with potential migration churn, among other reasons). Moving forward though, we should look into potentially restructuring its API and possible its name as well (it should really have "Interface" at the end like other interfaces at the very least). One other potentially interesting note is that I've attached the ShapedType::Trait to TensorType/BaseMemRefType to act as mixins for the ShapedType API. This is kind of weird, but allows for sharing the same API (i.e. preventing API loss from the transition from base class -> Interface). This inheritance doesn't affect any of the derived classes, it is just for API mixin. Differential Revision: https://reviews.llvm.org/D116962 | 4 年前 | |
Adjust "end namespace" comment in MLIR to match new agree'd coding style See D115115 and this mailing list discussion: https://lists.llvm.org/pipermail/llvm-dev/2021-December/154199.html Differential Revision: https://reviews.llvm.org/D115309 | 4 年前 |