[llvm] [AMDGPU] SIFixSGPRCopies avoid placing V_READFIRSTLANE inside the loop. (PR #186400)

[via llvm-commits]

================

----------------
alex-t wrote:

A "different parent block" heuristic would over-penalize (blocks can differ without any loop boundary, e.g. if-then-else) while giving us no way to detect the actual problem: a use site that is deeper in the loop nest than the copy.

The reason we need to get this right at the cost model stage is that once the chain is converted to VALU, legalizeOperands inserts V_READFIRSTLANE_B32 at the use site, and **no later pass can move it out** — V_READFIRSTLANE_B32 is marked isConvergent, so `MachineLICM` explicitly refuses to hoist it ([MachineLICM.cpp:1103](https://github.com/llvm/llvm-project/blob/main/llvm/lib/CodeGen/MachineLICM.cpp#L1103)).
I acknowledge SIFixSGPRCopies runs early (post-ISel) so this does trigger a fresh MachineLoopInfo computation. However, MachineLoopInfo is a lightweight analysis (a CFG walk to identify loops), and there is simply no way to fix this after the fact.

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