2018-09-13 01:21:23 +08:00
|
|
|
//===- LoopAnalysis.cpp - Misc loop analysis routines //-------------------===//
|
|
|
|
//
|
2020-01-26 11:58:30 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
2019-12-24 01:35:36 +08:00
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2018-09-13 01:21:23 +08:00
|
|
|
//
|
2019-12-24 01:35:36 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2018-09-13 01:21:23 +08:00
|
|
|
//
|
|
|
|
// This file implements miscellaneous loop analysis routines.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "mlir/Analysis/LoopAnalysis.h"
|
|
|
|
|
|
|
|
#include "mlir/Analysis/AffineAnalysis.h"
|
2019-02-23 08:51:08 +08:00
|
|
|
#include "mlir/Analysis/AffineStructures.h"
|
2019-01-26 22:59:23 +08:00
|
|
|
#include "mlir/Analysis/NestedMatcher.h"
|
2020-03-21 05:18:47 +08:00
|
|
|
#include "mlir/Dialect/Affine/IR/AffineOps.h"
|
|
|
|
#include "mlir/Dialect/Affine/IR/AffineValueMap.h"
|
2018-10-04 01:07:54 +08:00
|
|
|
#include "mlir/Support/MathExtras.h"
|
[MLIR] Add support for permutation_map
This CL hooks up and uses permutation_map in vector_transfer ops.
In particular, when going into the nuts and bolts of the implementation, it
became clear that cases arose that required supporting broadcast semantics.
Broadcast semantics are thus added to the general permutation_map.
The verify methods and tests are updated accordingly.
Examples of interest include.
Example 1:
The following MLIR snippet:
```mlir
for %i3 = 0 to %M {
for %i4 = 0 to %N {
for %i5 = 0 to %P {
%a5 = load %A[%i4, %i5, %i3] : memref<?x?x?xf32>
}}}
```
may vectorize with {permutation_map: (d0, d1, d2) -> (d2, d1)} into:
```mlir
for %i3 = 0 to %0 step 32 {
for %i4 = 0 to %1 {
for %i5 = 0 to %2 step 256 {
%4 = vector_transfer_read %arg0, %i4, %i5, %i3
{permutation_map: (d0, d1, d2) -> (d2, d1)} :
(memref<?x?x?xf32>, index, index) -> vector<32x256xf32>
}}}
````
Meaning that vector_transfer_read will be responsible for reading the 2-D slice:
`%arg0[%i4, %i5:%15+256, %i3:%i3+32]` into vector<32x256xf32>. This will
require a transposition when vector_transfer_read is further lowered.
Example 2:
The following MLIR snippet:
```mlir
%cst0 = constant 0 : index
for %i0 = 0 to %M {
%a0 = load %A[%cst0, %cst0] : memref<?x?xf32>
}
```
may vectorize with {permutation_map: (d0) -> (0)} into:
```mlir
for %i0 = 0 to %0 step 128 {
%3 = vector_transfer_read %arg0, %c0_0, %c0_0
{permutation_map: (d0, d1) -> (0)} :
(memref<?x?xf32>, index, index) -> vector<128xf32>
}
````
Meaning that vector_transfer_read will be responsible of reading the 0-D slice
`%arg0[%c0, %c0]` into vector<128xf32>. This will require a 1-D vector
broadcast when vector_transfer_read is further lowered.
Additionally, some minor cleanups and refactorings are performed.
One notable thing missing here is the composition with a projection map during
materialization. This is because I could not find an AffineMap composition
that operates on AffineMap directly: everything related to composition seems
to require going through SSAValue and only operates on AffinMap at a distance
via AffineValueMap. I have raised this concern a bunch of times already, the
followup CL will actually do something about it.
In the meantime, the projection is hacked at a minimum to pass verification
and materialiation tests are temporarily incorrect.
PiperOrigin-RevId: 224376828
2018-12-07 03:37:25 +08:00
|
|
|
|
|
|
|
#include "llvm/ADT/DenseSet.h"
|
2018-11-14 20:04:10 +08:00
|
|
|
#include "llvm/ADT/SmallString.h"
|
[MLIR] Add support for permutation_map
This CL hooks up and uses permutation_map in vector_transfer ops.
In particular, when going into the nuts and bolts of the implementation, it
became clear that cases arose that required supporting broadcast semantics.
Broadcast semantics are thus added to the general permutation_map.
The verify methods and tests are updated accordingly.
Examples of interest include.
Example 1:
The following MLIR snippet:
```mlir
for %i3 = 0 to %M {
for %i4 = 0 to %N {
for %i5 = 0 to %P {
%a5 = load %A[%i4, %i5, %i3] : memref<?x?x?xf32>
}}}
```
may vectorize with {permutation_map: (d0, d1, d2) -> (d2, d1)} into:
```mlir
for %i3 = 0 to %0 step 32 {
for %i4 = 0 to %1 {
for %i5 = 0 to %2 step 256 {
%4 = vector_transfer_read %arg0, %i4, %i5, %i3
{permutation_map: (d0, d1, d2) -> (d2, d1)} :
(memref<?x?x?xf32>, index, index) -> vector<32x256xf32>
}}}
````
Meaning that vector_transfer_read will be responsible for reading the 2-D slice:
`%arg0[%i4, %i5:%15+256, %i3:%i3+32]` into vector<32x256xf32>. This will
require a transposition when vector_transfer_read is further lowered.
Example 2:
The following MLIR snippet:
```mlir
%cst0 = constant 0 : index
for %i0 = 0 to %M {
%a0 = load %A[%cst0, %cst0] : memref<?x?xf32>
}
```
may vectorize with {permutation_map: (d0) -> (0)} into:
```mlir
for %i0 = 0 to %0 step 128 {
%3 = vector_transfer_read %arg0, %c0_0, %c0_0
{permutation_map: (d0, d1) -> (0)} :
(memref<?x?xf32>, index, index) -> vector<128xf32>
}
````
Meaning that vector_transfer_read will be responsible of reading the 0-D slice
`%arg0[%c0, %c0]` into vector<128xf32>. This will require a 1-D vector
broadcast when vector_transfer_read is further lowered.
Additionally, some minor cleanups and refactorings are performed.
One notable thing missing here is the composition with a projection map during
materialization. This is because I could not find an AffineMap composition
that operates on AffineMap directly: everything related to composition seems
to require going through SSAValue and only operates on AffinMap at a distance
via AffineValueMap. I have raised this concern a bunch of times already, the
followup CL will actually do something about it.
In the meantime, the projection is hacked at a minimum to pass verification
and materialiation tests are temporarily incorrect.
PiperOrigin-RevId: 224376828
2018-12-07 03:37:25 +08:00
|
|
|
#include <type_traits>
|
2018-09-13 01:21:23 +08:00
|
|
|
|
2018-10-04 06:39:12 +08:00
|
|
|
using namespace mlir;
|
2018-09-13 01:21:23 +08:00
|
|
|
|
|
|
|
/// Returns the trip count of the loop as an affine expression if the latter is
|
|
|
|
/// expressible as an affine expression, and nullptr otherwise. The trip count
|
2019-03-12 23:00:52 +08:00
|
|
|
/// expression is simplified before returning. This method only utilizes map
|
|
|
|
/// composition to construct lower and upper bounds before computing the trip
|
|
|
|
/// count expressions.
|
|
|
|
void mlir::buildTripCountMapAndOperands(
|
2019-09-15 03:10:18 +08:00
|
|
|
AffineForOp forOp, AffineMap *tripCountMap,
|
2019-12-24 06:45:01 +08:00
|
|
|
SmallVectorImpl<Value> *tripCountOperands) {
|
2018-09-13 01:21:23 +08:00
|
|
|
int64_t loopSpan;
|
|
|
|
|
2019-03-26 02:13:31 +08:00
|
|
|
int64_t step = forOp.getStep();
|
2019-06-05 10:18:23 +08:00
|
|
|
OpBuilder b(forOp.getOperation());
|
2018-09-13 01:21:23 +08:00
|
|
|
|
2019-03-26 02:13:31 +08:00
|
|
|
if (forOp.hasConstantBounds()) {
|
|
|
|
int64_t lb = forOp.getConstantLowerBound();
|
|
|
|
int64_t ub = forOp.getConstantUpperBound();
|
2018-11-07 21:44:50 +08:00
|
|
|
loopSpan = ub - lb;
|
2019-03-12 23:00:52 +08:00
|
|
|
if (loopSpan < 0)
|
|
|
|
loopSpan = 0;
|
2019-09-15 03:10:18 +08:00
|
|
|
*tripCountMap = b.getConstantAffineMap(ceilDiv(loopSpan, step));
|
2019-03-12 23:00:52 +08:00
|
|
|
tripCountOperands->clear();
|
|
|
|
return;
|
2018-09-13 01:21:23 +08:00
|
|
|
}
|
2019-03-26 02:13:31 +08:00
|
|
|
auto lbMap = forOp.getLowerBoundMap();
|
|
|
|
auto ubMap = forOp.getUpperBoundMap();
|
2019-03-12 23:00:52 +08:00
|
|
|
if (lbMap.getNumResults() != 1) {
|
2019-09-15 03:10:18 +08:00
|
|
|
*tripCountMap = AffineMap();
|
2019-03-12 23:00:52 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-09-15 03:10:18 +08:00
|
|
|
// Difference of each upper bound expression from the single lower bound
|
|
|
|
// expression (divided by the step) provides the expressions for the trip
|
|
|
|
// count map.
|
2020-03-14 12:15:07 +08:00
|
|
|
AffineValueMap ubValueMap(ubMap, forOp.getUpperBoundOperands());
|
2019-03-12 23:00:52 +08:00
|
|
|
|
2019-09-15 03:10:18 +08:00
|
|
|
SmallVector<AffineExpr, 4> lbSplatExpr(ubValueMap.getNumResults(),
|
|
|
|
lbMap.getResult(0));
|
[MLIR] Improve support for 0-dimensional Affine Maps.
Summary:
Modified AffineMap::get to remove support for the overload which allowed
an ArrayRef of AffineExpr but no context (and gathered the context from a
presumed first entry, resulting in bugs when there were 0 results).
Instead, we support only a ArrayRef and a context, and a version which
takes a single AffineExpr.
Additionally, removed some now needless case logic which previously
special cased which call to AffineMap::get to use.
Reviewers: flaub, bondhugula, rriddle!, nicolasvasilache, ftynse, ulysseB, mravishankar, antiagainst, aartbik
Subscribers: mehdi_amini, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, liufengdb, Joonsoo, bader, grosul1, frgossen, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D78226
2020-04-16 02:12:47 +08:00
|
|
|
auto lbMapSplat = AffineMap::get(lbMap.getNumDims(), lbMap.getNumSymbols(),
|
|
|
|
lbSplatExpr, b.getContext());
|
2020-03-14 12:15:07 +08:00
|
|
|
AffineValueMap lbSplatValueMap(lbMapSplat, forOp.getLowerBoundOperands());
|
2019-03-13 00:40:04 +08:00
|
|
|
|
2019-09-15 03:10:18 +08:00
|
|
|
AffineValueMap tripCountValueMap;
|
|
|
|
AffineValueMap::difference(ubValueMap, lbSplatValueMap, &tripCountValueMap);
|
|
|
|
for (unsigned i = 0, e = tripCountValueMap.getNumResults(); i < e; ++i)
|
|
|
|
tripCountValueMap.setResult(i,
|
|
|
|
tripCountValueMap.getResult(i).ceilDiv(step));
|
|
|
|
|
|
|
|
*tripCountMap = tripCountValueMap.getAffineMap();
|
|
|
|
tripCountOperands->assign(tripCountValueMap.getOperands().begin(),
|
|
|
|
tripCountValueMap.getOperands().end());
|
2018-09-13 01:21:23 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Returns the trip count of the loop if it's a constant, None otherwise. This
|
|
|
|
/// method uses affine expression analysis (in turn using getTripCount) and is
|
|
|
|
/// able to determine constant trip count in non-trivial cases.
|
2019-03-12 23:00:52 +08:00
|
|
|
// FIXME(mlir-team): this is really relying on buildTripCountMapAndOperands;
|
|
|
|
// being an analysis utility, it shouldn't. Replace with a version that just
|
|
|
|
// works with analysis structures (FlatAffineConstraints) and thus doesn't
|
|
|
|
// update the IR.
|
2019-12-19 01:28:48 +08:00
|
|
|
Optional<uint64_t> mlir::getConstantTripCount(AffineForOp forOp) {
|
2019-12-24 06:45:01 +08:00
|
|
|
SmallVector<Value, 4> operands;
|
2019-03-12 23:00:52 +08:00
|
|
|
AffineMap map;
|
|
|
|
buildTripCountMapAndOperands(forOp, &map, &operands);
|
2018-09-13 01:21:23 +08:00
|
|
|
|
2019-03-12 23:00:52 +08:00
|
|
|
if (!map)
|
2018-10-08 23:09:50 +08:00
|
|
|
return None;
|
|
|
|
|
2019-03-12 23:00:52 +08:00
|
|
|
// Take the min if all trip counts are constant.
|
|
|
|
Optional<uint64_t> tripCount;
|
|
|
|
for (auto resultExpr : map.getResults()) {
|
|
|
|
if (auto constExpr = resultExpr.dyn_cast<AffineConstantExpr>()) {
|
|
|
|
if (tripCount.hasValue())
|
|
|
|
tripCount = std::min(tripCount.getValue(),
|
|
|
|
static_cast<uint64_t>(constExpr.getValue()));
|
|
|
|
else
|
|
|
|
tripCount = constExpr.getValue();
|
|
|
|
} else
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
return tripCount;
|
2018-09-13 01:21:23 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/// Returns the greatest known integral divisor of the trip count. Affine
|
|
|
|
/// expression analysis is used (indirectly through getTripCount), and
|
|
|
|
/// this method is thus able to determine non-trivial divisors.
|
2019-03-25 10:53:05 +08:00
|
|
|
uint64_t mlir::getLargestDivisorOfTripCount(AffineForOp forOp) {
|
2019-12-24 06:45:01 +08:00
|
|
|
SmallVector<Value, 4> operands;
|
2019-03-12 23:00:52 +08:00
|
|
|
AffineMap map;
|
|
|
|
buildTripCountMapAndOperands(forOp, &map, &operands);
|
2018-09-13 01:21:23 +08:00
|
|
|
|
2019-03-12 23:00:52 +08:00
|
|
|
if (!map)
|
2018-09-13 01:21:23 +08:00
|
|
|
return 1;
|
|
|
|
|
2019-03-12 23:00:52 +08:00
|
|
|
// The largest divisor of the trip count is the GCD of the individual largest
|
|
|
|
// divisors.
|
|
|
|
assert(map.getNumResults() >= 1 && "expected one or more results");
|
|
|
|
Optional<uint64_t> gcd;
|
|
|
|
for (auto resultExpr : map.getResults()) {
|
|
|
|
uint64_t thisGcd;
|
|
|
|
if (auto constExpr = resultExpr.dyn_cast<AffineConstantExpr>()) {
|
|
|
|
uint64_t tripCount = constExpr.getValue();
|
|
|
|
// 0 iteration loops (greatest divisor is 2^64 - 1).
|
|
|
|
if (tripCount == 0)
|
|
|
|
thisGcd = std::numeric_limits<uint64_t>::max();
|
|
|
|
else
|
|
|
|
// The greatest divisor is the trip count.
|
|
|
|
thisGcd = tripCount;
|
|
|
|
} else {
|
|
|
|
// Trip count is not a known constant; return its largest known divisor.
|
|
|
|
thisGcd = resultExpr.getLargestKnownDivisor();
|
|
|
|
}
|
|
|
|
if (gcd.hasValue())
|
|
|
|
gcd = llvm::GreatestCommonDivisor64(gcd.getValue(), thisGcd);
|
|
|
|
else
|
|
|
|
gcd = thisGcd;
|
2018-09-13 01:21:23 +08:00
|
|
|
}
|
2019-03-12 23:00:52 +08:00
|
|
|
assert(gcd.hasValue() && "value expected per above logic");
|
|
|
|
return gcd.getValue();
|
2018-09-13 01:21:23 +08:00
|
|
|
}
|
2018-10-18 09:01:44 +08:00
|
|
|
|
2019-12-05 01:29:51 +08:00
|
|
|
/// Given an induction variable `iv` of type AffineForOp and an access `index`
|
|
|
|
/// of type index, returns `true` if `index` is independent of `iv` and
|
|
|
|
/// false otherwise. The determination supports composition with at most one
|
|
|
|
/// AffineApplyOp. The 'at most one AffineApplyOp' comes from the fact that
|
|
|
|
/// the composition of AffineApplyOp needs to be canonicalized by construction
|
|
|
|
/// to avoid writing code that composes arbitrary numbers of AffineApplyOps
|
|
|
|
/// everywhere. To achieve this, at the very least, the compose-affine-apply
|
|
|
|
/// pass must have been run.
|
|
|
|
///
|
|
|
|
/// Prerequisites:
|
|
|
|
/// 1. `iv` and `index` of the proper type;
|
|
|
|
/// 2. at most one reachable AffineApplyOp from index;
|
|
|
|
///
|
|
|
|
/// Returns false in cases with more than one AffineApplyOp, this is
|
|
|
|
/// conservative.
|
2019-12-24 06:45:01 +08:00
|
|
|
static bool isAccessIndexInvariant(Value iv, Value index) {
|
2019-03-30 00:34:06 +08:00
|
|
|
assert(isForInductionVar(iv) && "iv must be a AffineForOp");
|
2020-01-12 00:54:04 +08:00
|
|
|
assert(index.getType().isa<IndexType>() && "index must be of IndexType");
|
2019-03-27 23:55:17 +08:00
|
|
|
SmallVector<Operation *, 4> affineApplyOps;
|
2019-03-30 00:34:06 +08:00
|
|
|
getReachableAffineApplyOps({index}, affineApplyOps);
|
2018-10-18 09:01:44 +08:00
|
|
|
|
|
|
|
if (affineApplyOps.empty()) {
|
2018-12-28 06:35:10 +08:00
|
|
|
// Pointer equality test because of Value pointer semantics.
|
2019-03-30 00:34:06 +08:00
|
|
|
return index != iv;
|
2018-10-18 09:01:44 +08:00
|
|
|
}
|
|
|
|
|
2018-12-07 03:38:09 +08:00
|
|
|
if (affineApplyOps.size() > 1) {
|
2019-05-02 03:13:44 +08:00
|
|
|
affineApplyOps[0]->emitRemark(
|
2018-12-07 03:38:09 +08:00
|
|
|
"CompositionAffineMapsPass must have been run: there should be at most "
|
2019-03-30 00:34:06 +08:00
|
|
|
"one AffineApplyOp, returning false conservatively.");
|
2018-12-07 03:38:09 +08:00
|
|
|
return false;
|
|
|
|
}
|
[MLIR] Add support for permutation_map
This CL hooks up and uses permutation_map in vector_transfer ops.
In particular, when going into the nuts and bolts of the implementation, it
became clear that cases arose that required supporting broadcast semantics.
Broadcast semantics are thus added to the general permutation_map.
The verify methods and tests are updated accordingly.
Examples of interest include.
Example 1:
The following MLIR snippet:
```mlir
for %i3 = 0 to %M {
for %i4 = 0 to %N {
for %i5 = 0 to %P {
%a5 = load %A[%i4, %i5, %i3] : memref<?x?x?xf32>
}}}
```
may vectorize with {permutation_map: (d0, d1, d2) -> (d2, d1)} into:
```mlir
for %i3 = 0 to %0 step 32 {
for %i4 = 0 to %1 {
for %i5 = 0 to %2 step 256 {
%4 = vector_transfer_read %arg0, %i4, %i5, %i3
{permutation_map: (d0, d1, d2) -> (d2, d1)} :
(memref<?x?x?xf32>, index, index) -> vector<32x256xf32>
}}}
````
Meaning that vector_transfer_read will be responsible for reading the 2-D slice:
`%arg0[%i4, %i5:%15+256, %i3:%i3+32]` into vector<32x256xf32>. This will
require a transposition when vector_transfer_read is further lowered.
Example 2:
The following MLIR snippet:
```mlir
%cst0 = constant 0 : index
for %i0 = 0 to %M {
%a0 = load %A[%cst0, %cst0] : memref<?x?xf32>
}
```
may vectorize with {permutation_map: (d0) -> (0)} into:
```mlir
for %i0 = 0 to %0 step 128 {
%3 = vector_transfer_read %arg0, %c0_0, %c0_0
{permutation_map: (d0, d1) -> (0)} :
(memref<?x?xf32>, index, index) -> vector<128xf32>
}
````
Meaning that vector_transfer_read will be responsible of reading the 0-D slice
`%arg0[%c0, %c0]` into vector<128xf32>. This will require a 1-D vector
broadcast when vector_transfer_read is further lowered.
Additionally, some minor cleanups and refactorings are performed.
One notable thing missing here is the composition with a projection map during
materialization. This is because I could not find an AffineMap composition
that operates on AffineMap directly: everything related to composition seems
to require going through SSAValue and only operates on AffinMap at a distance
via AffineValueMap. I have raised this concern a bunch of times already, the
followup CL will actually do something about it.
In the meantime, the projection is hacked at a minimum to pass verification
and materialiation tests are temporarily incorrect.
PiperOrigin-RevId: 224376828
2018-12-07 03:37:25 +08:00
|
|
|
|
2019-05-12 08:57:32 +08:00
|
|
|
auto composeOp = cast<AffineApplyOp>(affineApplyOps[0]);
|
2018-10-30 22:54:23 +08:00
|
|
|
// We need yet another level of indirection because the `dim` index of the
|
|
|
|
// access may not correspond to the `dim` index of composeOp.
|
[MLIR][Affine] NFC: Move AffineValueMap and MutableAffineMap
Summary:
The `AffineValueMap` is moved into `Dialect/AffineOps` to prevent a cyclic
dependency between `Analysis` and `Dialect/AffineOps`.
Reviewers: bondhugula, herhut, nicolasvasilache, rriddle, mehdi_amini
Reviewed By: rriddle, mehdi_amini
Subscribers: mgorny, mehdi_amini, rriddle, jpienaar, burmako, shauheen, antiagainst, arpith-jacob, mgester, lucyrfox, aartbik, liufengdb, Joonsoo, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D74277
2020-02-10 17:17:28 +08:00
|
|
|
return !composeOp.getAffineValueMap().isFunctionOf(0, iv);
|
2018-10-18 09:01:44 +08:00
|
|
|
}
|
|
|
|
|
2019-12-24 06:45:01 +08:00
|
|
|
DenseSet<Value> mlir::getInvariantAccesses(Value iv, ArrayRef<Value> indices) {
|
|
|
|
DenseSet<Value> res;
|
[MLIR] Add support for permutation_map
This CL hooks up and uses permutation_map in vector_transfer ops.
In particular, when going into the nuts and bolts of the implementation, it
became clear that cases arose that required supporting broadcast semantics.
Broadcast semantics are thus added to the general permutation_map.
The verify methods and tests are updated accordingly.
Examples of interest include.
Example 1:
The following MLIR snippet:
```mlir
for %i3 = 0 to %M {
for %i4 = 0 to %N {
for %i5 = 0 to %P {
%a5 = load %A[%i4, %i5, %i3] : memref<?x?x?xf32>
}}}
```
may vectorize with {permutation_map: (d0, d1, d2) -> (d2, d1)} into:
```mlir
for %i3 = 0 to %0 step 32 {
for %i4 = 0 to %1 {
for %i5 = 0 to %2 step 256 {
%4 = vector_transfer_read %arg0, %i4, %i5, %i3
{permutation_map: (d0, d1, d2) -> (d2, d1)} :
(memref<?x?x?xf32>, index, index) -> vector<32x256xf32>
}}}
````
Meaning that vector_transfer_read will be responsible for reading the 2-D slice:
`%arg0[%i4, %i5:%15+256, %i3:%i3+32]` into vector<32x256xf32>. This will
require a transposition when vector_transfer_read is further lowered.
Example 2:
The following MLIR snippet:
```mlir
%cst0 = constant 0 : index
for %i0 = 0 to %M {
%a0 = load %A[%cst0, %cst0] : memref<?x?xf32>
}
```
may vectorize with {permutation_map: (d0) -> (0)} into:
```mlir
for %i0 = 0 to %0 step 128 {
%3 = vector_transfer_read %arg0, %c0_0, %c0_0
{permutation_map: (d0, d1) -> (0)} :
(memref<?x?xf32>, index, index) -> vector<128xf32>
}
````
Meaning that vector_transfer_read will be responsible of reading the 0-D slice
`%arg0[%c0, %c0]` into vector<128xf32>. This will require a 1-D vector
broadcast when vector_transfer_read is further lowered.
Additionally, some minor cleanups and refactorings are performed.
One notable thing missing here is the composition with a projection map during
materialization. This is because I could not find an AffineMap composition
that operates on AffineMap directly: everything related to composition seems
to require going through SSAValue and only operates on AffinMap at a distance
via AffineValueMap. I have raised this concern a bunch of times already, the
followup CL will actually do something about it.
In the meantime, the projection is hacked at a minimum to pass verification
and materialiation tests are temporarily incorrect.
PiperOrigin-RevId: 224376828
2018-12-07 03:37:25 +08:00
|
|
|
for (unsigned idx = 0, n = indices.size(); idx < n; ++idx) {
|
2019-12-23 13:59:55 +08:00
|
|
|
auto val = indices[idx];
|
2019-12-05 01:29:51 +08:00
|
|
|
if (isAccessIndexInvariant(iv, val)) {
|
[MLIR] Add support for permutation_map
This CL hooks up and uses permutation_map in vector_transfer ops.
In particular, when going into the nuts and bolts of the implementation, it
became clear that cases arose that required supporting broadcast semantics.
Broadcast semantics are thus added to the general permutation_map.
The verify methods and tests are updated accordingly.
Examples of interest include.
Example 1:
The following MLIR snippet:
```mlir
for %i3 = 0 to %M {
for %i4 = 0 to %N {
for %i5 = 0 to %P {
%a5 = load %A[%i4, %i5, %i3] : memref<?x?x?xf32>
}}}
```
may vectorize with {permutation_map: (d0, d1, d2) -> (d2, d1)} into:
```mlir
for %i3 = 0 to %0 step 32 {
for %i4 = 0 to %1 {
for %i5 = 0 to %2 step 256 {
%4 = vector_transfer_read %arg0, %i4, %i5, %i3
{permutation_map: (d0, d1, d2) -> (d2, d1)} :
(memref<?x?x?xf32>, index, index) -> vector<32x256xf32>
}}}
````
Meaning that vector_transfer_read will be responsible for reading the 2-D slice:
`%arg0[%i4, %i5:%15+256, %i3:%i3+32]` into vector<32x256xf32>. This will
require a transposition when vector_transfer_read is further lowered.
Example 2:
The following MLIR snippet:
```mlir
%cst0 = constant 0 : index
for %i0 = 0 to %M {
%a0 = load %A[%cst0, %cst0] : memref<?x?xf32>
}
```
may vectorize with {permutation_map: (d0) -> (0)} into:
```mlir
for %i0 = 0 to %0 step 128 {
%3 = vector_transfer_read %arg0, %c0_0, %c0_0
{permutation_map: (d0, d1) -> (0)} :
(memref<?x?xf32>, index, index) -> vector<128xf32>
}
````
Meaning that vector_transfer_read will be responsible of reading the 0-D slice
`%arg0[%c0, %c0]` into vector<128xf32>. This will require a 1-D vector
broadcast when vector_transfer_read is further lowered.
Additionally, some minor cleanups and refactorings are performed.
One notable thing missing here is the composition with a projection map during
materialization. This is because I could not find an AffineMap composition
that operates on AffineMap directly: everything related to composition seems
to require going through SSAValue and only operates on AffinMap at a distance
via AffineValueMap. I have raised this concern a bunch of times already, the
followup CL will actually do something about it.
In the meantime, the projection is hacked at a minimum to pass verification
and materialiation tests are temporarily incorrect.
PiperOrigin-RevId: 224376828
2018-12-07 03:37:25 +08:00
|
|
|
res.insert(val);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Given:
|
2019-02-02 08:42:18 +08:00
|
|
|
/// 1. an induction variable `iv` of type AffineForOp;
|
[MLIR] Add support for permutation_map
This CL hooks up and uses permutation_map in vector_transfer ops.
In particular, when going into the nuts and bolts of the implementation, it
became clear that cases arose that required supporting broadcast semantics.
Broadcast semantics are thus added to the general permutation_map.
The verify methods and tests are updated accordingly.
Examples of interest include.
Example 1:
The following MLIR snippet:
```mlir
for %i3 = 0 to %M {
for %i4 = 0 to %N {
for %i5 = 0 to %P {
%a5 = load %A[%i4, %i5, %i3] : memref<?x?x?xf32>
}}}
```
may vectorize with {permutation_map: (d0, d1, d2) -> (d2, d1)} into:
```mlir
for %i3 = 0 to %0 step 32 {
for %i4 = 0 to %1 {
for %i5 = 0 to %2 step 256 {
%4 = vector_transfer_read %arg0, %i4, %i5, %i3
{permutation_map: (d0, d1, d2) -> (d2, d1)} :
(memref<?x?x?xf32>, index, index) -> vector<32x256xf32>
}}}
````
Meaning that vector_transfer_read will be responsible for reading the 2-D slice:
`%arg0[%i4, %i5:%15+256, %i3:%i3+32]` into vector<32x256xf32>. This will
require a transposition when vector_transfer_read is further lowered.
Example 2:
The following MLIR snippet:
```mlir
%cst0 = constant 0 : index
for %i0 = 0 to %M {
%a0 = load %A[%cst0, %cst0] : memref<?x?xf32>
}
```
may vectorize with {permutation_map: (d0) -> (0)} into:
```mlir
for %i0 = 0 to %0 step 128 {
%3 = vector_transfer_read %arg0, %c0_0, %c0_0
{permutation_map: (d0, d1) -> (0)} :
(memref<?x?xf32>, index, index) -> vector<128xf32>
}
````
Meaning that vector_transfer_read will be responsible of reading the 0-D slice
`%arg0[%c0, %c0]` into vector<128xf32>. This will require a 1-D vector
broadcast when vector_transfer_read is further lowered.
Additionally, some minor cleanups and refactorings are performed.
One notable thing missing here is the composition with a projection map during
materialization. This is because I could not find an AffineMap composition
that operates on AffineMap directly: everything related to composition seems
to require going through SSAValue and only operates on AffinMap at a distance
via AffineValueMap. I have raised this concern a bunch of times already, the
followup CL will actually do something about it.
In the meantime, the projection is hacked at a minimum to pass verification
and materialiation tests are temporarily incorrect.
PiperOrigin-RevId: 224376828
2018-12-07 03:37:25 +08:00
|
|
|
/// 2. a `memoryOp` of type const LoadOp& or const StoreOp&;
|
2019-03-30 00:34:06 +08:00
|
|
|
/// determines whether `memoryOp` has a contiguous access along `iv`. Contiguous
|
|
|
|
/// is defined as either invariant or varying only along a unique MemRef dim.
|
|
|
|
/// Upon success, the unique MemRef dim is written in `memRefDim` (or -1 to
|
|
|
|
/// convey the memRef access is invariant along `iv`).
|
[MLIR] Add support for permutation_map
This CL hooks up and uses permutation_map in vector_transfer ops.
In particular, when going into the nuts and bolts of the implementation, it
became clear that cases arose that required supporting broadcast semantics.
Broadcast semantics are thus added to the general permutation_map.
The verify methods and tests are updated accordingly.
Examples of interest include.
Example 1:
The following MLIR snippet:
```mlir
for %i3 = 0 to %M {
for %i4 = 0 to %N {
for %i5 = 0 to %P {
%a5 = load %A[%i4, %i5, %i3] : memref<?x?x?xf32>
}}}
```
may vectorize with {permutation_map: (d0, d1, d2) -> (d2, d1)} into:
```mlir
for %i3 = 0 to %0 step 32 {
for %i4 = 0 to %1 {
for %i5 = 0 to %2 step 256 {
%4 = vector_transfer_read %arg0, %i4, %i5, %i3
{permutation_map: (d0, d1, d2) -> (d2, d1)} :
(memref<?x?x?xf32>, index, index) -> vector<32x256xf32>
}}}
````
Meaning that vector_transfer_read will be responsible for reading the 2-D slice:
`%arg0[%i4, %i5:%15+256, %i3:%i3+32]` into vector<32x256xf32>. This will
require a transposition when vector_transfer_read is further lowered.
Example 2:
The following MLIR snippet:
```mlir
%cst0 = constant 0 : index
for %i0 = 0 to %M {
%a0 = load %A[%cst0, %cst0] : memref<?x?xf32>
}
```
may vectorize with {permutation_map: (d0) -> (0)} into:
```mlir
for %i0 = 0 to %0 step 128 {
%3 = vector_transfer_read %arg0, %c0_0, %c0_0
{permutation_map: (d0, d1) -> (0)} :
(memref<?x?xf32>, index, index) -> vector<128xf32>
}
````
Meaning that vector_transfer_read will be responsible of reading the 0-D slice
`%arg0[%c0, %c0]` into vector<128xf32>. This will require a 1-D vector
broadcast when vector_transfer_read is further lowered.
Additionally, some minor cleanups and refactorings are performed.
One notable thing missing here is the composition with a projection map during
materialization. This is because I could not find an AffineMap composition
that operates on AffineMap directly: everything related to composition seems
to require going through SSAValue and only operates on AffinMap at a distance
via AffineValueMap. I have raised this concern a bunch of times already, the
followup CL will actually do something about it.
In the meantime, the projection is hacked at a minimum to pass verification
and materialiation tests are temporarily incorrect.
PiperOrigin-RevId: 224376828
2018-12-07 03:37:25 +08:00
|
|
|
///
|
|
|
|
/// Prerequisites:
|
2019-03-30 00:34:06 +08:00
|
|
|
/// 1. `memRefDim` ~= nullptr;
|
|
|
|
/// 2. `iv` of the proper type;
|
|
|
|
/// 3. the MemRef accessed by `memoryOp` has no layout map or at most an
|
[MLIR] Add support for permutation_map
This CL hooks up and uses permutation_map in vector_transfer ops.
In particular, when going into the nuts and bolts of the implementation, it
became clear that cases arose that required supporting broadcast semantics.
Broadcast semantics are thus added to the general permutation_map.
The verify methods and tests are updated accordingly.
Examples of interest include.
Example 1:
The following MLIR snippet:
```mlir
for %i3 = 0 to %M {
for %i4 = 0 to %N {
for %i5 = 0 to %P {
%a5 = load %A[%i4, %i5, %i3] : memref<?x?x?xf32>
}}}
```
may vectorize with {permutation_map: (d0, d1, d2) -> (d2, d1)} into:
```mlir
for %i3 = 0 to %0 step 32 {
for %i4 = 0 to %1 {
for %i5 = 0 to %2 step 256 {
%4 = vector_transfer_read %arg0, %i4, %i5, %i3
{permutation_map: (d0, d1, d2) -> (d2, d1)} :
(memref<?x?x?xf32>, index, index) -> vector<32x256xf32>
}}}
````
Meaning that vector_transfer_read will be responsible for reading the 2-D slice:
`%arg0[%i4, %i5:%15+256, %i3:%i3+32]` into vector<32x256xf32>. This will
require a transposition when vector_transfer_read is further lowered.
Example 2:
The following MLIR snippet:
```mlir
%cst0 = constant 0 : index
for %i0 = 0 to %M {
%a0 = load %A[%cst0, %cst0] : memref<?x?xf32>
}
```
may vectorize with {permutation_map: (d0) -> (0)} into:
```mlir
for %i0 = 0 to %0 step 128 {
%3 = vector_transfer_read %arg0, %c0_0, %c0_0
{permutation_map: (d0, d1) -> (0)} :
(memref<?x?xf32>, index, index) -> vector<128xf32>
}
````
Meaning that vector_transfer_read will be responsible of reading the 0-D slice
`%arg0[%c0, %c0]` into vector<128xf32>. This will require a 1-D vector
broadcast when vector_transfer_read is further lowered.
Additionally, some minor cleanups and refactorings are performed.
One notable thing missing here is the composition with a projection map during
materialization. This is because I could not find an AffineMap composition
that operates on AffineMap directly: everything related to composition seems
to require going through SSAValue and only operates on AffinMap at a distance
via AffineValueMap. I have raised this concern a bunch of times already, the
followup CL will actually do something about it.
In the meantime, the projection is hacked at a minimum to pass verification
and materialiation tests are temporarily incorrect.
PiperOrigin-RevId: 224376828
2018-12-07 03:37:25 +08:00
|
|
|
/// identity layout map.
|
|
|
|
///
|
2018-12-07 03:38:09 +08:00
|
|
|
/// Currently only supports no layoutMap or identity layoutMap in the MemRef.
|
2019-03-30 00:34:06 +08:00
|
|
|
/// Returns false if the MemRef has a non-identity layoutMap or more than 1
|
|
|
|
/// layoutMap. This is conservative.
|
2018-12-07 03:38:09 +08:00
|
|
|
///
|
2020-07-07 16:35:23 +08:00
|
|
|
// TODO: check strides.
|
[MLIR] Add support for permutation_map
This CL hooks up and uses permutation_map in vector_transfer ops.
In particular, when going into the nuts and bolts of the implementation, it
became clear that cases arose that required supporting broadcast semantics.
Broadcast semantics are thus added to the general permutation_map.
The verify methods and tests are updated accordingly.
Examples of interest include.
Example 1:
The following MLIR snippet:
```mlir
for %i3 = 0 to %M {
for %i4 = 0 to %N {
for %i5 = 0 to %P {
%a5 = load %A[%i4, %i5, %i3] : memref<?x?x?xf32>
}}}
```
may vectorize with {permutation_map: (d0, d1, d2) -> (d2, d1)} into:
```mlir
for %i3 = 0 to %0 step 32 {
for %i4 = 0 to %1 {
for %i5 = 0 to %2 step 256 {
%4 = vector_transfer_read %arg0, %i4, %i5, %i3
{permutation_map: (d0, d1, d2) -> (d2, d1)} :
(memref<?x?x?xf32>, index, index) -> vector<32x256xf32>
}}}
````
Meaning that vector_transfer_read will be responsible for reading the 2-D slice:
`%arg0[%i4, %i5:%15+256, %i3:%i3+32]` into vector<32x256xf32>. This will
require a transposition when vector_transfer_read is further lowered.
Example 2:
The following MLIR snippet:
```mlir
%cst0 = constant 0 : index
for %i0 = 0 to %M {
%a0 = load %A[%cst0, %cst0] : memref<?x?xf32>
}
```
may vectorize with {permutation_map: (d0) -> (0)} into:
```mlir
for %i0 = 0 to %0 step 128 {
%3 = vector_transfer_read %arg0, %c0_0, %c0_0
{permutation_map: (d0, d1) -> (0)} :
(memref<?x?xf32>, index, index) -> vector<128xf32>
}
````
Meaning that vector_transfer_read will be responsible of reading the 0-D slice
`%arg0[%c0, %c0]` into vector<128xf32>. This will require a 1-D vector
broadcast when vector_transfer_read is further lowered.
Additionally, some minor cleanups and refactorings are performed.
One notable thing missing here is the composition with a projection map during
materialization. This is because I could not find an AffineMap composition
that operates on AffineMap directly: everything related to composition seems
to require going through SSAValue and only operates on AffinMap at a distance
via AffineValueMap. I have raised this concern a bunch of times already, the
followup CL will actually do something about it.
In the meantime, the projection is hacked at a minimum to pass verification
and materialiation tests are temporarily incorrect.
PiperOrigin-RevId: 224376828
2018-12-07 03:37:25 +08:00
|
|
|
template <typename LoadOrStoreOp>
|
2019-12-24 06:45:01 +08:00
|
|
|
static bool isContiguousAccess(Value iv, LoadOrStoreOp memoryOp,
|
2019-03-30 00:34:06 +08:00
|
|
|
int *memRefDim) {
|
2020-03-25 10:23:05 +08:00
|
|
|
static_assert(
|
|
|
|
llvm::is_one_of<LoadOrStoreOp, AffineLoadOp, AffineStoreOp>::value,
|
|
|
|
"Must be called on either LoadOp or StoreOp");
|
2019-03-30 00:34:06 +08:00
|
|
|
assert(memRefDim && "memRefDim == nullptr");
|
2019-03-26 04:02:06 +08:00
|
|
|
auto memRefType = memoryOp.getMemRefType();
|
2018-12-28 00:16:39 +08:00
|
|
|
|
[MLIR] Add support for permutation_map
This CL hooks up and uses permutation_map in vector_transfer ops.
In particular, when going into the nuts and bolts of the implementation, it
became clear that cases arose that required supporting broadcast semantics.
Broadcast semantics are thus added to the general permutation_map.
The verify methods and tests are updated accordingly.
Examples of interest include.
Example 1:
The following MLIR snippet:
```mlir
for %i3 = 0 to %M {
for %i4 = 0 to %N {
for %i5 = 0 to %P {
%a5 = load %A[%i4, %i5, %i3] : memref<?x?x?xf32>
}}}
```
may vectorize with {permutation_map: (d0, d1, d2) -> (d2, d1)} into:
```mlir
for %i3 = 0 to %0 step 32 {
for %i4 = 0 to %1 {
for %i5 = 0 to %2 step 256 {
%4 = vector_transfer_read %arg0, %i4, %i5, %i3
{permutation_map: (d0, d1, d2) -> (d2, d1)} :
(memref<?x?x?xf32>, index, index) -> vector<32x256xf32>
}}}
````
Meaning that vector_transfer_read will be responsible for reading the 2-D slice:
`%arg0[%i4, %i5:%15+256, %i3:%i3+32]` into vector<32x256xf32>. This will
require a transposition when vector_transfer_read is further lowered.
Example 2:
The following MLIR snippet:
```mlir
%cst0 = constant 0 : index
for %i0 = 0 to %M {
%a0 = load %A[%cst0, %cst0] : memref<?x?xf32>
}
```
may vectorize with {permutation_map: (d0) -> (0)} into:
```mlir
for %i0 = 0 to %0 step 128 {
%3 = vector_transfer_read %arg0, %c0_0, %c0_0
{permutation_map: (d0, d1) -> (0)} :
(memref<?x?xf32>, index, index) -> vector<128xf32>
}
````
Meaning that vector_transfer_read will be responsible of reading the 0-D slice
`%arg0[%c0, %c0]` into vector<128xf32>. This will require a 1-D vector
broadcast when vector_transfer_read is further lowered.
Additionally, some minor cleanups and refactorings are performed.
One notable thing missing here is the composition with a projection map during
materialization. This is because I could not find an AffineMap composition
that operates on AffineMap directly: everything related to composition seems
to require going through SSAValue and only operates on AffinMap at a distance
via AffineValueMap. I have raised this concern a bunch of times already, the
followup CL will actually do something about it.
In the meantime, the projection is hacked at a minimum to pass verification
and materialiation tests are temporarily incorrect.
PiperOrigin-RevId: 224376828
2018-12-07 03:37:25 +08:00
|
|
|
auto layoutMap = memRefType.getAffineMaps();
|
2020-07-07 16:35:23 +08:00
|
|
|
// TODO: remove dependence on Builder once we support non-identity layout map.
|
2019-03-25 15:29:00 +08:00
|
|
|
Builder b(memoryOp.getContext());
|
2018-12-07 03:38:09 +08:00
|
|
|
if (layoutMap.size() >= 2 ||
|
|
|
|
(layoutMap.size() == 1 &&
|
|
|
|
!(layoutMap[0] ==
|
|
|
|
b.getMultiDimIdentityMap(layoutMap[0].getNumDims())))) {
|
2019-03-26 04:02:06 +08:00
|
|
|
return memoryOp.emitError("NYI: non-trivial layoutMap"), false;
|
2018-12-07 03:38:09 +08:00
|
|
|
}
|
[MLIR] Add support for permutation_map
This CL hooks up and uses permutation_map in vector_transfer ops.
In particular, when going into the nuts and bolts of the implementation, it
became clear that cases arose that required supporting broadcast semantics.
Broadcast semantics are thus added to the general permutation_map.
The verify methods and tests are updated accordingly.
Examples of interest include.
Example 1:
The following MLIR snippet:
```mlir
for %i3 = 0 to %M {
for %i4 = 0 to %N {
for %i5 = 0 to %P {
%a5 = load %A[%i4, %i5, %i3] : memref<?x?x?xf32>
}}}
```
may vectorize with {permutation_map: (d0, d1, d2) -> (d2, d1)} into:
```mlir
for %i3 = 0 to %0 step 32 {
for %i4 = 0 to %1 {
for %i5 = 0 to %2 step 256 {
%4 = vector_transfer_read %arg0, %i4, %i5, %i3
{permutation_map: (d0, d1, d2) -> (d2, d1)} :
(memref<?x?x?xf32>, index, index) -> vector<32x256xf32>
}}}
````
Meaning that vector_transfer_read will be responsible for reading the 2-D slice:
`%arg0[%i4, %i5:%15+256, %i3:%i3+32]` into vector<32x256xf32>. This will
require a transposition when vector_transfer_read is further lowered.
Example 2:
The following MLIR snippet:
```mlir
%cst0 = constant 0 : index
for %i0 = 0 to %M {
%a0 = load %A[%cst0, %cst0] : memref<?x?xf32>
}
```
may vectorize with {permutation_map: (d0) -> (0)} into:
```mlir
for %i0 = 0 to %0 step 128 {
%3 = vector_transfer_read %arg0, %c0_0, %c0_0
{permutation_map: (d0, d1) -> (0)} :
(memref<?x?xf32>, index, index) -> vector<128xf32>
}
````
Meaning that vector_transfer_read will be responsible of reading the 0-D slice
`%arg0[%c0, %c0]` into vector<128xf32>. This will require a 1-D vector
broadcast when vector_transfer_read is further lowered.
Additionally, some minor cleanups and refactorings are performed.
One notable thing missing here is the composition with a projection map during
materialization. This is because I could not find an AffineMap composition
that operates on AffineMap directly: everything related to composition seems
to require going through SSAValue and only operates on AffinMap at a distance
via AffineValueMap. I have raised this concern a bunch of times already, the
followup CL will actually do something about it.
In the meantime, the projection is hacked at a minimum to pass verification
and materialiation tests are temporarily incorrect.
PiperOrigin-RevId: 224376828
2018-12-07 03:37:25 +08:00
|
|
|
|
2019-03-30 00:34:06 +08:00
|
|
|
int uniqueVaryingIndexAlongIv = -1;
|
2019-07-04 01:35:03 +08:00
|
|
|
auto accessMap = memoryOp.getAffineMap();
|
2019-12-24 06:45:01 +08:00
|
|
|
SmallVector<Value, 4> mapOperands(memoryOp.getMapOperands());
|
2019-07-04 01:35:03 +08:00
|
|
|
unsigned numDims = accessMap.getNumDims();
|
|
|
|
for (unsigned i = 0, e = memRefType.getRank(); i < e; ++i) {
|
|
|
|
// Gather map operands used result expr 'i' in 'exprOperands'.
|
2019-12-24 06:45:01 +08:00
|
|
|
SmallVector<Value, 4> exprOperands;
|
2019-07-04 01:35:03 +08:00
|
|
|
auto resultExpr = accessMap.getResult(i);
|
|
|
|
resultExpr.walk([&](AffineExpr expr) {
|
|
|
|
if (auto dimExpr = expr.dyn_cast<AffineDimExpr>())
|
|
|
|
exprOperands.push_back(mapOperands[dimExpr.getPosition()]);
|
|
|
|
else if (auto symExpr = expr.dyn_cast<AffineSymbolExpr>())
|
|
|
|
exprOperands.push_back(mapOperands[numDims + symExpr.getPosition()]);
|
|
|
|
});
|
|
|
|
// Check access invariance of each operand in 'exprOperands'.
|
2019-12-23 13:59:55 +08:00
|
|
|
for (auto exprOperand : exprOperands) {
|
2019-12-05 01:29:51 +08:00
|
|
|
if (!isAccessIndexInvariant(iv, exprOperand)) {
|
2019-07-04 01:35:03 +08:00
|
|
|
if (uniqueVaryingIndexAlongIv != -1) {
|
|
|
|
// 2+ varying indices -> do not vectorize along iv.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
uniqueVaryingIndexAlongIv = i;
|
2019-03-30 00:34:06 +08:00
|
|
|
}
|
2018-10-18 09:01:44 +08:00
|
|
|
}
|
|
|
|
}
|
2019-03-30 00:34:06 +08:00
|
|
|
|
|
|
|
if (uniqueVaryingIndexAlongIv == -1)
|
|
|
|
*memRefDim = -1;
|
|
|
|
else
|
2019-07-04 01:35:03 +08:00
|
|
|
*memRefDim = memRefType.getRank() - (uniqueVaryingIndexAlongIv + 1);
|
2018-10-18 09:01:44 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2020-04-01 05:04:04 +08:00
|
|
|
template <typename LoadOrStoreOp>
|
|
|
|
static bool isVectorElement(LoadOrStoreOp memoryOp) {
|
2019-03-26 04:02:06 +08:00
|
|
|
auto memRefType = memoryOp.getMemRefType();
|
2018-10-31 05:59:22 +08:00
|
|
|
return memRefType.getElementType().template isa<VectorType>();
|
2018-10-30 22:54:23 +08:00
|
|
|
}
|
|
|
|
|
2019-03-28 08:50:34 +08:00
|
|
|
using VectorizableOpFun = std::function<bool(AffineForOp, Operation &)>;
|
[MLIR] Extend vectorization to 2+-D patterns
This CL adds support for vectorization using more interesting 2-D and 3-D
patterns. Note in particular the fact that we match some pretty complex
imperfectly nested 2-D patterns with a quite minimal change to the
implementation: we just add a bit of recursion to traverse the matched
patterns and actually vectorize the loops.
For instance, vectorizing the following loop by 128:
```
for %i3 = 0 to %0 {
%7 = affine_apply (d0) -> (d0)(%i3)
%8 = load %arg0[%c0_0, %7] : memref<?x?xf32>
}
```
Currently generates:
```
#map0 = ()[s0] -> (s0 + 127)
#map1 = (d0) -> (d0)
for %i3 = 0 to #map0()[%0] step 128 {
%9 = affine_apply #map1(%i3)
%10 = alloc() : memref<1xvector<128xf32>>
%11 = "n_d_unaligned_load"(%arg0, %c0_0, %9, %10, %c0) :
(memref<?x?xf32>, index, index, memref<1xvector<128xf32>>, index) ->
(memref<?x?xf32>, index, index, memref<1xvector<128xf32>>, index)
%12 = load %10[%c0] : memref<1xvector<128xf32>>
}
```
The above is subject to evolution.
PiperOrigin-RevId: 219629745
2018-11-01 22:14:14 +08:00
|
|
|
|
2019-03-28 08:50:34 +08:00
|
|
|
static bool
|
|
|
|
isVectorizableLoopBodyWithOpCond(AffineForOp loop,
|
2019-12-04 09:51:34 +08:00
|
|
|
VectorizableOpFun isVectorizableOp,
|
|
|
|
NestedPattern &vectorTransferMatcher) {
|
2019-03-28 08:50:34 +08:00
|
|
|
auto *forOp = loop.getOperation();
|
2018-10-30 22:54:23 +08:00
|
|
|
|
|
|
|
// No vectorization across conditionals for now.
|
|
|
|
auto conditionals = matcher::If();
|
2019-01-31 23:16:29 +08:00
|
|
|
SmallVector<NestedMatch, 8> conditionalsMatched;
|
2019-03-28 08:50:34 +08:00
|
|
|
conditionals.match(forOp, &conditionalsMatched);
|
2018-10-30 22:54:23 +08:00
|
|
|
if (!conditionalsMatched.empty()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-01-29 13:23:53 +08:00
|
|
|
// No vectorization across unknown regions.
|
2019-03-27 23:55:17 +08:00
|
|
|
auto regions = matcher::Op([](Operation &op) -> bool {
|
2020-06-25 02:49:30 +08:00
|
|
|
return op.getNumRegions() != 0 && !isa<AffineIfOp, AffineForOp>(op);
|
2019-01-29 13:23:53 +08:00
|
|
|
});
|
2019-01-31 23:16:29 +08:00
|
|
|
SmallVector<NestedMatch, 8> regionsMatched;
|
2019-03-28 08:50:34 +08:00
|
|
|
regions.match(forOp, ®ionsMatched);
|
2019-01-29 13:23:53 +08:00
|
|
|
if (!regionsMatched.empty()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-01-31 23:16:29 +08:00
|
|
|
SmallVector<NestedMatch, 8> vectorTransfersMatched;
|
2019-12-04 09:51:34 +08:00
|
|
|
vectorTransferMatcher.match(forOp, &vectorTransfersMatched);
|
2018-11-14 20:04:10 +08:00
|
|
|
if (!vectorTransfersMatched.empty()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2018-10-30 22:54:23 +08:00
|
|
|
auto loadAndStores = matcher::Op(matcher::isLoadOrStore);
|
2019-01-31 23:16:29 +08:00
|
|
|
SmallVector<NestedMatch, 8> loadAndStoresMatched;
|
2019-03-28 08:50:34 +08:00
|
|
|
loadAndStores.match(forOp, &loadAndStoresMatched);
|
2018-10-30 22:54:23 +08:00
|
|
|
for (auto ls : loadAndStoresMatched) {
|
2019-03-27 23:55:17 +08:00
|
|
|
auto *op = ls.getMatchedOperation();
|
2019-07-04 01:35:03 +08:00
|
|
|
auto load = dyn_cast<AffineLoadOp>(op);
|
|
|
|
auto store = dyn_cast<AffineStoreOp>(op);
|
2018-10-30 22:54:23 +08:00
|
|
|
// Only scalar types are considered vectorizable, all load/store must be
|
|
|
|
// vectorizable for a loop to qualify as vectorizable.
|
2020-07-07 16:35:23 +08:00
|
|
|
// TODO: ponder whether we want to be more general here.
|
2018-10-30 22:54:23 +08:00
|
|
|
bool vector = load ? isVectorElement(load) : isVectorElement(store);
|
|
|
|
if (vector) {
|
|
|
|
return false;
|
|
|
|
}
|
2019-03-28 08:50:34 +08:00
|
|
|
if (isVectorizableOp && !isVectorizableOp(loop, *op)) {
|
2018-10-18 09:01:44 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
2018-10-19 02:14:26 +08:00
|
|
|
|
2019-12-04 09:51:34 +08:00
|
|
|
bool mlir::isVectorizableLoopBody(AffineForOp loop, int *memRefDim,
|
|
|
|
NestedPattern &vectorTransferMatcher) {
|
2019-03-30 00:34:06 +08:00
|
|
|
VectorizableOpFun fun([memRefDim](AffineForOp loop, Operation &op) {
|
2019-07-04 01:35:03 +08:00
|
|
|
auto load = dyn_cast<AffineLoadOp>(op);
|
|
|
|
auto store = dyn_cast<AffineStoreOp>(op);
|
2019-03-30 00:34:06 +08:00
|
|
|
return load ? isContiguousAccess(loop.getInductionVar(), load, memRefDim)
|
|
|
|
: isContiguousAccess(loop.getInductionVar(), store, memRefDim);
|
2019-03-28 05:12:01 +08:00
|
|
|
});
|
2019-12-04 09:51:34 +08:00
|
|
|
return isVectorizableLoopBodyWithOpCond(loop, fun, vectorTransferMatcher);
|
[MLIR] Extend vectorization to 2+-D patterns
This CL adds support for vectorization using more interesting 2-D and 3-D
patterns. Note in particular the fact that we match some pretty complex
imperfectly nested 2-D patterns with a quite minimal change to the
implementation: we just add a bit of recursion to traverse the matched
patterns and actually vectorize the loops.
For instance, vectorizing the following loop by 128:
```
for %i3 = 0 to %0 {
%7 = affine_apply (d0) -> (d0)(%i3)
%8 = load %arg0[%c0_0, %7] : memref<?x?xf32>
}
```
Currently generates:
```
#map0 = ()[s0] -> (s0 + 127)
#map1 = (d0) -> (d0)
for %i3 = 0 to #map0()[%0] step 128 {
%9 = affine_apply #map1(%i3)
%10 = alloc() : memref<1xvector<128xf32>>
%11 = "n_d_unaligned_load"(%arg0, %c0_0, %9, %10, %c0) :
(memref<?x?xf32>, index, index, memref<1xvector<128xf32>>, index) ->
(memref<?x?xf32>, index, index, memref<1xvector<128xf32>>, index)
%12 = load %10[%c0] : memref<1xvector<128xf32>>
}
```
The above is subject to evolution.
PiperOrigin-RevId: 219629745
2018-11-01 22:14:14 +08:00
|
|
|
}
|
|
|
|
|
2019-12-04 09:51:34 +08:00
|
|
|
bool mlir::isVectorizableLoopBody(AffineForOp loop,
|
|
|
|
NestedPattern &vectorTransferMatcher) {
|
|
|
|
return isVectorizableLoopBodyWithOpCond(loop, nullptr, vectorTransferMatcher);
|
[MLIR] Extend vectorization to 2+-D patterns
This CL adds support for vectorization using more interesting 2-D and 3-D
patterns. Note in particular the fact that we match some pretty complex
imperfectly nested 2-D patterns with a quite minimal change to the
implementation: we just add a bit of recursion to traverse the matched
patterns and actually vectorize the loops.
For instance, vectorizing the following loop by 128:
```
for %i3 = 0 to %0 {
%7 = affine_apply (d0) -> (d0)(%i3)
%8 = load %arg0[%c0_0, %7] : memref<?x?xf32>
}
```
Currently generates:
```
#map0 = ()[s0] -> (s0 + 127)
#map1 = (d0) -> (d0)
for %i3 = 0 to #map0()[%0] step 128 {
%9 = affine_apply #map1(%i3)
%10 = alloc() : memref<1xvector<128xf32>>
%11 = "n_d_unaligned_load"(%arg0, %c0_0, %9, %10, %c0) :
(memref<?x?xf32>, index, index, memref<1xvector<128xf32>>, index) ->
(memref<?x?xf32>, index, index, memref<1xvector<128xf32>>, index)
%12 = load %10[%c0] : memref<1xvector<128xf32>>
}
```
The above is subject to evolution.
PiperOrigin-RevId: 219629745
2018-11-01 22:14:14 +08:00
|
|
|
}
|
|
|
|
|
2019-03-27 23:55:17 +08:00
|
|
|
/// Checks whether SSA dominance would be violated if a for op's body
|
|
|
|
/// operations are shifted by the specified shifts. This method checks if a
|
2018-10-19 02:14:26 +08:00
|
|
|
/// 'def' and all its uses have the same shift factor.
|
2020-07-07 16:35:23 +08:00
|
|
|
// TODO: extend this to check for memory-based dependence violation when we have
|
|
|
|
// the support.
|
2020-04-01 05:04:04 +08:00
|
|
|
bool mlir::isOpwiseShiftValid(AffineForOp forOp, ArrayRef<uint64_t> shifts) {
|
2019-03-26 02:13:31 +08:00
|
|
|
auto *forBody = forOp.getBody();
|
2019-03-27 08:05:09 +08:00
|
|
|
assert(shifts.size() == forBody->getOperations().size());
|
2019-02-07 02:54:57 +08:00
|
|
|
|
2019-02-07 03:36:16 +08:00
|
|
|
// Work backwards over the body of the block so that the shift of a use's
|
2019-03-27 23:55:17 +08:00
|
|
|
// ancestor operation in the block gets recorded before it's looked up.
|
|
|
|
DenseMap<Operation *, uint64_t> forBodyShift;
|
2019-03-27 08:05:09 +08:00
|
|
|
for (auto it : llvm::enumerate(llvm::reverse(forBody->getOperations()))) {
|
2019-03-27 23:55:17 +08:00
|
|
|
auto &op = it.value();
|
2019-02-07 02:54:57 +08:00
|
|
|
|
2019-03-27 23:55:17 +08:00
|
|
|
// Get the index of the current operation, note that we are iterating in
|
2019-02-07 02:54:57 +08:00
|
|
|
// reverse so we need to fix it up.
|
|
|
|
size_t index = shifts.size() - it.index() - 1;
|
|
|
|
|
2019-03-27 23:55:17 +08:00
|
|
|
// Remember the shift of this operation.
|
2019-02-07 02:54:57 +08:00
|
|
|
uint64_t shift = shifts[index];
|
2019-03-27 23:55:17 +08:00
|
|
|
forBodyShift.try_emplace(&op, shift);
|
2019-02-07 02:54:57 +08:00
|
|
|
|
2019-03-27 23:55:17 +08:00
|
|
|
// Validate the results of this operation if it were to be shifted.
|
|
|
|
for (unsigned i = 0, e = op.getNumResults(); i < e; ++i) {
|
2019-12-24 06:45:01 +08:00
|
|
|
Value result = op.getResult(i);
|
2020-01-12 00:54:04 +08:00
|
|
|
for (auto *user : result.getUsers()) {
|
2019-03-27 23:55:17 +08:00
|
|
|
// If an ancestor operation doesn't lie in the block of forOp,
|
2019-02-07 02:54:57 +08:00
|
|
|
// there is no shift to check.
|
2019-11-07 08:08:51 +08:00
|
|
|
if (auto *ancOp = forBody->findAncestorOpInBlock(*user)) {
|
|
|
|
assert(forBodyShift.count(ancOp) > 0 && "ancestor expected in map");
|
|
|
|
if (shift != forBodyShift[ancOp])
|
2019-02-04 02:03:46 +08:00
|
|
|
return false;
|
2019-02-07 03:36:16 +08:00
|
|
|
}
|
2018-10-19 02:14:26 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|