This is an archive of the discontinued LLVM Phabricator instance.

Don't rely on the DepCands iteration order when constructing checking pointer groups
ClosedPublic

Authored by sbaranga on Jul 9 2015, 8:10 AM.

Details

Summary

The checking pointer group construction algorithm relied on the iteration on DepCands.
We would need the same leaders across runs and the same iteration order over the underlying std::set for determinism.

This changes the algorithm to process the pointers in the order in which they were added to the runtime check, which is deterministic.
We need to update the tests, since the order in which pointers appear has changed.

No new tests were added, since it is impossible to test for non-determinism.

Diff Detail

Repository
rL LLVM

Event Timeline

sbaranga updated this revision to Diff 29335.Jul 9 2015, 8:10 AM
sbaranga retitled this revision from to Don't rely on the DepCands iteration oreder when constructing checking pointer groups.
sbaranga updated this object.
sbaranga added a subscriber: llvm-commits.
sbaranga retitled this revision from Don't rely on the DepCands iteration oreder when constructing checking pointer groups to Don't rely on the DepCands iteration order when constructing checking pointer groups.Jul 9 2015, 8:15 AM
This revision was automatically updated to reflect the committed changes.
anemet added a subscriber: anemet.Jul 9 2015, 10:00 AM
anemet added inline comments.
llvm/trunk/lib/Analysis/LoopAccessAnalysis.cpp
245

s/indeces/indices

245–253

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.

sbaranga added inline comments.Jul 10 2015, 6:40 AM
llvm/trunk/lib/Analysis/LoopAccessAnalysis.cpp
245–253

I think that's correct, they don't actually need to be sorted - at least with the current implementation of equivalence classes. I think the question is if this is a guarantee or an internal implementation detail. I can't find any place that explicitly makes this guarantee.

anemet added inline comments.Jul 10 2015, 4:19 PM
llvm/trunk/lib/Analysis/LoopAccessAnalysis.cpp
245–253

Sounds like something that is worth documenting (it removes redundant work in our case).

People can object if there is a reason to keep this unspecified but I don't see why that would be useful.

sbaranga added inline comments.Jul 13 2015, 7:50 AM
llvm/trunk/lib/Analysis/LoopAccessAnalysis.cpp
245–253

Thanks! I've removed the call to std::sort in r242033, I'll update the documentation in another change.