================
@@ -166,53 +166,27 @@ static bool inThisOrder(const Instruction *Src, const
Instruction *Dst) {
}
#endif
-/// Check if the direction vector is negative. A negative direction
-/// vector means Src and Dst are reversed in the actual program.
-///
-/// FIXME: in some cases the meaning of a negative direction vector
-/// may not be straightforward, e.g.,
-/// for (int i = 0; i < 32; ++i) {
-/// Src: A[i] = ...;
-/// Dst: use(A[31 - i]);
-/// }
-/// The dependency is
-/// flow { Src[i] -> Dst[31 - i] : when i >= 16 } and
-/// anti { Dst[i] -> Src[31 - i] : when i < 16 },
-/// -- hence a [<>].
-/// As long as a dependence result contains '>' ('<>', '<=>', "*"), it
-/// means that a reversed/normalized dependence needs to be considered
-/// as well. Nevertheless, current isDirectionNegative() only returns
-/// true with a '>' or '>=' dependency for ease of canonicalizing the
-/// dependency vector, since the reverse of '<>', '<=>' and "*" is itself.
-static bool isDirectionNegative(const Dependence &D) {
+/// Return true if the dependence \p D should be negated. The decision is based
+/// on the first element of the direction vector that contains exactly one of
+/// the '<' or '>' directions. If such an element exists, the preferred
+/// direction is '<' for the legality check. For instance, if the direction
+/// vector is ['*', '>', '<'], it should be negated to ['*', '<', '>'].
----------------
kasuga-fj wrote:
> * `[* <]` => unknown order => add `[* <]` AND negated `[* >]` to matrix
I don't follow this. If it were true, wouldn't it mean that the legality check
is unsound whenever the outermost loop isn't recognized as a loop? For example,
suppose we have a 3-nested loop whose direction vector is `[* < =]`. Following
your statement, we would need to add both `[* < =]` and `[* > =]` to the
matrix. In that case, we can't interchange the inner two loops because
`isLegalToInterChangeLoops` would return false. But if we failed to recognize
the outermost loop, we would get the direction vector `[< =]`, which would let
us interchange the two loops.
I think something odd is going on somewhere, but I'm not sure exactly what...
(or it may also be addressed by #193480?)
https://github.com/llvm/llvm-project/pull/206960
_______________________________________________
llvm-branch-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits