IR compiler란?

이 글을 쓰는 이유

코틀린 진영은 지금까지 멀티플랫폼을 노리고 있는 언어입니다. 여러 환경에서 돌아갈 수 있도록 하겠다는 것인데요.

JVM뿐만 아니라, WASM, JS, Native Platform등에서 돌아갈 수 있는 언어를 만드려고 하고 있습니다.

하지만 대부분 사람들이 멀티플랫폼에서 돌리려고 하기보다는 JVM 원툴로 사용하고 있기 때문에 그리고 JVM에서 굴러가서

쓰는 사람들이 대부분이기 때문에 멀티플랫폼에 관련된 글을 적어서 이런 시도를 하고 있다! 라는 것을 알리고 싶었습니다.

 

그래서 IR 컴파일러가 뭔데?

IR컴파일러는 Kotlin IR(intermediate representation, 중간표현)으로 컴파일을 해주는 친구입니다. 자바가 바이트코드로 바꾸고 이걸 jvm위에 올려서 굴리는 것처럼 코틀린 IR으로 컴파일을 해주고 이 코드가 결과적으로 각각의 플랫폼에서 굴러갈 수 있는 친구들입니다.

이게 JS에서도 돌아가고 JVM에서도 돌아갑니다. Native도 IR로 돌아간다고 이야기했으나, 2024-01-03을 기준으로 공식문서를 봤을때는 자바스크립트와 JVM에서만 stable이 찍혀있습니다. 이 이후에 Native는 K2 Compiler에서 사용을 보장해주기로 했나봅니다.

 

결국 중간 표현 언어로 바꿔주는 것이죠. 

그래서 IR컴파일러를 왜 쓰는건데?

플랫폼 의존적인 컴파일러를 만들 수도 있을텐데 왜 IR 컴파일러를 쓰는걸까?

고수준 언어의 특징을 변환하는 부분이 있다면 플랫폼 별로 코드 복붙하면 되는거 아냐?

이런식으로 생각할 수도 있지만, Native 플랫폼을 지원하려고 한 이상 컴파일러의 프론트엔드와 백엔드를 구분하는게 더 이득일 확률이

높다. AST로 만드는 코드를 계속 들여다보기보다는 한번 중간 언어로 바꿔놓고 중간 언어에서 플랫폼에서 돌아갈 수 있도록 백엔드 컴파일러에만 집중하는 것이 더 효율적일 수 있다. 만약 특정 명령어 세트에서 더 최적화를 하고 싶다면, 모두가 동시에 개발하는 컴파일러보다는 

백엔드 컴파일러에만 집중하는게 더 최적화 하기 쉬울 것이다.

 

그리고 프론트엔드 컴파일이 되고나서는 백엔드 컴파일을 진행하게되는데, 여기에서 바이트 코드로 바꾸거나, 네이티브로 바꾸거나 JS코드로 바꾸는 등의 작업을 하게 되는 것이다. 그리고 중간표현으로 바뀌는 과정에서 이미 동일하게 모두가 정해진 컴파일 과정을 밟으므로 더 안정적으로 빠르게 컴파일을 할 수 있을 것이다.

 

 

다음 글

K2 컴파일러란?

이거 설명하려고 IR 컴파일러 먼저 들고 왔습니다.