Language agnostic 为库使用LLVM字节码（而不是本机对象文件）

这意味着什么

• 可移植性（调用约定：当只调用C或OS库函数时，在LLVM级别它真的很重要吗）
• 连接时间
• 优化

我想用LLVM编译一个玩具语言，因为所有的困难部分都已经存在（优化、目标代码生成），但是我正在努力实现一个我想保留的概念，如果它值得的话：库文件应该是可再发行的，可以作为静态和共享库使用（对于链接，在共享情况下，最终应用程序链接时将生成一个真正的so或dll），可移植。我相信这将减少部分编译时间（因为本机代码生成和优化可能只在最终二进制链接时执行一次）。我设想链接器将处理调用约定（如果可能）如果需要，还可以将其转换为共享库。此外，还可以利用LLVM不进行链接，并使用LLVM JIT直接运行生成的字节码，从而在编写代码时完全消除链接时间

这听起来像吗

可行吗

值得吗？我知道C/C++链接时间相对较长，这在频繁重建时是有问题的。那么自由链接时间优化（cfr

/GL

和

-flto

呢，因为基本上是将LLVM字节码链接在一起，然后将其转换为本机二进制）

---

这可能是一个模糊的问题，如果我必须澄清一些事情，请提问。

我过去也做过类似的事情。您应该意识到，LLVM位代码不是“可移植的”因为它不是完全独立于机器的。位代码文件具有指针大小等特定于目标处理器的知识

话虽如此，在过去，我将程序及其支持库编译为位代码，并在为整个程序生成汇编文件之前将位代码文件链接在一起。您是对的，调用约定对于内部调用并不重要，但对于在外部（或从外部）进行的调用很重要仍然需要遵循ABI

您可能能够以这样一种方式设计您的玩具语言，即您可以避免依赖处理器的位代码，但是您必须非常小心

我注意到将位代码文件链接在一起需要花费相当长的时间，特别是在高优化级别上。这可能已经加快了，我在两三年前就用LLVM完成了

---

最后一点：根据目标处理器的不同，如果处理器没有执行浮点或64位整数操作的指令，您可能需要等效的libgcc.a或编译器rt来处理处理器不喜欢的事情。

感谢分享您的经验。我确实计划使用链接器“了解”对操作系统库的调用约定（将是C），并且也考虑了编译器rt的内容（例如异常支持），但这仍然是一个很长的路要走。看起来llvm ld的速度在时间上也得到了积极的提高（）我认为类型系统重写会有帮助。我应该再次尝试整个程序编译，这个概念很酷。：-）链接时间比什么长？Afaik链接时间主要取决于每个编译单元必须解析的符号数（源自其他编译单元），而不是语言。我也不确定LLVM字节码是否会自动清除调用约定。然后用LLVM编译的C++代码不能访问任何非LLVM编译。@ MarcovandeVoort：LLVM在生成本地对象代码时负责调用约定。如果我只调用LLVM代码（因此没有OS库），那么所有内容都将遵循相同的LLVM生成的调用约定。C/C++代码在编译时首先考虑了某种调用约定。Clang生成的LLVM位代码不是独立于平台的。我不明白为什么我的玩具语言需要在内部关注C调用约定。