[cfe-dev] [RFC] Moving (parts of) the Cling REPL in Clang

Vassil Vassilev via cfe-dev cfe-dev at lists.llvm.org
Tue Dec 1 10:50:56 PST 2020 

On 7/11/20 12:10 AM, Hal Finkel wrote:
>
>
> On 7/10/20 4:00 PM, JF Bastien wrote:
>>
>>
>>> On Jul 10, 2020, at 1:55 PM, Hal Finkel <hfinkel at anl.gov 
>>> <mailto:hfinkel at anl.gov>> wrote:
>>>
>>>
>>> On 7/10/20 1:57 PM, Vassil Vassilev wrote:
>>>> On 7/10/20 6:43 AM, JF Bastien wrote:
>>>>> I like cling, and having it integrated with the rest of the 
>>>>> project would be neat. I agree with Hal’s suggestion to explain 
>>>>> the design of what remains. It sounds like a pretty small amount 
>>>>> of code.
>>>>
>>>>
>>>> JF, Hal, did you mean you want a design document of how cling in 
>>>> general or a design RFC for the patches we have? A design document 
>>>> for cling would be quite large and will take us some time to write 
>>>> up. OTOH, we could relatively easily give a rationale for each patch.
>>>
>>>
>>> I had in mind something that's probably in between. Something that 
>>> explains the patches and enough about how they fit into a larger 
>>> system that we can reason about the context.
>>
>> Maybe a purpose would be more useful to understand your request? I 
>> assume you meant “I’d like us to understand what we’re signing up to 
>> maintain, and why it’s useful to do things this way”. In particular, 
>> if there’s undue burden in a particular component, and the code could 
>> be changed to work differently with less support overhead, then we’d 
>> want to identify this fact ahead of time.
>>
>> I’m guessing at what Hal is asking, LMK if that’s not what you had in 
>> mind!
>
>
> Yes. To understand how all of the pieces fit together to enable 
> support for incremental compilation of C++ code. Once everything is in 
> place, if I wanted to use the infrastructure to do some kind of 
> incremental compilation of C++, what would I do? And what do the set 
> of patches aim to do to get us there?
>

   It took us a while... We have published a blog post on interactive 
C++ with cling at the LLVM blog. Direct link 
<https://blog.llvm.org/posts/2020-11-17-interactive-cpp-with-cling/>. I 
realize this touches only on some aspects of interactive C++ and cling. 
We have a longer document with more information but I am not yet 
comfortable in giving a public pointer to it. If you are interested in 
that document please ping me off-list and I will give you access.


