| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[mlir] Add config for PDL (#69927) Make it so that PDL in pattern rewrites can be optionally disabled. PDL is still enabled by default and not optional bazel. So this should be a NOP for most folks, while enabling other to disable. This only works with tests disabled. With tests enabled this still compiles but tests fail as there is no lit config to disable tests that depend on PDL rewrites yet. | 2 年前 | |
Fix sign of largest known divisor of div. (#100081) There's a missing abs, so it returns a negative value if the divisor is negative. Later this is then cast to uint. | 2 年前 | |
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][vector] Make the in_bounds attribute mandatory (#97049) At the moment, the in_bounds attribute has two confusing/contradicting properties: 1. It is both optional _and_ has an effective default-value. 2. The default value is "out-of-bounds" for non-broadcast dims, and "in-bounds" for broadcast dims. (see the isDimInBounds vector interface method for an example of this "default" behaviour [1]). This PR aims to clarify the logic surrounding the in_bounds attribute by: * making the attribute mandatory (i.e. it is always present), * always setting the default value to "out of bounds" (that's consistent with the current behaviour for the most common cases). #### Broadcast dimensions in tests As per [2], the broadcast dimensions requires the corresponding in_bounds attribute to be true: vector.transfer_read op requires broadcast dimensions to be in-bounds The changes in this PR mean that we can no longer rely on the default value in cases like the following (dim 0 is a broadcast dim): mlir %read = vector.transfer_read %A[%base1, %base2], %f, %mask {permutation_map = affine_map<(d0, d1) -> (0, d1)>} : memref<?x?xf32>, vector<4x9xf32> Instead, the broadcast dimension has to explicitly be marked as "in bounds: mlir %read = vector.transfer_read %A[%base1, %base2], %f, %mask {in_bounds = [true, false], permutation_map = affine_map<(d0, d1) -> (0, d1)>} : memref<?x?xf32>, vector<4x9xf32> All tests with broadcast dims are updated accordingly. #### Changes in "SuperVectorize.cpp" and "Vectorization.cpp" The following patterns in "Vectorization.cpp" are updated to explicitly set the in_bounds attribute to false: * LinalgCopyVTRForwardingPattern and LinalgCopyVTWForwardingPattern Also, vectorizeAffineLoad (from "SuperVectorize.cpp") and vectorizeAsLinalgGeneric (from "Vectorization.cpp") are updated to make sure that xfer Ops created by these hooks set the dimension corresponding to broadcast dims as "in bounds". Otherwise, the Op verifier would complain Note that there is no mechanism to verify whether the corresponding memory access are indeed in bounds. Still, this is consistent with the current behaviour where the broadcast dim would be implicitly assumed to be "in bounds". [1] https://github.com/llvm/llvm-project/blob/4145ad2bac4bb99d5034d60c74bb2789f6c6e802/mlir/include/mlir/Interfaces/VectorInterfaces.td#L243-L246 [2] https://mlir.llvm.org/docs/Dialects/Vector/#vectortransfer_read-vectortransferreadop | 2 年前 | |
[AffineMap] Move result exprs into trailing storage. NFCI. | 4 年前 | |
[MLIR] Add f8E4M3 IEEE 754 type (#97118) This PR adds f8E4M3 type to mlir. f8E4M3 type follows IEEE 754 convention c f8E4M3 (IEEE 754) - Exponent bias: 7 - Maximum stored exponent value: 14 (binary 1110) - Maximum unbiased exponent value: 14 - 7 = 7 - Minimum stored exponent value: 1 (binary 0001) - Minimum unbiased exponent value: 1 − 7 = −6 - Precision specifies the total number of bits used for the significand (mantisa), including implicit leading integer bit = 3 + 1 = 4 - Follows IEEE 754 conventions for representation of special values - Has Positive and Negative zero - Has Positive and Negative infinity - Has NaNs Additional details: - Max exp (unbiased): 7 - Min exp (unbiased): -6 - Infinities (+/-): S.1111.000 - Zeros (+/-): S.0000.000 - NaNs: S.1111.{001, 010, 011, 100, 101, 110, 111} - Max normal number: S.1110.111 = +/-2^(7) x (1 + 0.875) = +/-240 - Min normal number: S.0001.000 = +/-2^(-6) - Max subnormal number: S.0000.111 = +/-2^(-6) x 0.875 = +/-2^(-9) x 7 - Min subnormal number: S.0000.001 = +/-2^(-6) x 0.125 = +/-2^(-9) Related PRs: - [PR-97179](https://github.com/llvm/llvm-project/pull/97179) [APFloat] Add support for f8E4M3 IEEE 754 type | 2 年前 | |
[MLIR] Cyclic AttrType Replacer (#98206) The current AttrTypeReplacer does not allow for custom handling of replacer functions that may cause self-recursion. For example, the replacement of one attr/type may depend on the replacement of another attr/type (by calling into the replacer manually again), which in turn may depend on the replacement of the original attr/type. To enable this functionality, this PR broke out the original AttrTypeReplacer into two parts: - An uncached base version (detail::AttrTypeReplacerBase) that allows registering replacer functions and has logic for invoking it on attr/types & their sub-elements - A cached version (AttrTypeReplacer) that provides the same caching as the original one. This is still the one used everywhere and behavior is unchanged. On top of the uncached base version, a CyclicAttrTypeReplacer is introduced that provides caching & cycle-handling for replacer logic that is cyclic. Cycle-breaking & caching is provided by the CyclicReplacerCache from https://github.com/llvm/llvm-project/pull/98202. Both concrete implementations of the uncached base version use CRTP to avoid dynamic dispatch. The base class merely provides replacer registration & invocation, and is not meant to be used, or otherwise extended elsewhere. | 2 年前 | |
[mlir] Use StringRef::operator== instead of StringRef::equals (NFC) (#91560) I'm planning to remove StringRef::equals in favor of StringRef::operator==. - StringRef::operator==/!= outnumber StringRef::equals by a factor of 10 under mlir/ in terms of their usage. - The elimination of StringRef::equals brings StringRef closer to std::string_view, which has operator== but not equals. - S == "foo" is more readable than S.equals("foo"), especially for !Long.Expression.equals("str") vs Long.Expression != "str". | 2 年前 | |
[mlir] Apply ClangTidy fix (NFC) Prefer to use .empty() instead of checking size(). | 2 年前 | |
[mlir][IR] Add RewriterBase::moveBlockBefore and fix bug in moveOpBefore (#79579) This commit adds a new method to the rewriter API: moveBlockBefore. This op is utilized by inlineRegionBefore and covered by dialect conversion test cases. Also fixes a bug in moveOpBefore, where the previous op location was not passed correctly. Adds a test case to test-strict-pattern-driver.mlir. | 2 年前 | |
[MLIR] Add f8E4M3 IEEE 754 type (#97118) This PR adds f8E4M3 type to mlir. f8E4M3 type follows IEEE 754 convention c f8E4M3 (IEEE 754) - Exponent bias: 7 - Maximum stored exponent value: 14 (binary 1110) - Maximum unbiased exponent value: 14 - 7 = 7 - Minimum stored exponent value: 1 (binary 0001) - Minimum unbiased exponent value: 1 − 7 = −6 - Precision specifies the total number of bits used for the significand (mantisa), including implicit leading integer bit = 3 + 1 = 4 - Follows IEEE 754 conventions for representation of special values - Has Positive and Negative zero - Has Positive and Negative infinity - Has NaNs Additional details: - Max exp (unbiased): 7 - Min exp (unbiased): -6 - Infinities (+/-): S.1111.000 - Zeros (+/-): S.0000.000 - NaNs: S.1111.{001, 010, 011, 100, 101, 110, 111} - Max normal number: S.1110.111 = +/-2^(7) x (1 + 0.875) = +/-240 - Min normal number: S.0001.000 = +/-2^(-6) - Max subnormal number: S.0000.111 = +/-2^(-6) x 0.875 = +/-2^(-9) x 7 - Min subnormal number: S.0000.001 = +/-2^(-6) x 0.125 = +/-2^(-9) Related PRs: - [PR-97179](https://github.com/llvm/llvm-project/pull/97179) [APFloat] Add support for f8E4M3 IEEE 754 type | 2 年前 | |
[mlir] Update method cast calls to function calls The MLIR classes Type/Attribute/Operation/Op/Value support cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast functionality in addition to defining methods with the same name. This change begins the migration of uses of the method to the corresponding function call as has been decided as more consistent. Note that there still exist classes that only define methods directly, such as AffineExpr, and this does not include work currently to support a functional cast/isa call. Context: * https://mlir.llvm.org/deprecation/ at "Use the free function variants for dyn_cast/cast/isa/…" * Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443 Implementation: This follows a previous patch that updated calls op.cast<T>()-> cast<T>(op). However some cases could not handle an unprefixed cast call due to occurrences of variables named cast, or occurring inside of class definitions which would resolve to the method. All C++ files that did not work automatically with cast<T>() are updated here to llvm::cast and similar with the intention that they can be easily updated after the methods are removed through a find-replace. See https://github.com/llvm/llvm-project/compare/main...tpopp:llvm-project:tidy-cast-check for the clang-tidy check that is used and then update printed occurrences of the function to include llvm:: before. One can then run the following: ninja -C $BUILD_DIR clang-tidy run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\ -export-fixes /tmp/cast/casts.yaml mlir/*\ -header-filter=mlir/ -fix rm -rf $BUILD_DIR/tools/mlir/**/*.inc Differential Revision: https://reviews.llvm.org/D150348 | 3 年前 | |
[mlir] Add debug messages for failures of isValidIntOrFloat I have run into assertion failures quite often when calling this method via DenseElementsAttr::get, and I think this would help, at the very least, by printing out the bit width size mismatches, rather than a plain assertion failure. I included all the other cases in the method for completeness | 2 年前 | |
Reimplementing target description concept using DLTI attribute (#92138) and Interfaces. This is a newer implementation of PR https://github.com/llvm/llvm-project/pull/85141 and [RFC](https://discourse.llvm.org/t/rfc-target-description-and-cost-model-in-mlir/76990) by considering reviews and comments on the original PR. As an example of attributes supported by this commit: module attributes { dlti.target_system_spec = #dlti.target_device_spec< #dlti.dl_entry<"dlti.device_id", 0: ui32>, #dlti.dl_entry<"dlti.device_type", "CPU">, #dlti.dl_entry<"dlti.L1_cache_size_in_bytes", 8192 : ui32>>, #dlti.target_device_spec < #dlti.dl_entry<"dlti.device_id", 1: ui32>, #dlti.dl_entry<"dlti.device_type", "GPU">, #dlti.dl_entry<"dlti.max_vector_op_width", 64 : ui32>>, #dlti.target_device_spec < #dlti.dl_entry<"dlti.device_id", 2: ui32>, #dlti.dl_entry<"dlti.device_type", "XPU">>> } | 2 年前 | |
Apply clang-tidy fixes for llvm-else-after-return in BuiltinDialectBytecode.cpp (NFC) | 2 年前 | |
[mlir:Bytecode] Add initial support for dialect defined attribute/type encodings Dialects can opt-in to providing custom encodings by implementing the BytecodeDialectInterface. This interface provides hooks, namely readAttribute/readType and writeAttribute/writeType, that will be used by the bytecode reader and writer. These hooks are provided a reader and writer implementation that can be used to encode various constructs in the underlying bytecode format. A unique feature of this interface is that dialects may choose to only encode a subset of their attributes and types in a custom bytecode format, which can simplify adding new or experimental components that aren't fully baked. Differential Revision: https://reviews.llvm.org/D132498 | 3 年前 | |
[mlir][IR] Remove ShapedType::getSizeInBits This function returns incorrect values for memrefs and vectors due to "widening". Differential Revision: https://reviews.llvm.org/D148501 | 3 年前 | |
[MLIR] Add f8E4M3 IEEE 754 type (#97118) This PR adds f8E4M3 type to mlir. f8E4M3 type follows IEEE 754 convention c f8E4M3 (IEEE 754) - Exponent bias: 7 - Maximum stored exponent value: 14 (binary 1110) - Maximum unbiased exponent value: 14 - 7 = 7 - Minimum stored exponent value: 1 (binary 0001) - Minimum unbiased exponent value: 1 − 7 = −6 - Precision specifies the total number of bits used for the significand (mantisa), including implicit leading integer bit = 3 + 1 = 4 - Follows IEEE 754 conventions for representation of special values - Has Positive and Negative zero - Has Positive and Negative infinity - Has NaNs Additional details: - Max exp (unbiased): 7 - Min exp (unbiased): -6 - Infinities (+/-): S.1111.000 - Zeros (+/-): S.0000.000 - NaNs: S.1111.{001, 010, 011, 100, 101, 110, 111} - Max normal number: S.1110.111 = +/-2^(7) x (1 + 0.875) = +/-240 - Min normal number: S.0001.000 = +/-2^(-6) - Max subnormal number: S.0000.111 = +/-2^(-6) x 0.875 = +/-2^(-9) x 7 - Min subnormal number: S.0000.001 = +/-2^(-6) x 0.125 = +/-2^(-9) Related PRs: - [PR-97179](https://github.com/llvm/llvm-project/pull/97179) [APFloat] Add support for f8E4M3 IEEE 754 type | 2 年前 | |
[mlir] Add config for PDL (#69927) Make it so that PDL in pattern rewrites can be optionally disabled. PDL is still enabled by default and not optional bazel. So this should be a NOP for most folks, while enabling other to disable. This only works with tests disabled. With tests enabled this still compiles but tests fail as there is no lit config to disable tests that depend on PDL rewrites yet. | 2 年前 | |
fix unused variable warnings in conditionals warning was updated in 92023b15099012a657da07ebf49dd7d94a260f84 | 2 年前 | |
[mlir] Extend the promise interface mechanism This patch pairs a promised interface with the object (Op/Attr/Type/Dialect) requesting the promise, ie: declarePromisedInterface<MyAttr, MyInterface>(); Allowing to make fine grained promises. It also adds a mechanism to query if Op/Attr/Type has an specific promise returning true if the promise is there or if an implementation has been added. Finally it adds a couple of Attr|TypeConstraints that can be used in ODS to query if the promise or an implementation is there. This patch tries to solve 2 issues: 1. Different entities cannot use the same promise. declarePromisedInterface<MyInterface>(); // Resolves a promise. MyAttr1::attachInterface<MyInterface>(ctx); // Doesn't resolves a promise, as the previous attachment removed the promise. MyAttr2::attachInterface<MyInterface>(ctx); 2. Is not possible to query if a promise has been declared. Reviewed By: mehdi_amini Differential Revision: https://reviews.llvm.org/D158464 | 2 年前 | |
[mlir] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to remove #include "llvm/ADT/Optional.h". This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[mlir][IR] Fix memory leak in DominanceInfo Differential Revision: https://reviews.llvm.org/D154185 | 3 年前 | |
mlir/LogicalResult: move into llvm (#97309) This patch is part of a project to move the Presburger library into LLVM. | 2 年前 | |
[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] Update method cast calls to function calls The MLIR classes Type/Attribute/Operation/Op/Value support cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast functionality in addition to defining methods with the same name. This change begins the migration of uses of the method to the corresponding function call as has been decided as more consistent. Note that there still exist classes that only define methods directly, such as AffineExpr, and this does not include work currently to support a functional cast/isa call. Context: * https://mlir.llvm.org/deprecation/ at "Use the free function variants for dyn_cast/cast/isa/…" * Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443 Implementation: This follows a previous patch that updated calls op.cast<T>()-> cast<T>(op). However some cases could not handle an unprefixed cast call due to occurrences of variables named cast, or occurring inside of class definitions which would resolve to the method. All C++ files that did not work automatically with cast<T>() are updated here to llvm::cast and similar with the intention that they can be easily updated after the methods are removed through a find-replace. See https://github.com/llvm/llvm-project/compare/main...tpopp:llvm-project:tidy-cast-check for the clang-tidy check that is used and then update printed occurrences of the function to include llvm:: before. One can then run the following: ninja -C $BUILD_DIR clang-tidy run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\ -export-fixes /tmp/cast/casts.yaml mlir/*\ -header-filter=mlir/ -fix rm -rf $BUILD_DIR/tools/mlir/**/*.inc Differential Revision: https://reviews.llvm.org/D150348 | 3 年前 | |
[MLIR] Add f8E4M3 IEEE 754 type (#97118) This PR adds f8E4M3 type to mlir. f8E4M3 type follows IEEE 754 convention c f8E4M3 (IEEE 754) - Exponent bias: 7 - Maximum stored exponent value: 14 (binary 1110) - Maximum unbiased exponent value: 14 - 7 = 7 - Minimum stored exponent value: 1 (binary 0001) - Minimum unbiased exponent value: 1 − 7 = −6 - Precision specifies the total number of bits used for the significand (mantisa), including implicit leading integer bit = 3 + 1 = 4 - Follows IEEE 754 conventions for representation of special values - Has Positive and Negative zero - Has Positive and Negative infinity - Has NaNs Additional details: - Max exp (unbiased): 7 - Min exp (unbiased): -6 - Infinities (+/-): S.1111.000 - Zeros (+/-): S.0000.000 - NaNs: S.1111.{001, 010, 011, 100, 101, 110, 111} - Max normal number: S.1110.111 = +/-2^(7) x (1 + 0.875) = +/-240 - Min normal number: S.0001.000 = +/-2^(-6) - Max subnormal number: S.0000.111 = +/-2^(-6) x 0.875 = +/-2^(-9) x 7 - Min subnormal number: S.0000.001 = +/-2^(-6) x 0.125 = +/-2^(-9) Related PRs: - [PR-97179](https://github.com/llvm/llvm-project/pull/97179) [APFloat] Add support for f8E4M3 IEEE 754 type | 2 年前 | |
Simplify diagnostic error management for MLIR properties API (NFC) (#67409) This is a follow-up to 8c2bff1ab929 which lazy-initialized the diagnostic and removed the need to dynamically abandon() an InFlightDiagnostic. This further simplifies the code to not needed to return a reference to an InFlightDiagnostic and instead eagerly emit errors. Also use emitError as name instead of getDiag which seems more explicit and in-line with the common usage. | 2 年前 | |
[mlir] Do not print empty property (#93379) Skip printing property as <<<NULL ATTRIBUTE>>> when operation has an empty property. Co-authored-by: Biao Wang <biaow@nvidia.com> | 2 年前 | |
Fix remaining build failures with GCC 8.3 (#83266) When compiling for GCC 8.x (< 8.4), SFINAE is disabled for iterator_range constructor causing ambiguous resolution to construct an OperandRange from a MutableOperatorRange, even in the presence of a static_cast<OperatorRange>. This adds an explicit conversion method to lift the ambiguity. Tested with a full MLIR build with GCC 8.3. | 2 年前 | |
[mlir][SCF] Modernize coalesceLoops method to handle scf.for loops with iter_args (#87019) As part of this extension this change also does some general cleanup 1) Make all the methods take RewriterBase as arguments instead of creating their own builders that tend to crash when used within pattern rewrites 2) Split coalesePerfectlyNestedLoops into two separate methods, one for scf.for and other for affine.for. The templatization didnt seem to be buying much there. Also general clean up of tests. | 2 年前 | |
[mlir] Move casting calls from methods to function calls The MLIR classes Type/Attribute/Operation/Op/Value support cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast functionality in addition to defining methods with the same name. This change begins the migration of uses of the method to the corresponding function call as has been decided as more consistent. Note that there still exist classes that only define methods directly, such as AffineExpr, and this does not include work currently to support a functional cast/isa call. Context: - https://mlir.llvm.org/deprecation/ at "Use the free function variants for dyn_cast/cast/isa/…" - Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443 Implementation: This patch updates all remaining uses of the deprecated functionality in mlir/. This was done with clang-tidy as described below and further modifications to GPUBase.td and OpenMPOpsInterfaces.td. Steps are described per line, as comments are removed by git: 0. Retrieve the change from the following to build clang-tidy with an additional check: main...tpopp:llvm-project:tidy-cast-check 1. Build clang-tidy 2. Run clang-tidy over your entire codebase while disabling all checks and enabling the one relevant one. Run on all header files also. 3. Delete .inc files that were also modified, so the next build rebuilds them to a pure state. ninja -C $BUILD_DIR clang-tidy run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\ -header-filter=mlir/ mlir/* -fix rm -rf $BUILD_DIR/tools/mlir/**/*.inc Differential Revision: https://reviews.llvm.org/D151542 | 3 年前 | |
[mlir][IR] Trigger notifyOperationRemoved callback for nested ops (#66771) When cloning an op, the notifyOperationInserted callback is triggered for all nested ops. Similarly, the notifyOperationRemoved callback should be triggered for all nested ops when removing an op. Listeners may inspect the IR during a notifyOperationRemoved callback. Therefore, when multiple ops are removed in a single RewriterBase::eraseOp call, the notifications must be triggered in an order in which the ops could have been removed one-by-one: * Op removals must be interleaved with notifyOperationRemoved callbacks. A callback is triggered right before the respective op is removed. * Ops are removed post-order and in reverse order. Other traversal orders could delete an op that still has uses. (This is not avoidable in graph regions and with cyclic block graphs.) Differential Revision: Imported from https://reviews.llvm.org/D144193. | 2 年前 | |
[mlir][gpu] Introduce gpu.dynamic_shared_memory Op (#71546) While the gpu.launch Op allows setting the size via the dynamic_shared_memory_size argument, accessing the dynamic shared memory is very convoluted. This PR implements the proposed Op, gpu.dynamic_shared_memory that aims to simplify the utilization of dynamic shared memory. RFC: https://discourse.llvm.org/t/rfc-simplifying-dynamic-shared-memory-access-in-gpu/ **Proposal from RFC** This PR gpu.dynamic.shared.memory Op to use dynamic shared memory feature efficiently. It is is a powerful feature that enables the allocation of shared memory at runtime with the kernel launch on the host. Afterwards, the memory can be accessed directly from the device. I believe similar story exists for AMDGPU. **Current way Using Dynamic Shared Memory with MLIR** Let me illustrate the challenges of using dynamic shared memory in MLIR with an example below. The process involves several steps: - memref.global 0-sized array LLVM's NVPTX backend expects - dynamic_shared_memory_size Set the size of dynamic shared memory - memref.get_global Access the global symbol - reinterpret_cast and subview Many OPs for pointer arithmetic `` // Step 1. Create 0-sized global symbol. Manually set the alignment memref.global "private" @dynamicShmem : memref<0xf16, 3> { alignment = 16 } func.func @main() { // Step 2. Allocate shared memory gpu.launch blocks(...) threads(...) dynamic_shared_memory_size %c10000 { // Step 3. Access the global object %shmem = memref.get_global @dynamicShmem : memref<0xf16, 3> // Step 4. A sequence of memref.reinterpret_cast and memref.subview operations. %4 = memref.reinterpret_cast %shmem to offset: [0], sizes: [14, 64, 128], strides: [8192,128,1] : memref<0xf16, 3> to memref<14x64x128xf16,3> %5 = memref.subview %4[7, 0, 0][7, 64, 128][1,1,1] : memref<14x64x128xf16,3> to memref<7x64x128xf16, strided<[8192, 128, 1], offset: 57344>, 3> %6 = memref.subview %5[2, 0, 0][1, 64, 128][1,1,1] : memref<7x64x128xf16, strided<[8192, 128, 1], offset: 57344>, 3> to memref<64x128xf16, strided<[128, 1], offset: 73728>, 3> %7 = memref.subview %6[0, 0][64, 64][1,1] : memref<64x128xf16, strided<[128, 1], offset: 73728>, 3> to memref<64x64xf16, strided<[128, 1], offset: 73728>, 3> %8 = memref.subview %6[32, 0][64, 64][1,1] : memref<64x128xf16, strided<[128, 1], offset: 73728>, 3> to memref<64x64xf16, strided<[128, 1], offset: 77824>, 3> // Step.5 Use "test.use.shared.memory"(%7) : (memref<64x64xf16, strided<[128, 1], offset: 73728>, 3>) -> (index) "test.use.shared.memory"(%8) : (memref<64x64xf16, strided<[128, 1], offset: 77824>, 3>) -> (index) gpu.terminator } Let’s write the program above with that: func.func @main() { gpu.launch blocks(...) threads(...) dynamic_shared_memory_size %c10000 { %i = arith.constant 18 : index // Step 1: Obtain shared memory directly %shmem = gpu.dynamic_shared_memory : memref<?xi8, 3> %c147456 = arith.constant 147456 : index %c155648 = arith.constant 155648 : index %7 = memref.view %shmem[%c147456][] : memref<?xi8, 3> to memref<64x64xf16, 3> %8 = memref.view %shmem[%c155648][] : memref<?xi8, 3> to memref<64x64xf16, 3> // Step 2: Utilize the shared memory "test.use.shared.memory"(%7) : (memref<64x64xf16, 3>) -> (index) "test.use.shared.memory"(%8) : (memref<64x64xf16, 3>) -> (index) } } `` This PR resolves #72513 | 2 年前 | |
[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 年前 | |
[mlir] Promote the SubElementInterfaces to a core Attribute/Type construct This commit restructures the sub element infrastructure to be a core part of attributes and types, instead of being relegated to an interface. This establishes sub element walking/replacement as something "always there", which makes it easier to rely on for correctness/etc (which various bits of infrastructure want, such as Symbols). Attribute/Type now have walk and replace methods directly accessible, which provide power API for interacting with sub elements. As part of this, a new AttrTypeWalker class is introduced that supports caching walked attributes/types, and a friendlier API (see the simplification of symbol walking in SymbolTable.cpp). Differential Revision: https://reviews.llvm.org/D142272 | 3 年前 | |
[mlir] Move casting calls from methods to function calls The MLIR classes Type/Attribute/Operation/Op/Value support cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast functionality in addition to defining methods with the same name. This change begins the migration of uses of the method to the corresponding function call as has been decided as more consistent. Note that there still exist classes that only define methods directly, such as AffineExpr, and this does not include work currently to support a functional cast/isa call. Context: - https://mlir.llvm.org/deprecation/ at "Use the free function variants for dyn_cast/cast/isa/…" - Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443 Implementation: This patch updates all remaining uses of the deprecated functionality in mlir/. This was done with clang-tidy as described below and further modifications to GPUBase.td and OpenMPOpsInterfaces.td. Steps are described per line, as comments are removed by git: 0. Retrieve the change from the following to build clang-tidy with an additional check: main...tpopp:llvm-project:tidy-cast-check 1. Build clang-tidy 2. Run clang-tidy over your entire codebase while disabling all checks and enabling the one relevant one. Run on all header files also. 3. Delete .inc files that were also modified, so the next build rebuilds them to a pure state. ninja -C $BUILD_DIR clang-tidy run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\ -header-filter=mlir/ mlir/* -fix rm -rf $BUILD_DIR/tools/mlir/**/*.inc Differential Revision: https://reviews.llvm.org/D151542 | 3 年前 | |
[mlir] Move FunctionInterfaces to Interfaces directory and inherit from CallableOpInterface Functions are always callable operations and thus every operation implementing the FunctionOpInterface also implements the CallableOpInterface. The only exception was the FuncOp in the toy example. To make implementation of the FunctionOpInterface easier, this commit lets FunctionOpInterface inherit from CallableOpInterface and merges some of their methods. More precisely, the CallableOpInterface has methods to get the argument and result attributes and a method to get the result types of the callable region. These methods are always implemented the same way as their analogues in FunctionOpInterface and thus this commit moves all the argument and result attribute handling methods to the callable interface as well as the methods to get the argument and result types. The FuntionOpInterface then does not have to declare them as well, but just inherits them from the CallableOpInterface. Adding the inheritance relation also required to move the FunctionOpInterface from the IR directory to the Interfaces directory since IR should not depend on Interfaces. Reviewed By: jpienaar, springerm Differential Revision: https://reviews.llvm.org/D157988 | 2 年前 | |
[MLIR] Add f8E4M3 IEEE 754 type (#97118) This PR adds f8E4M3 type to mlir. f8E4M3 type follows IEEE 754 convention c f8E4M3 (IEEE 754) - Exponent bias: 7 - Maximum stored exponent value: 14 (binary 1110) - Maximum unbiased exponent value: 14 - 7 = 7 - Minimum stored exponent value: 1 (binary 0001) - Minimum unbiased exponent value: 1 − 7 = −6 - Precision specifies the total number of bits used for the significand (mantisa), including implicit leading integer bit = 3 + 1 = 4 - Follows IEEE 754 conventions for representation of special values - Has Positive and Negative zero - Has Positive and Negative infinity - Has NaNs Additional details: - Max exp (unbiased): 7 - Min exp (unbiased): -6 - Infinities (+/-): S.1111.000 - Zeros (+/-): S.0000.000 - NaNs: S.1111.{001, 010, 011, 100, 101, 110, 111} - Max normal number: S.1110.111 = +/-2^(7) x (1 + 0.875) = +/-240 - Min normal number: S.0001.000 = +/-2^(-6) - Max subnormal number: S.0000.111 = +/-2^(-6) x 0.875 = +/-2^(-9) x 7 - Min subnormal number: S.0000.001 = +/-2^(-6) x 0.125 = +/-2^(-9) Related PRs: - [PR-97179](https://github.com/llvm/llvm-project/pull/97179) [APFloat] Add support for f8E4M3 IEEE 754 type | 2 年前 | |
[mlir] Move casting calls from methods to function calls The MLIR classes Type/Attribute/Operation/Op/Value support cast/dyn_cast/isa/dyn_cast_or_null functionality through llvm's doCast functionality in addition to defining methods with the same name. This change begins the migration of uses of the method to the corresponding function call as has been decided as more consistent. Note that there still exist classes that only define methods directly, such as AffineExpr, and this does not include work currently to support a functional cast/isa call. Context: - https://mlir.llvm.org/deprecation/ at "Use the free function variants for dyn_cast/cast/isa/…" - Original discussion at https://discourse.llvm.org/t/preferred-casting-style-going-forward/68443 Implementation: This patch updates all remaining uses of the deprecated functionality in mlir/. This was done with clang-tidy as described below and further modifications to GPUBase.td and OpenMPOpsInterfaces.td. Steps are described per line, as comments are removed by git: 0. Retrieve the change from the following to build clang-tidy with an additional check: main...tpopp:llvm-project:tidy-cast-check 1. Build clang-tidy 2. Run clang-tidy over your entire codebase while disabling all checks and enabling the one relevant one. Run on all header files also. 3. Delete .inc files that were also modified, so the next build rebuilds them to a pure state. ninja -C $BUILD_DIR clang-tidy run-clang-tidy -clang-tidy-binary=$BUILD_DIR/bin/clang-tidy -checks='-*,misc-cast-functions'\ -header-filter=mlir/ mlir/* -fix rm -rf $BUILD_DIR/tools/mlir/**/*.inc Differential Revision: https://reviews.llvm.org/D151542 | 3 年前 | |
Make MLIR Value more consistent in terms of const "correctness" (NFC) (#72765) MLIR can't really be const-correct (it would need a ConstValue class alongside the Value class really, like ArrayRef and MutableArrayRef). This is however making is more consistent: method that are directly modifying the Value shouldn't be marked const. | 2 年前 | |
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][IR] Make verifyDominanceOfContainedRegions iterative (#74428) This commit refactors verifyDominanceOfContainedRegions to iterative algorithms similar to https://reviews.llvm.org/D154925 to fix stack overflow for deeply nested regions (e.g. https://github.com/llvm/circt/issues/5316). There should be no functional change except that this could result in slightly different order of verification. | 2 年前 | |
[mlir][IR][NFC] Move walk definitions to header file This allows users to provide custom Iterator templates. A new iterator will be added in a subsequent change. Also rename makeRange to makeIterable and add a test case for the reverse iterator. Differential Revision: https://reviews.llvm.org/D144887 | 3 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 5 年前 | ||
| 3 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 2 年前 | ||
| 3 年前 |