[PATCH] LowerBitSets: Introduce global layout builder.

Peter Collingbourne peter at pcc.me.uk
Fri Feb 20 15:04:15 PST 2015

Comment at: lib/Transforms/IPO/LowerBitSets.cpp:552
@@ +551,3 @@
+        [](const std::set<uint64_t> &O1, const std::set<uint64_t> &O2) {
+          return O1.size() < O2.size();
+        });
jfb wrote:
> pcc wrote:
> > jfb wrote:
> > > pcc wrote:
> > > > jfb wrote:
> > > > > This won't be deterministic without a tie-breaker?
> > > > Because I'm using `stable_sort`, it should be as deterministic as `EquivalenceClasses` is. I'm not certain, but it looks like the only non-determinism there relates to the order in which elements are visited (i.e. begin()..end()), not the order in which members of equivalence classes are visited (member_begin()..member_end()). That's a separate problem which we should fix somehow.
> > > My main concern is that order of iteration of `std::set` isn't stable, am I understanding correctly?
> > I don't understand. We aren't iterating over `std::set` here. `BitSetMembers` is a `std::vector`.
> Sorry, explaining myself badly: if the `std::set` are equal then we can't iterate through them to compare members? I guess your point was that using `std::stable_sort` keeps the same order as `BitSetMembers` already had, and that was already deterministic?
I still don't get it. We aren't iterating over any `std::set`s here, we are only taking their sizes. Anyway, `std::set`s are ordered, see http://en.cppreference.com/w/cpp/container/set



More information about the llvm-commits mailing list