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