This is an archive of the discontinued LLVM Phabricator instance.

[LAA] Rename and fix semantics of MaxSafeDepDistBytes to MinDepDistBytes
ClosedPublic

Authored by michaelmaitland on Jul 24 2023, 11:33 AM.

Details

Summary
`MaxSafeDepDistBytes` was not correct based on its name an semantics
in instances when there was a non-unit stride loop. For example,

```
for (int k = 0; k < len; k+=3) {
  a[k] = a[k+4];
  a[k+2] = a[k+6];
}
```

Here, the smallest dependence distance is 24 bytes, but only vectorizing 8 bytes
is safe. `MaxSafeVectorWidthInBits` reported the correct number of bits
that could be vectorized as 64 bits.

The semantics of of `MaxSafeDepDistBytes` should be:
  The smallest dependence distance in bytes in the loop. This may not be
  the same as the maximum number of bytes that are safe to operate on
  simultaneously.

The name of this variable should reflect those semantics and
its docstring should be updated accordingly, `MinDepDistBytes`.

A debug message that used `MaxSafeDepDistBytes` to signify to the user
how many bytes could be accessed in parallel is updated to use
`MaxSafeVectorWidthInBits` instead. That way, the same message if
communicated to the user, just in different units.

This patch makes sure that when `MinDepDistBytes` is modified in a way
that should impact `MaxSafeVectorWidthInBits`, that we update the latter
accordingly. This patch also clarifies why `MaxSafeVectorWidthInBits`
does not to be updated when `MinDepDistBytes` is (i.e. in the case of a
forward dependency).

Diff Detail

Event Timeline

Herald added a project: Restricted Project. · View Herald TranscriptJul 24 2023, 11:33 AM
michaelmaitland requested review of this revision.Jul 24 2023, 11:33 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 24 2023, 11:33 AM

Last update had wrong diff.

Clarify how MinDepDistBytes intereacts with MaxSafeVectorWidthInBits

fhahn added inline comments.Aug 8 2023, 2:49 PM
llvm/include/llvm/Analysis/LoopAccessAnalysis.h
204

Are there any uses outside of LAA remaining? If not, maybe make it private to prevent future potential mis-use?

llvm/lib/Analysis/LoopAccessAnalysis.cpp
2011

This is the only non-NFC part of the patch, IIUC? Would it be possible to create a test case showing the new behavior?

fhahn added a comment.Aug 8 2023, 2:50 PM

Thanks for the follow up!

michaelmaitland marked an inline comment as done.

Make getMinDepDistBytes private to DepChecker.

fhahn added a comment.Aug 11 2023, 7:10 AM

Thanks for the update! It looks like there's some clang-format issue (as reported by the pre-commit checks), but overall looks good pending clarification about the test for the change in behavior

llvm/lib/Analysis/LoopAccessAnalysis.cpp
2011

Would it be possible to add a test for the functional change here?

llvm/lib/Analysis/LoopAccessAnalysis.cpp
2011

I assume you mean the fact that we update MaxSafeVectorWidthInBits even if IsTrueDataDependence && EnableForwardingConflictDetection && couldPreventStoreLoadForward(Distance, TypeByteSize).

I am working on constructing a test case for this.

michaelmaitland marked 2 inline comments as done.

Add sanity check

llvm/lib/Analysis/LoopAccessAnalysis.cpp
2011

@fhahn I've updated this diff that no longer update MaxSafeVectorWidthInBits even if IsTrueDataDependence && EnableForwardingConflictDetection && couldPreventStoreLoadForward(Distance, TypeByteSize). The reason for this is that if couldPreventStoreLoadForward returns true, then it must be the case that MinDepDistBytes was not updated, and therefore MaxSafeVectorWidthInBits will remain the same.

I've added an assert statement as a sanity check against any future changes.

fhahn accepted this revision.Aug 16 2023, 3:05 AM

LGTM, thanks!

llvm/lib/Analysis/LoopAccessAnalysis.cpp
2009

As MinDepDistBytesOld is only used in the assert, I think at the moment we would get a warning in release builds, so we probably either need (void) MinDepDistBytesOld; or wrap the declaration in an ifdef.

2011

Ok thanks! I think that is fine for now, as this keeps the logic in this part working as before.

This revision is now accepted and ready to land.Aug 16 2023, 3:05 AM
This revision was landed with ongoing or failed builds.Aug 16 2023, 9:53 AM
This revision was automatically updated to reflect the committed changes.