[llvm] [polly] [LoopInfo] Add an opaque LoopRef handle and stop exposing loop containers (PR #210653)

[Fangrui Song via llvm-commits]

MaskRay wrote:

> I think the PR should be split:

Sounds right.

> * Improved updating facilities. These seem ok.

> * Moving some things to LoopInfo. Doable, although no benefit?

It's a precondition for changing the representation (e.g. Euler tour technique using a modified reverse post order like TPDE analysis / llvm::ModifiedPostOrder). The alternative is for every LoopBase to hold a back pointer to LoopInfoBase, which I'd rather shrink than grow.

> * LoopRef. What's the long-term plan here? I don't think it's feasible to do deeper changes or improvements to LoopInfo -- the current design is depended upon in so many places. This might just end up as a lot of code churn for little (which exact?) benefit and another half-finished migration?

The handle isn't carry weight here. The intent was for all mutation operations to use LoopRef.

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