[triton] moveUpTranspose 최적화 제거 PR의 Revert - 회귀 방지

PR 링크: triton-lang/triton#9229 상태: Merged | 변경: +11 / -0

들어가며

컴파일러 최적화를 제거할 때는 충분한 벤치마크 커버리지가 필요합니다. #9204에서 "ConvertLayout이 실제 전치 코드를 생성하므로 TransposeOp 이동은 무의미하다"는 분석 하에 moveUpTranspose를 제거했지만, 일부 워크로드에서 성능 회귀가 발견되어 즉시 되돌렸습니다.

핵심 코드 분석

복원된 코드:

static void moveUpTranspose(triton::FuncOp funcOp) {
  SmallVector<triton::TransposeOpInterface> transOps;
  funcOp.walk([&](triton::TransposeOpInterface op) {
    transOps.push_back(op);
  });
  for (auto op : transOps)
    if (Operation *argOp = op.getSrc().getDefiningOp())
      op->moveAfter(argOp);
}

TransposeOp를 정의(definition) 바로 뒤로 이동시키는 단순한 최적화입니다. ConvertLayoutOp이 실제 전치를 수행하더라도, TransposeOp의 위치가 레지스터 수명에 영향을 미쳐 일부 커널의 레지스터 할당에 변화를 줄 수 있습니다.

왜 이게 좋은가

이 PR은 revert 문화의 좋은 사례입니다. 회귀가 발견되면 원인 분석에 시간을 들이기보다 먼저 되돌려서 안정성을 확보하고, 이후에 원인을 분석하여 개선된 버전을 다시 제출하는 것이 대규모 오픈소스 프로젝트의 표준 관행입니다. 실제로 이후 #9328에서 MoveUpPrologueLoads라는 새로운 패스로 ReorderInstructions를 완전히 대체했습니다.

정리

• #9204에서 제거한 moveUpTranspose 최적화 복원
• 일부 워크로드에서의 성능 회귀 방지
• 이후 #9328에서 근본적 재설계로 해결

참고 자료

• triton-lang/triton#9229
• triton-lang/triton#9204

이 분석은 AI가 실제 코드 diff를 기반으로 작성했습니다.