This was trigerred by the debug check when comp(a, a) was called.
On line 216 it's checked that LoopBlockNumber should contain
all if there are more than 1. NFC for end users
I don't have commit rights. Danila Kutenin. kutdanila@yandex.ru
Differential D157954
[LoopSink] Don't sort BBs if there is only 1 of them (NFC) danlark on Aug 15 2023, 1:52 AM. Authored by
Details This was trigerred by the debug check when comp(a, a) was called. I don't have commit rights. Danila Kutenin. kutdanila@yandex.ru
Diff Detail
Event TimelineComment Actions If you build llvm with libcxx at head as a standard library with -D_LIBCPP_DEBUG_STRICT_WEAK_ORDERING_CHECK and -D_LIBCPP_ENABLE_DEBUG_MODE, then for this sorting it will invoke comp(a, a) for llvm/test/Transforms/LICM/loopsink.ll.test This change is extremely safe, on line 216 it's checked that llvm::set_is_subset(BBsToSinkInto, LoopBlockNumber) if BBsToSinkInto.size() > 1. If it's size 1, it implicitly thought no comparator would be called. But it can and LoopBlockNumber.find(A)->second will be a .end() iterator dereference Comment Actions LGTM. Took me a while to get it, but you're saying that by default sort with one element will not invoke the comparison callback, while in debug mode it will be done to verify the strict weak ordering. That's why we did not previously hit the assertion failure. I'm not sure whether this is really the right fix (possibly the earlier BBsToSinkInto.size() > 1 check should be removed), but this is fine to fix the assertion failure while keeping the current behavior. |