对库使用LLVM字节码(而不是本机对象文件)

Question

有什么影响

• 可移植性(调用约定:当只调用C或OS库函数时,它在LLVM级别真的很重要)
• 链接时间
• 优化

我想用LLVM编译一个玩具语言,因为已经存在所有的硬件(优化,目标代码生成),但是如果值得的话,我想要保留一个概念:库文件应该是可再发行,可用作静态和共享库(用于链接,在共享情况下,当最终应用程序链接时将生成真实的或者dll),可移植.我相信这会减少部分编译时间(因为本机代码生成和优化只能在最终二进制链接时完成一次).我设想链接器负责调用约定(如果可能)以及如果请求转换到共享库.在远伸此外,或许LLVM可以被利用来不链接,并使用LLVM JIT直接运行生成的字节码,在编写代码时完全删除链接倍.

这听起来不错

1. 可行？
2. 值得？我知道C/C++链接时间比较长,这在经常重建时会出现问题.那么自由链接时优化(CFR /GL,并-flto因为这将是基本LLVM字节码连接到一起,然后将变成一个本地二进制).

这可能是一个模糊的问题,如果我必须澄清一些问题,请询问.

Answer 1

我过去做过类似的事情.您应该意识到的一件事是LLVM bitcode不是"可移植的",因为它不是完全独立于机器的.Bitcode文件具有特定于目标处理器的指针大小等知识.

话虽如此,过去我已经将程序及其支持库编译为bitcode,并在生成整个程序的汇编文件之前将bitcode文件链接在一起.你是正确的,呼叫约定对于内部呼叫并不重要,但是在外部(或从外部)进行的呼叫仍然需要遵循ABI.

您可以设计您的玩具语言,以避免依赖于处理器的位代码,但您必须非常小心.

我注意到将bitcode文件链接在一起花了很长时间,特别是在高优化级别.这可能已经加速了,我用2年或3年前的LLVM做到了.

最后一点:根据目标处理器的不同,您可能需要等效的libgcc.a或compiler-rt来处理处理器不喜欢浮点或64位整数的东西,如果处理器没有指令那么执行这些操作.