Incremental Compilation Support in Clang
Vassil S. Vassilev, David J Lange · Zenodo (CERN European Organization for Nuclear Research) · 2020
Cling is a C++ interpreter built on top of clang and llvm. In a nutshell, it uses clang's incremental compilation facilities to process code chunk-by-chunk by assuming an ever-growing translation unit. Code is then lowered into llvm IR and run by the llvm jit. Cling has implemented language "extensions" such as execution statements on the global scope and error recovery. Cling is in the core of high-energy physics research -- it is heavily used during data analysis of exabytes of particle physics data coming from the Large Hadron Collider (LHC) and other particle physics experiments. We recently started a project aim at improving cling's sustainability and to make it a standalone tool. In this poster we would like to present one of the project's main directions -- move parts of cling upstream along with the clang and llvm features that enable them. Over the years we have slowly moved some patches upstream. However we still have around 100 patches in the clang fork. Most of them are in the context of extending the incremental compilation support for clang. The incremental compilation poses some challenges in the clang infrastructure. For example, we need to tune CodeGen to work with multiple llvm::Module instances, and finalize per each end-of-translation unit (we have multiple of them). Other changes include small adjustments in the FileManager's caching mechanism, and bug fixes in the SourceManager (code which can be reached mostly from within our setup). One conclusion we can draw from our research is that the clang infrastructure fits amazingly well to something which was not its main use case. The grand total of our diffs against clang-9 is: `62 files changed, 1294 insertions(+), 231 deletions(-)`. Cling is currently being upgraded from llvm-5 to llvm-9. A major weakness of cling's infrastructure is that it does not work with the clang Action infrastructure due to the lack of an IncrementalAction. We will present a possible way forward would be to implement a clang::IncrementalAction as a starting point.