我最近开始使用 emscripten c/c++ to javascript 编译器做一些工作，当尝试从源代码构建编译器时，我看到它有一个特定版本的 clang 为自己。
直到现在，我都找不到任何理由说明为什么会有一个单独的编译器版本。我的印象是，如果您遵循 llvm 规范，并且为两者使用相同的 llvm 版本，每个后端都可以从每个前端获取输入。我可以想象人们可以使用这种方法来使用特定的命令行选项，但看不到重建整个事物的优势，而不是通过脚本来完成这项工作并连接点。
那么，与仅仅实现后端相比，进行特定的 clang 构建究竟有哪些优势？
【问题讨论】：
标签： compiler-construction clang llvm emscripten
实现后端正是我们为 WebAssembly 所做的工作，Emscripten 最终将能够将该后端用于 WebAssembly 和 asm.js。
Emscripten 和 PNaCl 是作为不确定的实验开始的，没有足够的 LLVM 经验。与满足 LLVM 的约束相比，作者更容易以他们认为合理的方式编写自己的东西。由于这些事情通常会发生，这些实验并没有完全消失......但随着时间的推移，WebAssembly 应该会让一切变得正确。
LLVM 的约束是完全明智的：保持高代码质量，不增加维护负担，避免在代码层之间创建不必要的依赖关系。这使得 LLVM 能够成功：当它接受新的后端时，LLVM 希望作为一个整体变得更好，不受新后端的负担，或者拥有一个孤立存在的后端，或者变得无人维护。其他限制更具历史意义：当PNaCl started in ~2010 (video) LLVM 没有很好地支持 NaCl's x86 sandboxes 所依赖的 x86 指令捆绑，或者 NaCl 依赖其 x86-64 sandbox 的 x32 时，以及两者都支持 PNaCl Emscripten 并不清楚当时如何支持virtual ISAs。我过于简单化了，许多其他因素都影响了这些决定，我敢肯定，如果他们今天做出这些决定，事情会变得不同。
PNaCl 仍然有很大的变化（LLVM 和 clang 分叉），尽管其中许多让上游 LLVM 和 PNaCl 开发人员参与了代码审查，这使得 LLVM 对 PNaCl 的用例更加友好。这些更改分为三类：NaCl 沙盒所需的后端更改（subzero 打算替换），bitcode "simplification" passes 代表后端完成“LLVM 方式”（并且 Emscripten 使用），以及其他许多随机更改其中可以上游。
Emscripten 在迁移到 fastcomp 而不是之前的方法时看到了重大的方法变化。
请注意，不仅仅是 LLVM 和 clang：这些编译器还依赖于 C++ 标准库（两者都有 libc++ / libc++abi，大部分未更改，PNaCl 用于支持 libstdc++）、C 标准库（两者都有 musl、PNaCl还有 newlib、bionic、某种形式的 glibc)、编译器运行时 (compiler-rt)、链接器和通用用户库，例如 SDL（Emscripten 的一部分，以及webports 中的 PNaCl）。
在这两种情况下，编译器都会半频繁地重新定位到主干 LLVM，尽管 Emscripten 的更改比 PNaCl 的更容易重新定位。维护分叉的成本很高！
【讨论】：