opt -enable-new-pm=1 -loop-load-elim -indvars -loop-distribute -enable-loop-distribute crashes with Assertion `Ptr != End && "dereferencing end() iterator"' failed.

[mikaelholmen]

Bugzilla Link	51598
Version	trunk
OS	Linux
Attachments	bbi-58974.ll reproducer
CC	@aeubanks,@alinas,@bjope

Extended Description

llvm commit ebf35370ff59

Reproduce with: opt -enable-new-pm=1 -loop-load-elim -indvars -loop-distribute -enable-loop-distribute -o /dev/null bbi-58974.ll

Result: opt: ../include/llvm/ADT/DenseMap.h:1242: llvm::DenseMapIterator::pointer llvm::DenseMapIterator<llvm::PointerIntPair<llvm::Value , 1, bool, llvm::PointerLikeTypeTraits<llvm::Value >, llvm::PointerIntPairInfo<llvm::Value , 1, llvm::PointerLikeTypeTraits<llvm::Value > > >, std::vector<unsigned int, std::allocator >, llvm::DenseMapInfo<llvm::PointerIntPair<llvm::Value , 1, bool, llvm::PointerLikeTypeTraits<llvm::Value >, llvm::PointerIntPairInfo<llvm::Value , 1, llvm::PointerLikeTypeTraits<llvm::Value > > > >, llvm::detail::DenseMapPair<llvm::PointerIntPair<llvm::Value , 1, bool, llvm::PointerLikeTypeTraits<llvm::Value >, llvm::PointerIntPairInfo<llvm::Value , 1, llvm::PointerLikeTypeTraits<llvm::Value > > >, std::vector<unsigned int, std::allocator > >, true>::operator->() const [KeyT = llvm::PointerIntPair<llvm::Value , 1, bool, llvm::PointerLikeTypeTraits<llvm::Value >, llvm::PointerIntPairInfo<llvm::Value , 1, llvm::PointerLikeTypeTraits<llvm::Value > > >, ValueT = std::vector<unsigned int, std::allocator >, KeyInfoT = llvm::DenseMapInfo<llvm::PointerIntPair<llvm::Value , 1, bool, llvm::PointerLikeTypeTraits<llvm::Value >, llvm::PointerIntPairInfo<llvm::Value , 1, llvm::PointerLikeTypeTraits<llvm::Value > > > >, Bucket = llvm::detail::DenseMapPair<llvm::PointerIntPair<llvm::Value , 1, bool, llvm::PointerLikeTypeTraits<llvm::Value >, llvm::PointerIntPairInfo<llvm::Value , 1, llvm::PointerLikeTypeTraits<llvm::Value > > >, std::vector<unsigned int, std::allocator > >, IsConst = true]: Assertion `Ptr != End && "dereferencing end() iterator"' failed.

[aeubanks]

Yeah a loop pass should not be impacting a sibling loop's analyses. That's why we enforce LCSSA.

[bjope]

As far as I can tell Indvars isn't removing any loops. But it is doing rewrite such as

rewriteLoopExitValues: AfterLoopVal = %tnr1 = bitcast %struct.tnr_t %tnr to <2 x i16> LoopVal = %1 = bitcast i16 %tnr17 to <2 x i16>

which somehow impacts the memory dependencies.

But when exiting the loop pass manager we do not see any invalidation of memory dependence analyses for the for.body49.lver.orig loop (which I think might be impcated by that change) because the rewrites are done for the loop %for.body5, which is invalidated according to -debug-pass-manager=verbose: Invalidating analysis: LoopAccessAnalysis on Loop at depth 1 containing: %for.body5

,%crit_edge

I wonder if indvars is doing something bad here (impacting the analysis of another loop). I guess it shouldn't be a loop pass if it is doing such things.

Maybe my analysis above is wrong (a bit hard to follow what happens when debugging this, and it is a pity that there is no verifier that catches that the analysis is stale here (that we get different results if invalidating and recalculating it after the loop pass manager, or before LoopDistribute). But maybe it is the rewriteLoopExitValues that is a bit too wild, also impacting other loops and not only the current loop. I haven't found any API really to discard analyses for other loops (or the LoopAnalysisManager) that could be used from inside a loop pass like Indvars.

[bjope]

Can also be reproduced using

opt -passes='loop(require),function(loop(indvars)),function(loop-distribute)' -enable-loop-distribute -o /dev/null bbi-58974.ll

so loop-load-elim only worked as a trigger to populate the analysis cache.

[fhahn]

Still crashing: https://llvm.godbolt.org/z/4bqhae9hd

[fhahn]

Proposed fix is to change LAA to a function analysis: https://reviews.llvm.org/D134606

[mikaelholmen]

Thanks!