Changes in loop-tiling-validity.mlir

227ed2f4 - [mlir][NFC] Update textual references of `func` to `func.func` in Affine/ tests

Wed, 20 Apr 2022 23:13:44 +0000

[mlir][NFC] Update textual references of `func` to `func.func` in Affine/ testsThe special case parsing of `func` operations is being removed. List of files: /llvm-project-15.0.7/mlir/test/Dialect/Affine/loop-tiling-validity.mlir

9cf9ed94 - Multiple fixes to affine loop tiling return status and checks

Mon, 27 Dec 2021 19:12:14 +0000

Multiple fixes to affine loop tiling return status and checksFix crash in the presence of yield values. Multiple fixes to affine looptiling pre-condition checks and return status. Do not signal passfailure on a failure to tile since the IR is still valid. Detect indexset computation failure in checkIfHyperrectangular and return failure.Replace assertions with proper status return. Move checks to anappropriate place earlier in the utility before mutation happens.Differential Revision: https://reviews.llvm.org/D116738 List of files: /llvm-project-15.0.7/mlir/test/Dialect/Affine/loop-tiling-validity.mlir

a54f4eae - [MLIR] Replace std ops with arith dialect ops

Tue, 12 Oct 2021 23:14:57 +0000

[MLIR] Replace std ops with arith dialect opsPrecursor: https://reviews.llvm.org/D110200Removed redundant ops from the standard dialect that were moved to the`arith` or `math` dialects.Renamed all instances of operations in the codebase and in tests.Reviewed By: rriddle, jpienaarDifferential Revision: https://reviews.llvm.org/D110797 List of files: /llvm-project-15.0.7/mlir/test/Dialect/Affine/loop-tiling-validity.mlir

e2310704 - [MLIR] Create memref dialect and move dialect-specific ops from std.

Wed, 10 Feb 2021 12:53:11 +0000

[MLIR] Create memref dialect and move dialect-specific ops from std.Create the memref dialect and move dialect-specific opsfrom std dialect to this dialect.Moved ops:AllocOp -> MemRef_AllocOpAllocaOp -> MemRef_AllocaOpAssumeAlignmentOp -> MemRef_AssumeAlignmentOpDeallocOp -> MemRef_DeallocOpDimOp -> MemRef_DimOpMemRefCastOp -> MemRef_CastOpMemRefReinterpretCastOp -> MemRef_ReinterpretCastOpGetGlobalMemRefOp -> MemRef_GetGlobalOpGlobalMemRefOp -> MemRef_GlobalOpLoadOp -> MemRef_LoadOpPrefetchOp -> MemRef_PrefetchOpReshapeOp -> MemRef_ReshapeOpStoreOp -> MemRef_StoreOpSubViewOp -> MemRef_SubViewOpTransposeOp -> MemRef_TransposeOpTensorLoadOp -> MemRef_TensorLoadOpTensorStoreOp -> MemRef_TensorStoreOpTensorToMemRefOp -> MemRef_BufferCastOpViewOp -> MemRef_ViewOpThe roadmap to split the memref dialect from std is discussed here:https://llvm.discourse.group/t/rfc-split-the-memref-dialect-from-std/2667Differential Revision: https://reviews.llvm.org/D98041 List of files: /llvm-project-15.0.7/mlir/test/Dialect/Affine/loop-tiling-validity.mlir

a89035d7 - Revert "[MLIR] Create memref dialect and move several dialect-specific ops from std."

Thu, 18 Feb 2021 11:49:52 +0000

Revert "[MLIR] Create memref dialect and move several dialect-specific ops from std."This commit introduced a cyclic dependency:Memref dialect depends on Standard because it used ConstantIndexOp.Std depends on the MemRef dialect in its EDSC/Intrinsics.hWorking on a fix.This reverts commit 8aa6c3765b924d86f623d452777eb76b83bf2787. List of files: /llvm-project-15.0.7/mlir/test/Dialect/Affine/loop-tiling-validity.mlir

8aa6c376 - [MLIR] Create memref dialect and move several dialect-specific ops from std.

Wed, 10 Feb 2021 12:53:11 +0000

[MLIR] Create memref dialect and move several dialect-specific ops from std.Create the memref dialect and move several dialect-specific ops withoutdependencies to other ops from std dialect to this dialect.Moved ops:AllocOp -> MemRef_AllocOpAllocaOp -> MemRef_AllocaOpDeallocOp -> MemRef_DeallocOpMemRefCastOp -> MemRef_CastOpGetGlobalMemRefOp -> MemRef_GetGlobalOpGlobalMemRefOp -> MemRef_GlobalOpPrefetchOp -> MemRef_PrefetchOpReshapeOp -> MemRef_ReshapeOpStoreOp -> MemRef_StoreOpTransposeOp -> MemRef_TransposeOpViewOp -> MemRef_ViewOpThe roadmap to split the memref dialect from std is discussed here:https://llvm.discourse.group/t/rfc-split-the-memref-dialect-from-std/2667Differential Revision: https://reviews.llvm.org/D96425 List of files: /llvm-project-15.0.7/mlir/test/Dialect/Affine/loop-tiling-validity.mlir

