[MThreads][TLE] Reusing a TME descriptor across K iterations crashes llc: cannot allocate physical SH register for TME operand

## 问题描述

在 MThreads 后端编译一个包含真实 `tle.gpu.copy`、显式 barrier 和多个 warp-specialized role 的 TLE kernel 时：

- 每个 TME descriptor 只使用一次（`K_CAP=1`）可以正常编译；
- 同一个 descriptor 在两个 K iteration 中复用（`K_CAP=2`）时，`llc` 稳定崩溃：

```text
LLVM ERROR: cannot allocate physical SH register for TME operand
```

失败发生在编译阶段，kernel 尚未启动，因此与运行时同步、MT-SHMEM 或通信无关。

## 测试环境

- Hardware: MThreads S5000 80GB
- FlagTree commit:

```text
7ef26f610d361d4fba031c01e8ad8e516e53f144
```

- FlagTree tracked source status: clean

- 未设置任何 `TRITON_MUSA_LLC_*` 编译器覆盖。
- 使用 FlagTree checkout 自带的 MThreads backend 与 `llc`。

## TLE Python 最小复现

主附件：

```text
tle-python-repro-source-20260916.tar.gz
```

主要文件：

```text
loader_only_repro.py
fused_loader_role.py
v234_math_role.py
dispatch_role.py
v234_fence.py
run_repro.sh
README.md
```

该 case 直接调用 `triton.compile`，并明确满足：

```text
gpu_allocated = false
kernel_launched = false
```

它不初始化 MT-SHMEM，不执行 dispatch、通信、scatter 或 combine。

保留的 TLE 结构为：

```text
default/idle role : 4 warps
math0 : 4 warps
math1 : 4 warps
A TME producer : 1 warp
B TME producer : 1 warp
```

其中：

- A/B producer 使用真实 `tle.gpu.copy`；
- math role 保留真实矩阵计算；
- 使用公开的 `tle.gpu.alloc_barriers`、`barrier_wait` 和 `barrier_arrive`；
- 不使用 `tle.pipe`；
- 不使用 two-writer pipe；
- 不使用私有 barrier helper；
- 不修改编译器。

## 复现命令

```bash
tar -xzf tle-python-repro-source-20260916.tar.gz
cd tle-python-repro-source-20260916

FLAGTREE_ROOT=/path/to/FlagTree \
RUN_DIR=/tmp/tme-sh-repro \
bash run_repro.sh
```

脚本从独立 cache 分别编译 `K_CAP=1` 和 `K_CAP=2`。

## 实际结果

| Case | TME descriptor 使用情况 | 结果 |
|---|---|---|
| `K_CAP=1` | 每个 descriptor 一个有效 K iteration | PASS |
| `K_CAP=2` | 同一个 descriptor 跨两个 K iteration 复用 | FAIL |

`K_CAP=1`：

```text
RESULT {
"status": "PASS",
"k_cap": 1,
"async_tme_ttgir": 2,
"gpu_allocated": false,
"kernel_launched": false
}
```

`K_CAP=2`：

```text
RuntimeError: `llc` failed with error code -6

LLVM ERROR: cannot allocate physical SH register for TME operand

Running pass:
MTGPU Machine Instr Pseudo Custom Elimination

Function:
loader_only_kernel
```

相关 stack frame：

```text
MTGPUPseudoCustomElimination::legalizeTMEDescAddr
MTGPUPseudoCustomElimination::runOnMachineFunction
```

脚本最终输出：

```text
EXPECTED_REPRODUCED: K1 passes; K2 fails in TME SH allocation
```

## 期望行为

`K_CAP=2` 应当像 `K_CAP=1` 一样正常完成编译。

即使硬件资源确实不足，编译器也不应在 `legalizeTMEDescAddr` 中 fatal；至少应给出可恢复的资源诊断。

## 完整业务代码交叉验证

在完整 MegaMoE TLE kernel 上还进行了以下四组 compile-only 对照：

| K cap | SFA loader | 结果 |
|---:|---|---|
| 1 | scalar | PASS |
| 2 | scalar | 同一 SH 错误 |
| 1 | TME | PASS |
| 2 | TME | 同一 SH 错误 |

因此该问题不依赖 SFA 使用 scalar copy 还是 TME copy。

在当前 kernel 和编译环境下，K=1 可以编译，而 K=2 稳定触发问题。

## 初步定位

根据 K=1/K=2 的机器 IR 对比，初步观察到：

- K=1 时，TME descriptor 地址可以直接使用 ABI 中已有的 SH 寄存器对；
- K=2 时，同一个 descriptor 跨多个 TME callsite 使用，地址被转换为临时的 64-bit value；
- `legalizeTMEDescAddr` 随后尝试为该地址重新申请连续的 SH 寄存器对；
- 当前 kernel 的 math role 和跨 role 数据流已经造成较高 SH 寄存器压力；
- 后端无法找到新的连续 SH pair，最终触发 fatal error。

这只是基于生成 IR 的初步分析，希望编译器团队帮助确认 descriptor 地址合法化及 SH register allocation 是否存在问题。

## 辅助证据

辅助证据包：

```text
tle-python-repro-aux-evidence-20260916.tar.gz
```

其中包含：

- K=1/K=2 完整日志；
- 环境与源码指纹；
- TTIR/TTGIR/LLIR；
- `verdict.txt`；
- 失败时保存的 `kernel.ll`。

`kernel.ll` 仅作为后端直接重放和定位的辅助材料；TLE Python 文件是本 issue 的主复现。

## 附件

[tle-python-repro-source-20260916.tar.gz](https://github.com/user-attachments/files/32269241/tle-python-repro-source-20260916.tar.gz)
[tle-python-repro-aux-evidence-20260916.tar.gz](https://github.com/user-attachments/files/32269240/tle-python-repro-aux-evidence-20260916.tar.gz)

Start with README.md, loader_only_repro.py, and run_repro.sh in the attached reproduction archive, then run the script against the specified FlagTree checkout. Compare the K_CAP=1 and K_CAP=2 compiler output and inspect the reported legalizeTMEDescAddr path; done means K_CAP=2 compiles without the fatal SH-register allocation error.

Written by the indexing model from the issue text.