RRiver Riddle[mlir] Refactor SubElementInterface replace support
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
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 年前 | |
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 年前 | |
CombineContractBroadcast should not create dims unused in LHS+RHS Differential Revision: https://reviews.llvm.org/D129087 | 3 年前 | |
[AffineMap] Move result exprs into trailing storage. NFCI. | 4 年前 | |
[mlir] (NFC) run clang-format on all files | 3 年前 | |
Apply clang-tidy fixes for llvm-qualified-auto to MLIR (NFC) | 4 年前 | |
[mlir] Convert NamedAttribute to be a class NamedAttribute is currently represented as an std::pair, but this creates an extremely clunky .first/.second API. This commit converts it to a class, with better accessors (getName/getValue) and also opens the door for more convenient API in the future. Differential Revision: https://reviews.llvm.org/D113956 | 4 年前 | |
[mlir] (NFC) run clang-format on all files | 3 年前 | |
[mlir] Make OpBuilder::createOperation to accept raw inputs This provides a way to create an operation without manipulating OperationState directly. This is useful for creating unregistered ops. Reviewed By: rriddle, mehdi_amini Differential Revision: https://reviews.llvm.org/D120787 | 4 年前 | |
[mlir] Refactor ElementsAttr's value access API There are several aspects of the API that either aren't easy to use, or are deceptively easy to do the wrong thing. The main change of this commit is to remove all of the getValue<T>/getFlatValue<T> from ElementsAttr and instead provide operator[] methods on the ranges returned by getValues<T>. This provides a much more convenient API for the value ranges. It also removes the easy-to-be-inefficient nature of getValue/getFlatValue, which under the hood would construct a new range for the type T. Constructing a range is not necessarily cheap in all cases, and could lead to very poor performance if used within a loop; i.e. if you were to naively write something like: DenseElementsAttr attr = ...; for (int i = 0; i < size; ++i) { // We are internally rebuilding the APFloat value range on each iteration!! APFloat it = attr.getFlatValue<APFloat>(i); } Differential Revision: https://reviews.llvm.org/D113229 | 4 年前 | |
[mlir] Refactor SubElementInterface replace support The current support was essentially the amount necessary to support replacing SymbolRefAttrs, but suffers from various deficiencies (both ergonomic and functional): * Replace crashes if unsupported This makes it really hard to use safely, given that you don't know if you are going to crash or not when using it. * Types aren't supported This seems like a simple missed addition when the attribute replacement support was originally added. * The ergonomics are weird It currently uses an index based replacement, which makes the implementations quite clunky. This commit refactors support to be a bit more ergonomic, and also adds support for types in the process. This was also a great oppurtunity to greatly simplify how replacement is done in the symbol table. Fixes #56355 Differential Revision: https://reviews.llvm.org/D130589 | 3 年前 | |
Split class ValueRange to a new file When we apply parent patch : https://reviews.llvm.org/D129475 The prompt I get with the clang compiler is: ValueRange is imcomplete type,ValueRange is a forward declaration in the file TypeRange.h, and the file OperationSupport.h already includes the file TypeRange.h.The class TypeRange and the class ValueRange depend on each other. Reviewed By: rriddle, Mogball Differential Revision: https://reviews.llvm.org/D130332 | 3 年前 | |
[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 年前 | |
[mlir] Refactor SubElementInterface replace support The current support was essentially the amount necessary to support replacing SymbolRefAttrs, but suffers from various deficiencies (both ergonomic and functional): * Replace crashes if unsupported This makes it really hard to use safely, given that you don't know if you are going to crash or not when using it. * Types aren't supported This seems like a simple missed addition when the attribute replacement support was originally added. * The ergonomics are weird It currently uses an index based replacement, which makes the implementations quite clunky. This commit refactors support to be a bit more ergonomic, and also adds support for types in the process. This was also a great oppurtunity to greatly simplify how replacement is done in the symbol table. Fixes #56355 Differential Revision: https://reviews.llvm.org/D130589 | 3 年前 | |
Split class ValueRange to a new file When we apply parent patch : https://reviews.llvm.org/D129475 The prompt I get with the clang compiler is: ValueRange is imcomplete type,ValueRange is a forward declaration in the file TypeRange.h, and the file OperationSupport.h already includes the file TypeRange.h.The class TypeRange and the class ValueRange depend on each other. Reviewed By: rriddle, Mogball Differential Revision: https://reviews.llvm.org/D130332 | 3 年前 | |
[mlir] (NFC) run clang-format on all files | 3 年前 | |
[mlir] Add asserts when changing various MLIRContext configurations This helps to prevent tsan failures when users inadvertantly mutate the context in a non-safe way. Differential Revision: https://reviews.llvm.org/D112021 | 4 年前 | |
[Dominators] Rewrite the dominator implementation for efficiency. NFC. The previous impl densely scanned the entire region starting with an op when dominators were created, creating a DominatorTree for every region. This is extremely expensive up front -- particularly for clients like Linalg/Transforms/Fusion.cpp that construct DominanceInfo for a single query. It is also extremely memory wasteful for IRs that use single block regions commonly (e.g. affine.for) because it's making a dominator tree for a region that has trivial dominance. The implementation also had numerous unnecessary minor efficiencies, e.g. doing multiple walks of the region tree or tryGetBlocksInSameRegion building a DenseMap that it didn't need. This patch switches to an approach where [Post]DominanceInfo is free to construct, and which lazily constructs DominatorTree's for any multiblock regions that it needs. This avoids the up-front cost entirely, making its runtime proportional to the complexity of the region tree instead of # ops in a region. This also avoids the memory and time cost of creating DominatorTree's for single block regions. Finally this rewrites the implementation for simplicity and to avoids the constant factor problems the old implementation had. Differential Revision: https://reviews.llvm.org/D103384 | 4 年前 | |
[mlir] Plumb through default attribute populate for extensible dialect. | 3 年前 | |
Revert "Don't use Optional::hasValue (NFC)" This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d. | 3 年前 | |
[mlir] (NFC) run clang-format on all files | 3 年前 | |
[MLIR] Use a shared uniquer for affine maps and integer sets. Affine maps and integer sets previously relied on a single lock for creating unique instances. In a multi-threaded setting, this lock becomes a contention point. This commit updates AffineMap and IntegerSet to use StorageUniquer instead. StorageUniquer internally uses sharded locks and thread-local caches to reduce contention. It is already used for affine expressions, types and attributes. On my local machine, this gives me a 5X speedup for an application that manipulates a lot of affine maps and integer sets. This commit also removes the integer set uniquer threshold. The threshold was used to avoid adding integer sets with a lot of constraints to the hash_map containing unique instances, but the constraints and the integer set were still allocated in the same allocator and never freed, thus not saving any space expect for the hash-map entry. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D114942 | 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 年前 | |
[mlir] Retain metadata for single loc fusedloc If a fusedloc is created with a single location then no fusedloc was previously created and single location returned instead. In the case where there is a metadata associated with the location this results in discarding the metadata. Instead only canonicalize where there is no loss of information. Differential Revision: https://reviews.llvm.org/D115605 | 4 年前 | |
[mlir] Add method to populate default attributes Previously default attributes were only usable by way of the ODS generated accessors, but this was undesirable as 1. The ODS getters could construct Attribute each get request; 2. For non-C++ uses this would require either duplicating some of tee default attribute generating or generating additional bindings to generate methods; 3. Accessing op.getAttr("foo") and op.getFoo() would return different results; Generate method to populate default attributes that can be used to address these. This merely adds this facility but does not employ by default on any path. Differential Revision: https://reviews.llvm.org/D128962 | 3 年前 | |
[mlir] Switch create to use NamedAttrList&& Avoids needing the two parallel functions as NamedAttrList already takes care of caching DictionaryAttr and implicitly can convert from either. Differential Revision: https://reviews.llvm.org/D129527 | 3 年前 | |
[mlir] (NFC) run clang-format on all files | 3 年前 | |
[mlir:PDL] Fix bugs in PDLPatternModule merging * Constraints/Rewrites registered before a pattern was added were dropped * Constraints/Rewrites may be registered multiple times (if different pattern sets depend on them) * ModuleOp no longer has a terminator, so we shouldn't be removing the terminator from it Differential Revision: https://reviews.llvm.org/D114816 | 4 年前 | |
[mlir] Make Regionss cloneInto multithread-readable Prior to this patch, cloneInto would do a simple walk over the blocks and contained operations and clone and map them as it encounters them. As finishing touch it then remaps any successor and operands it has remapped during that process. This is generally fine, but sadly leads to a lot of uses of both operations and blocks from the source region, in the cloned operations in the target region. Those uses lead to writes in the use-def list of the operations, making cloneInto never thread safe. This patch reimplements cloneInto in three steps to avoid ever creating any extra uses on elements in the source region: * It first creates the mapping of all blocks and block operands * It then clones all operations to create the mapping of all operation results, but does not yet clone any regions or set the operands * After all operation results have been mapped, it now sets the operations operands and clones their regions. That way it is now possible to call cloneInto from multiple threads if the Region or Operation is isolated-from-above. This allows creating copies of functions or to use mlir::inlineCall with the same source region from multiple threads. In the general case, the method is thread-safe if through cloning, no new uses of Values from outside the cloned Operation/Region are created. This can be ensured by mapping any outside operands via the BlockAndValueMapping to Values owned by the caller thread. While I was at it, I also reworked the clone method of Operation a little bit and added a proper options class to avoid having a cloneWithoutRegionsAndOperands method, and be more extensible in the future. cloneWithoutRegions is now also a simple wrapper that calls clone with the proper options set. That way all the operation cloning code is now contained solely within clone. Differential Revision: https://reviews.llvm.org/D123917 | 4 年前 | |
[MLIR] Add RegionKindInterface Some dialects have semantics which is not well represented by common SSA structures with dominance constraints. This patch allows operations to declare the 'kind' of their contained regions. Currently, two kinds are allowed: "SSACFG" and "Graph". The only difference between them at the moment is that SSACFG regions are required to have dominance, while Graph regions are not required to have dominance. The intention is that this Interface would be generated by ODS for existing operations, although this has not yet been implemented. Presumably, if someone were interested in code generation, we might also have a "CFG" dialect, which defines control flow, but does not require SSA. The new behavior is mostly identical to the previous behavior, since registered operations without a RegionKindInterface are assumed to contain SSACFG regions. However, the behavior has changed for unregistered operations. Previously, these were checked for dominance, however the new behavior allows dominance violations, in order to allow the processing of unregistered dialects with Graph regions. One implication of this is that regions in unregistered operations with more than one op are no longer CSE'd (since it requires dominance info). I've also reorganized the LangRef documentation to remove assertions about "sequential execution", "SSA Values", and "Dominance". Instead, the core IR is simply "ordered" (i.e. totally ordered) and consists of "Values". I've also clarified some things about how control flow passes between blocks in an SSACFG region. Control Flow must enter a region at the entry block and follow terminator operation successors or be returned to the containing op. Graph regions do not define a notion of control flow. see discussion here: https://llvm.discourse.group/t/rfc-allowing-dialects-to-relax-the-ssa-dominance-condition/833/53 Differential Revision: https://reviews.llvm.org/D80358 | 5 年前 | |
[mlir] Refactor SubElementInterface replace support The current support was essentially the amount necessary to support replacing SymbolRefAttrs, but suffers from various deficiencies (both ergonomic and functional): * Replace crashes if unsupported This makes it really hard to use safely, given that you don't know if you are going to crash or not when using it. * Types aren't supported This seems like a simple missed addition when the attribute replacement support was originally added. * The ergonomics are weird It currently uses an index based replacement, which makes the implementations quite clunky. This commit refactors support to be a bit more ergonomic, and also adds support for types in the process. This was also a great oppurtunity to greatly simplify how replacement is done in the symbol table. Fixes #56355 Differential Revision: https://reviews.llvm.org/D130589 | 3 年前 | |
[mlir] Refactor SubElementInterface replace support The current support was essentially the amount necessary to support replacing SymbolRefAttrs, but suffers from various deficiencies (both ergonomic and functional): * Replace crashes if unsupported This makes it really hard to use safely, given that you don't know if you are going to crash or not when using it. * Types aren't supported This seems like a simple missed addition when the attribute replacement support was originally added. * The ergonomics are weird It currently uses an index based replacement, which makes the implementations quite clunky. This commit refactors support to be a bit more ergonomic, and also adds support for types in the process. This was also a great oppurtunity to greatly simplify how replacement is done in the symbol table. Fixes #56355 Differential Revision: https://reviews.llvm.org/D130589 | 3 年前 | |
[mlir][tensors] Introduce attribute interface/attribute for tensor encoding The new "encoding" field in tensor types so far had no meaning. This revision introduces: 1. an encoding attribute interface in IR: for verification between tensors and encodings in general 2. an attribute in Tensor dialect; #tensor.sparse<dict> + concrete sparse tensors API Active discussion: https://llvm.discourse.group/t/rfc-introduce-a-sparse-tensor-type-to-core-mlir/2944/ Reviewed By: silvas, penpornk, bixia Differential Revision: https://reviews.llvm.org/D101008 | 5 年前 | |
Apply clang-tidy fixes for llvm-qualified-auto to MLIR (NFC) | 4 年前 | |
[mlir][NFC] Remove TypeRange's constructors that cause ambiguity ArrayRef<Value> can implicit convert to ValueRange，when we call TypeRange(SmallVector<Value>) is ambiguity. TypeRange(ValueRange values) TypeRange(ArrayRef<Value> values) Reviewed By: rriddle, Mogball Differential Revision: https://reviews.llvm.org/D129475 | 3 年前 | |
[mlir][Arith] Disallow casting between scalable and fixed-length vectors Casting between scalable vectors and fixed-length vectors doesn't make sense. If one of the operands is scalable, the other has to be scalable to be able to guarantee they have the same shape at runtime. Differential Revision: https://reviews.llvm.org/D119568 | 4 年前 | |
[mlir][NFC] Move several small methods from .cpp to .h to allow more aggressive inlining Differential Revision: https://reviews.llvm.org/D104756 | 4 年前 | |
[mlir] (NFC) run clang-format on all files | 3 年前 | |
Split class ValueRange to a new file When we apply parent patch : https://reviews.llvm.org/D129475 The prompt I get with the clang compiler is: ValueRange is imcomplete type,ValueRange is a forward declaration in the file TypeRange.h, and the file OperationSupport.h already includes the file TypeRange.h.The class TypeRange and the class ValueRange depend on each other. Reviewed By: rriddle, Mogball Differential Revision: https://reviews.llvm.org/D130332 | 3 年前 | |
[mlir] Fix verification order of nested ops. In order to increase parallism, certain ops with regions and have the IsIsolatedFromAbove trait will have their verification delayed. That means the region verifier may access the invalid ops and may lead to a crash. Reviewed By: rriddle Differential Revision: https://reviews.llvm.org/D122771 | 4 年前 | |
[mlir] check whether region and block visitors are interrupted The visitor functions for Region and Block types did not always check the value returned by recursive calls. This caused the top-level visitor invocation to return WalkResult::advance() even if one or more recursive invocations returned WalkResult::interrupt(). This patch fixes the problem by check if any recursive call is interrupted, and if so, return WalkResult::interrupt(). Reviewed By: dcaballe Differential Revision: https://reviews.llvm.org/D129718 | 3 年前 |