ebcc0225 - [mlir][AsmPrinter] Refactor printing to only print aliases for attributes/types that will exist in the output.

Tue, 10 Nov 2020 05:50:31 +0000

[mlir][AsmPrinter] Refactor printing to only print aliases for attributes/types that will exist in the output.This revision refactors the way that attributes/types are considered when generating aliases. Instead of considering all of the attributes/types of every operation, we perform a "fake" print step that prints the operations using a dummy printer to collect the attributes and types that would actually be printed during the real process. This removes a lot of attributes/types from consideration that generally won't end up in the final output, e.g. affine map attributes in an `affine.apply`/`affine.for`.This resolves a long standing TODO w.r.t aliases, and helps to have a much cleaner textual output format. As a datapoint to the latter, as part of this change several tests were identified as testing for the presence of attributes aliases that weren't actually referenced by the custom form of any operation.To ensure that this wouldn't cause a large degradation in compile time due to the second full print, I benchmarked this change on a very large module with a lot of operations(The file is ~673M/~4.7 million lines long). This file before this change take ~6.9 seconds to print in the custom form, and ~7 seconds after this change. In the custom assembly case, this added an average of a little over ~100 miliseconds to the compile time. This increase was due to the way that argument attributes on functions are structured and how they get printed; i.e. with a better representation the negative impact here can be greatly decreased. When printing in the generic form, this revision had no observable impact on the compile time. This benchmarking leads me to believe that the impact of this change on compile time w.r.t printing is closely related to `print` methods that perform a lot of additional/complex processing outside of the OpAsmPrinter.Differential Revision: https://reviews.llvm.org/D90512 List of files: /llvm-project-15.0.7/mlir/test/Dialect/Affine/loop-tiling-validity.mlir

754e09f9 - [MLIR] Add tiling validity check to loop tiling pass

Thu, 06 Aug 2020 20:25:49 +0000

[MLIR] Add tiling validity check to loop tiling passThis revision aims to provide a new API, `checkTilingLegality`, toverify that the loop tiling result still satisifes the dependenceconstraints of the original loop nest.Previously, there was no check for the validity of tiling. For instance:```func @diagonal_dependence() { %A = alloc() : memref<64x64xf32> affine.for %i = 0 to 64 { affine.for %j = 0 to 64 { %0 = affine.load %A[%j, %i] : memref<64x64xf32> %1 = affine.load %A[%i, %j - 1] : memref<64x64xf32> %2 = addf %0, %1 : f32 affine.store %2, %A[%i, %j] : memref<64x64xf32> } } return}```You can find more information about this example from the Section 3.11of [1].In general, there are three types of dependences here: two flowdependences, one in direction `(i, j) = (0, 1)` (notation that depicts avector in the 2D iteration space), one in `(i, j) = (1, -1)`; and oneanti dependence in the direction `(-1, 1)`.Since two of them are along the diagonal in opposite directions, thedefault tiling method in `affine`, which tiles the iteration space intorectangles, will violate the legality condition proposed by Irigoin andTriolet [2]. [2] implies two tiles cannot depend on each other, while inthe `affine` tiling case, two rectangles along the same diagonal areindeed dependent, which simply violates the rule.This diff attempts to put together a validator that checks whether therule from [2] is violated or not when applying the default tiling methodin `affine`.The canonical way to perform such validation is by examining the effectfrom adding the constraint from Irigoin and Triolet to the existingdependence constraints.Since we already have the prior knowlegde that `affine` tiles in ahyper-rectangular way, and the resulting tiles will be scheduled in thesame order as their respective loop indices, we can simplify thesolution to just checking whether all dependence components arenon-negative along the tiling dimensions.We put this algorithm into a new API called `checkTilingLegality` under`LoopTiling.cpp`. This function iterates every `load`/`store` pair, andif there is any dependence between them, we get the dependence component and check whether it has any negative component. This function returns `failure` if the legality condition is violated.[1]. Bondhugula, Uday. Effective Automatic parallelization and locality optimization using the Polyhedral model. https://dl.acm.org/doi/book/10.5555/1559029[2]. Irigoin, F. and Triolet, R. Supernode Partitioning. https://dl.acm.org/doi/10.1145/73560.73588Differential Revision: https://reviews.llvm.org/D84882 List of files: /llvm-project-15.0.7/mlir/test/Dialect/Affine/loop-tiling-validity.mlir