[llvm] [IndVarSimplify] Don't perform LFTR only to convert the predicate (PR #126086)

[Nikita Popov via llvm-commits]

nikic wrote:

I think @preames is probably the person with the most context on this.

I think the key question is: What are we trying to achieve with LFTR?

I think that originally, LFTR was probably envisioned as a canonicalizing transform, so that all loops with a known BECount take the same form of an equality comparison of a canonical IV against the BECount. In practice, this doesn't work out in multiple ways, the most notable being that we have to avoid high cost expansions, so we don't actually perform LFTR in many cases where it is, theoretically, possible.

Viewed as a canonical form, I'm not really sure what the value of LFTR is. For passes using SCEV it doesn't matter either way (evidenced by the fact that it could compute the BECount in the first place). For passes not using SCEV, the equality LFTR form is arguably worse than using an inequality exit condition -- equality exit conditions can essentially only be handled by sophisticated analysis like SCEV, while inequalities at least have trivial range implications.

Now, if we instead only consider it as an optimization, then we have to take a closer look at the costs. If LFTR allows us to eliminate instructions in the loop for additional instructions in the preheader, that will often be a profitable transform. This happens for example if LFTR can replace and and/or exit condition with a min/max comparison. However, if all LFTR does is change the predicate, then adding any number of additional preheader instructions is a bad tradeoff (unless it allows eliminating an IV).

There's also the additional complexity that IVs will be rewritten by LSR to be more efficient for the target, and that we have LoopTermFold, which is basically LFTR but performed post-LSR in the backend and targeting at the elimination of IVs.

https://github.com/llvm/llvm-project/pull/126086