>  -Hal
>
>
>>
>>
>>>  -Hal
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>> On Jul 9, 2020, at 7:25 PM, Hal Finkel via cfe-dev 
>>>>>> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>>>>>
>>>>>> I think that it would be great to have infrastructure for 
>>>>>> incremental C++ compilation, supporting interactive use, 
>>>>>> just-in-time compilation, and so on. I think that the best way to 
>>>>>> deal with the patches, etc., as well as IncrementalAction, is to 
>>>>>> first send an RFC explaining the overall design.
>>>>>>
>>>>>> -Hal
>>>>>>
>>>>>> On 7/9/20 3:46 PM, Vassil Vassilev via cfe-dev wrote:
>>>>>>> Motivation
>>>>>>> ===
>>>>>>>
>>>>>>> Over the last decade we have developed an interactive, 
>>>>>>> interpretative C++ (aka REPL) as part of the high-energy physics 
>>>>>>> (HEP) data analysis project -- ROOT [1-2]. We invested a 
>>>>>>> significant effort to replace the CINT C++ interpreter with a 
>>>>>>> newly implemented REPL based on llvm -- cling [3]. The cling 
>>>>>>> infrastructure is a core component of the data analysis 
>>>>>>> framework of ROOT and runs in production for approximately 5 years.
>>>>>>>
>>>>>>> Cling is also  a standalone tool, which has a growing community 
>>>>>>> outside of our field. Cling’s user community includes users in 
>>>>>>> finance, biology and in a few companies with proprietary 
>>>>>>> software. For example, there is a xeus-cling jupyter kernel [4]. 
>>>>>>> One of the major challenges we face to foster that community is  
>>>>>>> our cling-related patches in llvm and clang forks. The benefits 
>>>>>>> of using the LLVM community standards for code reviews, release 
>>>>>>> cycles and integration has been mentioned a number of times by 
>>>>>>> our "external" users.
>>>>>>>
>>>>>>> Last year we were awarded an NSF grant to improve cling's 
>>>>>>> sustainability and make it a standalone tool. We thank the LLVM 
>>>>>>> Foundation Board for supporting us with a non-binding letter of 
>>>>>>> collaboration which was essential for getting this grant.
>>>>>>>
>>>>>>>
>>>>>>> Background
>>>>>>> ===
>>>>>>>
>>>>>>> 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 [5]. Then code is lowered into llvm IR and run 
>>>>>>> by the llvm jit. Cling has implemented some language 
>>>>>>> "extensions" such as execution statements on the global scope 
>>>>>>> and error recovery. Cling is in the core of HEP -- 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.
>>>>>>>
>>>>>>>
>>>>>>> Plans
>>>>>>> ===
>>>>>>>
>>>>>>> The project foresees three main directions -- move parts of 
>>>>>>> cling upstream along with the clang and llvm features that 
>>>>>>> enable them; extend and generalize the language interoperability 
>>>>>>> layer around cling; and extend and generalize the OpenCL/CUDA 
>>>>>>> support in cling. We are at the early stages of the project and 
>>>>>>> this email intends to be an RFC for the first part -- 
>>>>>>> upstreaming parts of cling. Please do share your thoughts on the 
>>>>>>> rest, too.
>>>>>>>
>>>>>>>
>>>>>>> Moving Parts of Cling Upstream
>>>>>>> ---
>>>>>>>
>>>>>>> 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.  A possible way forward would be to implement 
>>>>>>> a clang::IncrementalAction as a starting point. This way we 
>>>>>>> should be able to reduce the amount of setup necessary to use 
>>>>>>> the incremental infrastructure in clang. However, this will be a 
>>>>>>> bit of a testing challenge -- cling lives downstream and some of 
>>>>>>> the new code may be impossible to pick straight away and use. 
>>>>>>> Building a mainline example tool such as clang-repl which gives 
>>>>>>> us a way to test that incremental case or repurpose the already 
>>>>>>> existing clang-interpreter may  be able to address the issue. 
>>>>>>> The major risk of the task is avoiding code in the clang 
>>>>>>> mainline which is untested by its HEP production environment.
>>>>>>> There are several other types of patches to the ROOT fork of 
>>>>>>> Clang, including ones  in the context of performance,towards  
>>>>>>> C++ modules support (D41416), and storage (does not have a patch 
>>>>>>> yet but has an open projects entry and somebody working on it). 
>>>>>>> These patches can be considered in parallel independently on the 
>>>>>>> rest.
>>>>>>>
>>>>>>> Extend and Generalize the Language Interoperability Layer Around 
>>>>>>> Cling
>>>>>>> ---
>>>>>>>
>>>>>>> HEP has extensive experience with on-demand python 
>>>>>>> interoperability using cppyy[6], which is built around the type 
>>>>>>> information provided by cling. Unlike tools with custom parsers 
>>>>>>> such as swig and sip and tools built on top of C-APIs such as 
>>>>>>> boost.python and pybind11, cling can provide information about 
>>>>>>> memory management patterns (eg refcounting) and instantiate 
>>>>>>> templates on the fly.We feel that functionality may not be of 
>>>>>>> general interest to the llvm community but we will prepare 
>>>>>>> another RFC and send it here later on to gather feedback.
>>>>>>>
>>>>>>>
>>>>>>> Extend and Generalize the OpenCL/CUDA Support in Cling
>>>>>>> ---
>>>>>>>
>>>>>>> Cling can incrementally compile CUDA code [7-8] allowing easier 
>>>>>>> set up and enabling some interesting use cases. There are a 
>>>>>>> number of planned improvements including talking to HIP [9] and 
>>>>>>> SYCL to support more hardware architectures.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The primary focus of our work is to upstreaming functionality 
>>>>>>> required to build an incremental compiler and rework cling build 
>>>>>>> against vanilla clang and llvm. The last two points are to give 
>>>>>>> the scope of the work which we will be doing the next 2-3 years. 
>>>>>>> We will send here RFCs for both of them to trigger technical 
>>>>>>> discussion if there is interest in pursuing this direction.
>>>>>>>
>>>>>>>
>>>>>>> Collaboration
>>>>>>> ===
>>>>>>>
>>>>>>> Open source development nowadays relies on reviewers. LLVM is no 
>>>>>>> different and we will probably disturb a good number of people 
>>>>>>> in the community ;)We would like to invite anybody interested in 
>>>>>>> joining our incremental C++ activities to our open every second 
>>>>>>> week calls. Announcements will be done via google group: 
>>>>>>> compiler-research-announce 
>>>>>>> (https://groups.google.com/g/compiler-research-announce 
>>>>>>> <https://groups.google.com/g/compiler-research-announce>).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Many thanks!
>>>>>>>
>>>>>>>
>>>>>>> David & Vassil
>>>>>>>
>>>>>>> References
>>>>>>> ===
>>>>>>> [1] ROOT GitHub https://github.com/root-project/root 
>>>>>>> <https://github.com/root-project/root>
>>>>>>> [2] ROOT https://root.cern <https://root.cern>
>>>>>>> [3] Cling https://github.com/root-project/cling 
>>>>>>> <https://github.com/root-project/cling>
>>>>>>> [4] Xeus-Cling 
>>>>>>> https://blog.jupyter.org/xeus-is-now-a-jupyter-subproject-c4ec5a1bf30b 
>>>>>>> <https://blog.jupyter.org/xeus-is-now-a-jupyter-subproject-c4ec5a1bf30b>
>>>>>>> [5] Cling – The New Interactive Interpreter for ROOT 6, 
>>>>>>> https://iopscience.iop.org/article/10.1088/1742-6596/396/5/052071 
>>>>>>> <https://iopscience.iop.org/article/10.1088/1742-6596/396/5/052071>
>>>>>>> [6] High-performance Python-C++ bindings with PyPy and Cling, 
>>>>>>> https://dl.acm.org/doi/10.5555/3019083.3019087 
>>>>>>> <https://dl.acm.org/doi/10.5555/3019083.3019087>
>>>>>>> [7] 
>>>>>>> https://indico.cern.ch/event/697389/contributions/3085538/attachments/1712698/2761717/2018_09_10_cling_CUDA.pdf 
>>>>>>> <https://indico.cern.ch/event/697389/contributions/3085538/attachments/1712698/2761717/2018_09_10_cling_CUDA.pdf>
>>>>>>> [8] CUDA C++ in Jupyter: Adding CUDA Runtime Support to Cling', 
>>>>>>> https://zenodo.org/record/3713753#.Xu8jqvJRXxU 
>>>>>>> <https://zenodo.org/record/3713753#.Xu8jqvJRXxU>
>>>>>>> [9] HIP Programming Guide 
>>>>>>> https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html 
>>>>>>> <https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cfe-dev mailing list
>>>>>>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>>> --
>>>>>> Hal Finkel
>>>>>> Lead, Compiler Technology and Programming Languages
>>>>>> Leadership Computing Facility
>>>>>> Argonne National Laboratory
>>>>>>
>>>>>> _______________________________________________
>>>>>> cfe-dev mailing list
>>>>>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>
>>>>
>>> --
>>> Hal Finkel
>>> Lead, Compiler Technology and Programming Languages
>>> Leadership Computing Facility
>>> Argonne National Laboratory
>>
> -- 
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20201201/6755710d/attachment-0001.html>

More information about the cfe-dev mailing list