AICF IR Flag System 도입 문서

1. 배경

기존 AICF 구조에서는

• OpKind (문자열)
• kind_id, attr_schema, attr_blob (백엔드 실행 정보)

만 존재,

연산의 성격은 Optimizer 단계에서 kind 이름 기반으로 판별하거나 하드코딩 조건문으로 분기해야 했음

이 방식은

• 연산 이름에 의존하는 취약한 설계
• 새 Op 추가 시 Pass 코드 수정 필요
• Fusion 정책이 문자열 기반 분기 로직에 종속됨
• IR 레벨에서 연산 분류 체계가 존재하지 않음

 

2. 변경 목적

Emitter 단계에서 연산의 정적 본질을 비트마스크로 IR 노드에 직접 각인한다

이를 통해

• 문자열 분기 제거
• Pass 단계 단순화
• Fusion 조건을 수학적 판정식으로 정의 가능
• 확장성 확보

 

3. 설계 개요

Flag 계층 구조

0 ~ 15 bit   : Static Flags  (Emitter가 설정)
16 ~ 31 bit  : Derived Flags (Pass가 설정)

 

4. OpFlags 정의

class OpFlags:
    NONE = 0

    # --- Static Flags ---
    IS_GEMM_LIKE   = 1 << 0
    IS_ELEMENTWISE = 1 << 1
    IS_REDUCE      = 1 << 2
    IS_OPTIMIZER   = 1 << 3
    HAS_STATE      = 1 << 4
    TERMINAL       = 1 << 5
    INPLACE_PREF   = 1 << 6

    # --- Derived Flags ---
    SAFE_NODE      = 1 << 16
    FUSION_BARRIER = 1 << 17
    DTYPE_F32      = 1 << 18

 

5. emit_resolved 변경 사항

신규 인자

static_flags: int = OpFlags.NONE

신규 필드 주입

op.static_flags = int(static_flags)
op.derived_flags = 0

전체 구조 요약

• Builder.emit()
• backend 실행 정보 주입
• static_flags 각인
• derived_flags 초기화

 

6. Static vs Derived 분리 이유

Static Flags	Emitter	연산의 본질 (변하지 않음)
Derived Flags	Pass	그래프 맥락에 따라 변함

• GEMM 은 항상 IS_GEMM_LIKE
• 하지만 SAFE_NODE 는 그래프 연결 구조에 따라 달라짐

 

7. 사용 예시

GEMM

static_flags = OpFlags.IS_GEMM_LIKE

Add

static_flags = OpFlags.IS_ELEMENTWISE

AdamStep

static_flags = (
    OpFlags.IS_OPTIMIZER |
    OpFlags.HAS_STATE |
    OpFlags.INPLACE_PREF
)

 

8. Fusion 판정 예시

문자열 비교가 아닌 다음과 같이 가능

if (
    (op.static_flags & OpFlags.IS_GEMM_LIKE) and
    (next_op.static_flags & OpFlags.IS_ELEMENTWISE) and
    not (op.derived_flags & OpFlags.FUSION_BARRIER)
):
    fuse(op, next_op)