[llvm] r269667 - [LAA] Comment couldPreventStoreLoadForward. NFC

[Adam Nemet via llvm-commits]

Author: anemet
Date: Mon May 16 11:57:47 2016
New Revision: 269667

URL: http://llvm.org/viewvc/llvm-project?rev=269667&view=rev
Log:
[LAA] Comment couldPreventStoreLoadForward. NFC

Also s/Cycles/Iters/ in NumCyclesForStoreLoadThroughMemory to make it
clear that this is not about clock cycles but loop cycles/iterations.

Modified:
    llvm/trunk/include/llvm/Analysis/LoopAccessAnalysis.h
    llvm/trunk/lib/Analysis/LoopAccessAnalysis.cpp

Modified: llvm/trunk/include/llvm/Analysis/LoopAccessAnalysis.h
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/Analysis/LoopAccessAnalysis.h?rev=269667&r1=269666&r2=269667&view=diff
==============================================================================
--- llvm/trunk/include/llvm/Analysis/LoopAccessAnalysis.h (original)
+++ llvm/trunk/include/llvm/Analysis/LoopAccessAnalysis.h Mon May 16 11:57:47 2016
@@ -321,6 +321,9 @@ private:
 
   /// \brief Check whether the data dependence could prevent store-load
   /// forwarding.
+  ///
+  /// \return false if we shouldn't vectorize at all or avoid larger
+  /// vectorization factors by limiting MaxSafeDepDistBytes.
   bool couldPreventStoreLoadForward(unsigned Distance, unsigned TypeByteSize);
 };
 

Modified: llvm/trunk/lib/Analysis/LoopAccessAnalysis.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Analysis/LoopAccessAnalysis.cpp?rev=269667&r1=269666&r2=269667&view=diff
==============================================================================
--- llvm/trunk/lib/Analysis/LoopAccessAnalysis.cpp (original)
+++ llvm/trunk/lib/Analysis/LoopAccessAnalysis.cpp Mon May 16 11:57:47 2016
@@ -1081,14 +1081,20 @@ bool MemoryDepChecker::couldPreventStore
   //   hence on your typical architecture store-load forwarding does not take
   //   place. Vectorizing in such cases does not make sense.
   // Store-load forwarding distance.
-  const unsigned NumCyclesForStoreLoadThroughMemory = 8 * TypeByteSize;
+
+  // After this many iterations store-to-load forwarding conflicts should not
+  // cause any slowdowns.
+  const unsigned NumItersForStoreLoadThroughMemory = 8 * TypeByteSize;
   // Maximum vector factor.
   unsigned MaxVFWithoutSLForwardIssues = std::min(
       VectorizerParams::MaxVectorWidth * TypeByteSize, MaxSafeDepDistBytes);
 
+  // Compute the smallest VF at which the store and load would be misaligned.
   for (unsigned VF = 2 * TypeByteSize; VF <= MaxVFWithoutSLForwardIssues;
        VF *= 2) {
-    if (Distance % VF && Distance / VF < NumCyclesForStoreLoadThroughMemory) {
+    // If the number of vector iteration between the store and the load are
+    // small we could incur conflicts.
+    if (Distance % VF && Distance / VF < NumItersForStoreLoadThroughMemory) {
       MaxVFWithoutSLForwardIssues = (VF >>= 1);
       break;
     }