AICF v2 - Online Accumulative Optimization 설계 문서 ( 여기서 Compiler 의 완성 )

연산 병합 fusion 과 실행 최적화가 어떤 원리로 이뤄저야 하는지를 정의

다음 질문에 대한 답을 제공하게 될 것

• 단순한 pattern matching 방식이 한계인 이유
• 누적 accumulative 방식에 대해
• 전통적 컴파일러 설계와의 연결
• emit - IR - compile - executor 구조에 맞게

 

1. 단순한 패턴 매칭 방식의 한계

1.1 패턴 매칭 접근

if sequence == [gemm, bias_add, relu]:
    replace_with(gemm_epilogue)

 

1.2 구조적 한계

• 패턴 폭발
• 레이어 경계 의존
• 컴파일러스럽지 않음, 수식이 아니라 문자열 패턴을 다루는 느낌
• 확장 유지보수 불가...

 

2. 핵심 전환 : 연산을 패턴이 아닌 수식으로 해석

2.1 관점 전환

연산 시퀀스는 op 나열이 아니라 실행 가능한 수식의 점진적 확장

gemm → bias_add → relu

///////////////////////

relu(gemm(A,B) + bias)

 

 

3. Online Accumulative Optimization 의 핵심 개념

3.1 Accumulator (누적 상태)

IR 의 순차 처리, 누적된 실행 표현 상태의 유지 - Accumulator

Base: GEMM
Epilogue:
  - bias: true
  - activation: relu

 

3.2 누적은 병합이 아닌 승격 (promote)

연산이 제거되는 것이 아닌 더 강한 실행 표현으로 변환

 

4. AND / OR 조건식 기반 변환 메커니즘

4.1 패턴 대신 조건식

문자열 매칭이 아닌 논리 조건식으로 결정된다.

can_absorb_bias =
    (current_state == GEMM)
    AND (bias_shape_compatible)
    AND (use_count == 1)

can_absorb_relu =
    (has_bias OR allow_relu_without_bias)
    AND (dtype_supported)

 

4.2 의미

• AND : 의미 보존 조건
• OR : backend 정책 / capability 선택

 

5. IR attrs vs Exec attrs - 역할 분리

5.1 IR attrs ( emit 시점 )

• 생성 위치 : layer.emit - b.emit
• 목적 : 의미 표현
• 인간 / 디버거 친화적

 

5.2 Exec attrs ( compile / lower 시점 )

• 생성 위치 : compile_cuda / lower
• 목적 : 실행 파라미터
• ABI pack 과 1:1 대응
• 누적 대상

 

추후 Cost-based 기반 확장 가능성 또한 존재