[llvm] [LoopInterchange] Consider eligible inner subnests (PR #214920)

[via llvm-commits]

MattPD wrote:

Yes, substantial overlap. Thank you for the pointer; I missed [#199511](https://github.com/llvm/llvm-project/pull/199511).

I've taken a look and ran the motivating `bfs_loop_count_is_not_depth` and `uncomputable_sibling_does_not_block` test cases: #199511 (as of `6420173cbfcc`) interchanges both under default profitability and with `-loop-interchange-profitabilities=ignore`. Where both apply, its routing is more general: it can run the existing multi-swap algorithm on several collected subnests (while this patch deliberately tries a bounded set of parent/leaf-child pairs).

The remaining routing differences are policy or generality cases (which I don't believe I'll require for the follow-up SPECfp2000/SWIM2000 work): this patch isolates a computable inner pair below an uncomputable outer level, orders candidates deepest first, and stops after one transform. I don't think those differences justify competing routing implementations now.

I found two issues worth addressing separately on #199511 (I'll post the comments later):
1. With cache profitability explicitly enabled, a collected nested subnest gets no cache cost because its root is not outermost; an explicit-chain `CacheCost` construction avoids that.
2. The executed `print<loops>` probe shows the transformed pair appended after its siblings in LoopInfo, changing later loop-pass visitation order; `replaceChildLoopWith` preserves the original slot. 

Given the overlap and #199511's progress, I'm inclined to move #214920 back to draft and split out the independent 64-bit memory-ratio fix. (The direction-vector padding guard should not carry over unchanged; #199511 pads to absolute depth, then projects to the selected subnest.)

If #199511 lands, I think the SPECfp2000/SWIM2000 follow-ups (static outer-epilogue and runtime-bound) can use its candidate routing.

To confirm: I'll assume #199511 will own candidate routing, with the cache and sibling-order fixes moved there, unless reviewers prefer otherwise.


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