> > Would it be too intrusive to ask ScalarEvolution to use a > > PostDominanceFrontier for this? > > No, that's what I implemented at first. Unfortunately, it doesn't cover > all the possible cases (specifically, it broke 2007-01-06-TripCount.ll). > > In 2007-01-06-TripCount.ll there's two "loops" sharing one loop header. > The first runs from header -> exit -> A -> header and the other is > header -> B -> A -> header. I was testing exit postdom header, which it > does, but that didn't catch this case where the transform is still > unsafe. > > If you think I merely had my test wrong, please let me know what you > think it ought to be and I'll implement it and see.
I do think you merely had the wrong test. The post-dominance frontiers are needed here. Running -analyze -postdomfrontier on 2007-01-06-TripCount.ll gives this: Printing analysis 'Post-Dominance Frontier Construction' for function 'test': DomFrontier for BB %bb is: %bb2 %cond_next DomFrontier for BB %bb2 is: %bb2 %cond_next DomFrontier for BB %cond_true is: %bb2 DomFrontier for BB %cond_next is: %cond_next DomFrontier for BB %bb6 is: DomFrontier for BB %return is: DomFrontier for BB %entry is: It looks like %bb2 is the loop header, and %cond_next is the block that contains the exit branch. The frontier sets for these two blocks are different, so they're not control-equivalent, and that disqualifies the loop for what ScalarEvolution is doing here. Dan -- Dan Gohman, Cray Inc. _______________________________________________ llvm-commits mailing list llvm-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
