[PATCH] D11064: Don't rely on the DepCands iteration order when constructing checking pointer groups

Adam Nemet anemet at apple.com
Thu Jul 9 10:00:51 PDT 2015


anemet added a subscriber: anemet.

================
Comment at: llvm/trunk/lib/Analysis/LoopAccessAnalysis.cpp:245
@@ -232,2 +244,3 @@
 
-    for (auto MI = DepCands.member_begin(DI), ME = DepCands.member_end();
+    // Get all indeces of the members of this equivalence class and sort them.
+    // This will allow us to process all accesses in the order in which they
----------------
s/indeces/indices


================
Comment at: llvm/trunk/lib/Analysis/LoopAccessAnalysis.cpp:245-253
@@ -232,4 +244,11 @@
 
-    for (auto MI = DepCands.member_begin(DI), ME = DepCands.member_end();
+    // Get all indeces of the members of this equivalence class and sort them.
+    // This will allow us to process all accesses in the order in which they
+    // were added to the RuntimePointerCheck.
+    for (auto MI = DepCands.member_begin(LeaderI), ME = DepCands.member_end();
          MI != ME; ++MI) {
       unsigned Pointer = PositionMap[MI->getPointer()];
+      MemberIndices.push_back(Pointer);
+    }
+    std::sort(MemberIndices.begin(), MemberIndices.end());
+
----------------
anemet wrote:
> s/indeces/indices
> 
Are you positive we need to sort the members too?

I think these are hooked up to the equivalence class in program order and it's effectively a linked list, so they should preserve the chaining order.

Either way it needs a comment.


Repository:
  rL LLVM

http://reviews.llvm.org/D11064







More information about the llvm-commits mailing list