| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[MLIR] Clean up pass options for test-loop-fusion and affine-super-vectorizer-test (#87606) Before the change test-loop-fusion and affine-super-vectorizer-test options were in their own category. This was because they used the standard llvm command line parsing with llvm::cl::opt. This PR moves them over to the mlir Pass::Option class. Before the change $ mlir-opt --help ... General options: ... Compiler passes to run Passes: ... Pass Pipelines: ... Generic Options: .... affine-super-vectorizer-test options: --backward-slicing ... --vectorize-affine-loop-nest test-loop-fusion options: --test-loop-fusion-dependence-check ... --test-loop-fusion-transformation After the change $ mlir-opt --help ... General options: ... Compiler passes to run Passes: ... --affine-super-vectorizer-test --backward-slicing ... --vectorize-affine-loop-nest ... --test-loop-fusion options: --test-loop-fusion-dependence-check ... --test-loop-fusion-transformation ... Pass Pipelines: ... Generic Options: ... --------- Signed-off-by: philass <plassen@groq.com> | 2 年前 | |
[mlir][affine] Check the input vector sizes to be greater than 0 (#65293) In the process of vectorization of the affine loop, the 0 vector size causes the crash with building the invalid AffineForOp. We can catch the case beforehand propagating to the assertion. See: https://github.com/llvm/llvm-project/issues/64262 | 2 年前 | |
[mlir][affine] SuperVectorizer only widen ops with valid types fixes https://github.com/llvm/llvm-project/issues/61309 Differential Revision: https://reviews.llvm.org/D147679 | 3 年前 | |
[mlir][NFC] Update textual references of func to func.func in Affine/ tests The special case parsing of func operations is being removed. | 4 年前 | |
[MLIR] Clean up pass options for test-loop-fusion and affine-super-vectorizer-test (#87606) Before the change test-loop-fusion and affine-super-vectorizer-test options were in their own category. This was because they used the standard llvm command line parsing with llvm::cl::opt. This PR moves them over to the mlir Pass::Option class. Before the change $ mlir-opt --help ... General options: ... Compiler passes to run Passes: ... Pass Pipelines: ... Generic Options: .... affine-super-vectorizer-test options: --backward-slicing ... --vectorize-affine-loop-nest test-loop-fusion options: --test-loop-fusion-dependence-check ... --test-loop-fusion-transformation After the change $ mlir-opt --help ... General options: ... Compiler passes to run Passes: ... --affine-super-vectorizer-test --backward-slicing ... --vectorize-affine-loop-nest ... --test-loop-fusion options: --test-loop-fusion-dependence-check ... --test-loop-fusion-transformation ... Pass Pipelines: ... Generic Options: ... --------- Signed-off-by: philass <plassen@groq.com> | 2 年前 | |
[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 | 1 年前 | |
[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 | 1 年前 | |
[mlir][NFC] Update textual references of func to func.func in Affine/ tests The special case parsing of func operations is being removed. | 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 | 1 年前 | |
[mlir][NFC] Update textual references of func to func.func in Affine/ tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in Affine/ tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][vector] Rename vector reductions: maxf → maximumf, minf → minimumf This patch is part of a larger initiative aimed at fixing floating-point max and min operations in MLIR: https://discourse.llvm.org/t/rfc-fix-floating-point-max-and-min-operations-in-mlir/72671. Here, we are addressing task 2.1 from the plan, which involves renaming the vector reductions to align with the semantics of the corresponding LLVM intrinsics. Reviewed By: dcaballe Differential Revision: https://reviews.llvm.org/D158618 | 2 年前 | |
[mlir][NFC] Update textual references of func to func.func in Affine/ tests The special case parsing of func operations is being removed. | 4 年前 | |
[mlir][NFC] Update textual references of func to func.func in Affine/ tests The special case parsing of func operations is being removed. | 4 年前 | |
[MLIR] Clean up pass options for test-loop-fusion and affine-super-vectorizer-test (#87606) Before the change test-loop-fusion and affine-super-vectorizer-test options were in their own category. This was because they used the standard llvm command line parsing with llvm::cl::opt. This PR moves them over to the mlir Pass::Option class. Before the change $ mlir-opt --help ... General options: ... Compiler passes to run Passes: ... Pass Pipelines: ... Generic Options: .... affine-super-vectorizer-test options: --backward-slicing ... --vectorize-affine-loop-nest test-loop-fusion options: --test-loop-fusion-dependence-check ... --test-loop-fusion-transformation After the change $ mlir-opt --help ... General options: ... Compiler passes to run Passes: ... --affine-super-vectorizer-test --backward-slicing ... --vectorize-affine-loop-nest ... --test-loop-fusion options: --test-loop-fusion-dependence-check ... --test-loop-fusion-transformation ... Pass Pipelines: ... Generic Options: ... --------- Signed-off-by: philass <plassen@groq.com> | 2 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 年前 | ||
| 2 年前 | ||
| 3 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 4 年前 | ||
| 1 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 4 年前 | ||
| 2 年前 |