# QBE - 컴파일러 백엔드: 버전 1.3

> Clean Markdown view of GeekNews topic #30087. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30087](https://news.hada.io/topic?id=30087)
- GeekNews Markdown: [https://news.hada.io/topic/30087.md](https://news.hada.io/topic/30087.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-02T09:22:36+09:00
- Updated: 2026-06-02T09:22:36+09:00
- Original source: [c9x.me](https://c9x.me/compile/release/qbe-1.3.html)
- Points: 1
- Comments: 1

## Topic Body

- **성능 최적화**가 크게 추가되어 QBE 1.3은 vanilla [coremark](https://www.eembc.org/coremark/)에서 상용 컴파일러 성능의 63% 이상을 기록하고, Hare 테스트 스위트에서는 qbe-1.2 대비 33% 개선됨
- QBE 1.3은 1.0 이후 가장 큰 릴리스로, 약 **7k 줄 추가**와 1.5k 줄 삭제가 포함됨
- 새 최적화에는 **GVN/GCM**, 루프 최적화, if 제거, CFG 단순화 등이 포함됐지만, 검증된 일부 패스만 유지됨
- 인라이닝은 QBE의 **함수 단위 스트리밍 컴파일 모델**과 맞지 않는 문제가 있어 이번 최적화 세트에서 제외됨
- `ee_isdigit`를 인라인하고 `crcu8`를 더 단순한 분기 없는 구현으로 바꾼 coremark 변형에서는 QBE가 목표였던 `gcc -O2` 대비 70% 성능에 도달함
- 새 OCaml 도구 **`mgen`** 이 lispy IL 패턴을 C 매칭 코드로 컴파일해, 기존 수작업 명령 선택 로직을 대체하거나 단순화할 수 있게 됨
- `mgen`은 특수 주석 블록의 IL 패턴을 찾아 바로 아래에 C 코드를 삽입하며, 현재 사용 예는 [`isel.c`](https://c9x.me/git/qbe.git/tree/amd64/isel.c?id=c0818978acec60ebb6167fade60fb7012cbf20ca#n667)에 있음
- 명령 DAG 매칭은 Ken Thompson의 Plan9 C 컴파일러 방식과 유사한 번호 매기기 접근을 따르며, `runmatch()`가 해석하는 단순 바이트코드 매처도 생성됨
- **Windows ABI** 지원이 추가되어 `-t amd64_win`을 넘기면 Windows 대상 컴파일이 가능해짐
- QBE가 생성하는 어셈블리는 여전히 AT&T 문법이며, mingw 어셈블러로 컴파일하는 방식이 적합하다고 안내됨
- 위치 독립 코드 지원이 개선되어 대부분의 대상에서 공유 객체와 더 원활히 링크하고 공유 객체를 생성할 수 있게 됨
- 새 `extern` 동적 상수 플래그(`DYNCONST`)로 IL 수준에서 동적 라이브러리 변수 같은 전역 심볼의 간접 접근을 표현할 수 있음

## Comments



### Comment 58772

- Author: neo
- Created: 2026-06-02T09:22:37+09:00
- Points: 1

###### [Lobste.rs 의견들](https://lobste.rs/s/aahxxs/qbe_compiler_backend_version_1_3) 
- 오래 진행 중인 취미 프로젝트로 **TRIPOS/Amiga Exec 스타일의 작은 OS**를 만들고 있음  
  메모리 보호가 없고, 평면 메모리 맵이며, 메시지 전달도 포인터를 넘기는 수준임  
  이런 시스템을 자체 호스팅하려면 **PIE/PIC**를 만들 수 있는 작은 컴파일러가 훨씬 편함. Amiga 스타일 라이브러리는 당연히 PIC여야 하고, 실행 파일을 공유 메모리 맵 어딘가에 올릴 때 로드 시점 패치를 많이 하지 않아도 되는 점도 좋음  
  GCC와 Clang은 가능하지만 너무 거대함. 마지막으로 확인했을 때 TCC는 PIC를 못 했고, QBE를 더 살펴봐야겠음
  - 내 C 컴파일러는 **PIC**를 만들 수 있으니 관심 있을지도 모름: https://codeberg.org/lsof/antcc/  
    자기 홍보처럼 들리지 않았으면 함. 작은 컴파일러 분야를 정말 좋아하고, 테스트도 더 많이 필요함
  - 나도 평면 메모리 맵, 전부 PIE, 시스템 호출이 함수 호출인 OS인 [Ashet OS](https://github.com/Ashet-Technologies/Ashet-OS)를 만들고 있음  
    이미 꽤 진척됐고, 여러 플랫폼을 지원함  
    곧 자체 호스팅까지 가기는 어려울 듯함. **Thumb-2 코드 생성**이 필요하고, 이를 돌릴 방법이 사실상 직접 컴파일러를 쓰는 것뿐이기 때문임. 커널 코드를 제외하고 사용 가능한 RAM이 8MB뿐이라는 제약이 있음  
    ELF 파일을 변환해 만드는 자체 실행 파일 형식 `.ashex`를 사용함. 이 과정에서 사실상 절대 점프 하나인 특수 섹션을 소비하고, 앱 로더가 이를 실제 시스템 호출 주소로 다시 씀  
    평면 메모리 시스템의 어려움은 공유 객체를 깔끔하게 지원하는 데 있음. 서로 다른 애플리케이션 사이에서 코드를 공유하려면 모든 동적 심볼 접근이 레지스터에 저장된 변수를 통해 이뤄지도록 컴파일러 지원이 필요함

- 새 **`extern` 키워드**가 생겨서 정말 반가움  
  릴리스 노트에는 없지만 이것이 `thread`와도 함께 동작해서 initial-exec TLS를 가능하게 함. 다른 공유 라이브러리에 정의된 스레드 로컬 전역 변수에 접근할 때 필요하며, FreeBSD의 `ctype.h`에 필요함  
  `extern`은 macOS나 Haiku 같은 플랫폼에서 공유 라이브러리의 일반 전역 변수, 예를 들어 `stderr`에 접근할 때도 필요함. 이제 QBE 기반 컴파일러가 훨씬 더 많은 운영체제와 사용 사례를 지원할 수 있게 됨  
  Roland의 **성능 개선**도 매우 고마움. 정말 훌륭한 작업을 했음

- 이걸 제대로 읽은 게 맞다면 **정식 Windows 지원**이 들어간 건가?  
  QBE의 역사적이면서도 현재까지 큰 제약 중 하나가 이 부분 아니었나? 정말 보기 좋음

- 이 프로젝트의 목표가 **Cranelift**와 겹치나? 언제 QBE를 쓰는지 잘 감이 안 옴
  - QBE는 컴파일러 백엔드계의 “OpenBSD”에 가까움. 단순성과 미니멀리즘이 철학이고, [공식 설명](https://c9x.me/compile/)에 따르면 “산업용 최적화 컴파일러 성능의 70%를 코드 10%로 제공”하는 것이 목표임  
    경쟁 대상은 실제로 Cranelift와 LLVM임  
    아쉽게도 과거에는 주로 취미 언어나 컴파일러 구현에서 쓰였음. 예를 들어 새 C 계열 언어처럼 보였던 [myrddin](https://myrlang.org/)은 이제 죽은 듯하고, [cproc](https://sr.ht/~mcf/cproc/)는 아직 살아 있는 취미용 C 컴파일러 구현임  
    그래도 [Hare가 QBE를 채택](https://harelang.org/)한 뒤로는 기대가 생겼음. 질문에 대한 답은 여기 있음: https://harelang.org/documentation/faq.html#why-qbe-instead-of-llvm
  - Cranelift뿐 아니라 LLVM과도 목표가 겹친다고 봄  
    자세히 잘 아는 건 아니지만 비교 자료는 많이 있음. 아는 범위에서는 QBE가 다른 두 가지보다 훨씬 **단순한 백엔드**를 지향함

- 명령어 선택 매처를 생성하는 데 작은 **DSL**을 쓰는 방식이 정말 멋짐