Currently pass LSR runs before PPCCTRLoops, we meet some problem with this order because of the icmp inside loop which compares iteration indexed and loop count. In pass LSR, we always treat that icmp as a valid ICmpZero type LSRUse. But this is not true because in later pass HardwareLoops pass, we may replace this icmp with ctrloop instruction mtctr/bdnz. So we may get suboptimal code based on this order.
In Patch https://reviews.llvm.org/D62847, I made a patch which reorders LSR Pass and HardwareLoops pass. By reordering, LSR knows precisely whether the icmp is replaced or kept in HardwareLoops pass. But reviewers is uneasy about that patch and suggests we should add a target hook in LSR.
This patch add a target hook canSaveCmp() in TTI, it returns true only when we are sure that current handling loop in LSR is a hardware loop. If the loop is a hardware loop, we should not generate formulae for this icmp.
This is duplicating applicibility logic from the HardwareLoops pass? Can we move this into a utility function, maybe something like HardwareLoopInfo::canAnalyze(Loop *L)?