Android 中的 LLVM 主要做什么?

关注者
268
被浏览
12375
前面的答案里提到ART与LLVM的都是被hype荼毒的人呐。
前面答案说RenderScript和NDK的是正解。但是ART的就不算太正解了。

这是关于Android toolchain与NDK的部分的文档:
Beginning with the Jellybean MR1 release, Google has included LLVM as an alternative compiler as part of the Android toolchain and the Android NDK. LLVM is suitable wherever you use native code (C/C++) in your Android application.

这是介绍RenderScript与LLVM关系的一个演示稿:llvm.org/devmtg/2011-11

至于ART(Android Runtime),虽然在Kitkat放出的源码里其编译器的两个后端(Quick和Portable)中Portable后端基于LLVM来实现,但我还没见过谁用Kitkat-release的源码启用ART_USE_PORTABLE_COMPILER之后还能让ART正常运行的;大多做了这个尝试的人都败了,在编译时特别慢,而在运行时会遇到segfault。这个后端根本还是半成品。
实际大家在Kitkat上用的ART都不是用Portable后端,而是用Quick后端。这个编译器源自Dalvik VM的JIT编译器,被大幅魔改成了method-based AOT编译器。

而AOSP里最新的ART源码里已经彻底删除了整个Portable后端(以及另一个使用LLVM的后端“Sea IR”),包括里面的LLVM源码。请参考这个change:956af0f0cb05422e38c1d22cbef309d16b8a1a12 "Remove portable." - platform/art - Git at Google(及其review
到此为止ART已经跟LLVM彻底没关系。以后请别再忽悠新手说ART就是借助LLVM实现AOT编译了——之前不是,现在更不是。

至于为啥ART会删除了所有基于LLVM的后端,主要是公司内政治斗争+LLVM的编译速度实在慢…
- 为啥ART会删除了所有基于LLVM的后端? - Android Runtime (ART)

话说后来ART自身也可以用Clang来构建了。这个很重要。