@krasin Thanks for the input. From my understanding ThinLTO is intended to bring compilation speed of LTO builds closer that of non-LTO builds. Prior to the change you are referring to with merged modules, it seems this was achieved by optimizing multiple .bc modules in parallel during link time (using summery information from thin-link) [1].

Is there any high-level information of the design behind merged modules? Are they simply a concatenation of .bc files with a table of file offsets for each module?

I am new to ThinLTO and the work related to merged modules, so any information providing insight would be appreciated.

As for the llir/llvm project. It includes a .ll parser, but relies on the LLVM toolchain for converting .bc files into .ll; i.e.

llvm-dis -o foo.ll foo.bc

This decision has been taken so that we can focus time on maintaining good support for one of the isomorphic LLVM IR forms.

Any application which requires good performance should definitely make use of the official LLVM C++ library for interacting with LLVM IR.

The llir/llvm project is intended for those who wish to write tools in Go which consume, produce, process or manipulate LLVM IR.

Future releases of llir/llvm will try to get closer in performance to the official LLVM C++ library, but at this point of the project the aim is to iron out a good API for interacting with LLVM IR, and to have fun coding :)

For those interested, the llir/llvm project was born to support the requirements of a decompiler project [2] which decompiles LLVM IR to Go source code. The llir/llvm project has since become a general purpose library, and is now looking for anyone curious to try it out at this early stage to provide feedback on its API and design.

[1]: http://blog.llvm.org/2016/06/thinlto-scalable-and-incrementa...

[2]: https://github.com/decomp/decomp