`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).
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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? |
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. |
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. |
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. |
Are there any uses outside of LAA remaining? If not, maybe make it private to prevent future potential mis-use?