[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