<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Richard,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 7/10/20 11:10 PM, Richard Smith
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAOfiQqmSrf5a6dXptULbWcPnzZrgULo0FT6CEdOr9JbfSXZsTg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hi Vassil,
<div><br>
</div>
<div>This is a very exciting proposal that I can imagine
bringing important benefits to the existing cling users and
also to the clang user and developer community. Thank you for
all the work you and your team have done on cling so far and
for offering to bring that work under the LLVM umbrella!</div>
<div><br>
</div>
<div>Are you imagining cling being part of the clang repository,
or a separate LLVM subproject (with only the changes necessary
to support cling-style uses of the clang libraries added to
the clang tree)?</div>
</div>
</blockquote>
<p><br>
</p>
<p> Good question. In principle cling was developed with the idea
to become a separate LLVM subproject. Although I'd easily see it
fit in clang/tools/.<br>
</p>
<p><br>
</p>
<p> Nominally, cling has "high-energy physics"-specific features
such as the so called 'meta commands'. For example, `[cling] .L
some_file` would try to load a library called some_file.so and if
it does not exist, try #include-ing a header with that name;
`[cling] .x script.C` includes script.C and calls a function named
`script`. I can imagine that broader community may not like/use
that. If we start trimming down features like that then it won't
really be cling anymore. Here is what I would imagine as a way
forward:</p>
<p> 1. Land as many cling/"incremental compilation"-related patches
as we can in clang.<br>
2. Build a simple tool, let's use a strawman name -- clang-repl,
which only does the basics. For example, one can feed it
incremental C++ and execute it.<br>
3. Rework cling to use that infrastructure -- ideally,
implementing it's specific meta commands and other domain-specific
features such as dynamic scopes.</p>
<p> We could move any of the cling features which the broader
community finds useful closer to clang. For the moment I am being
conservative as this will also give us the opportunity to rethink
some of the features.</p>
<p> The hard part is what lives where. First bullet point is clear.
The second -- not so much. Clang has a clang-interpreter in its
examples folder and it looks a little unmaintained. Maybe we can
start repurposing that to match 2.</p>
<p> As for cling itself there are some challenges we should try to
solve. Our community lives downstream (currently llvm-5) and a
straight-forward llvm upgrade + bugfixing takes around 3 months
due to the nature of our software stacks. It would be a
non-trivial task to move the cling-based development in llvm
upstream. My worry is that HEP-cling will soon depart from
LLVM-cling if we don't get both communities on the same codebase
(we have experienced such a problem with the getFullyQualified*
interfaces). I am hoping that a middleman, such as clang-repl, can
help. When we move parts of cling in clang we will develop and
test the required functionality using clang-repl. This way users
will enjoy cling-like experience and when cling upgrades its llvm
its codebase will become smaller in size.</p>
<p> Am I making sense?<br>
</p>
<br>
<blockquote type="cite"
cite="mid:CAOfiQqmSrf5a6dXptULbWcPnzZrgULo0FT6CEdOr9JbfSXZsTg@mail.gmail.com"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, 9 Jul 2020 at 13:46,
Vassil Vassilev via cfe-dev <<a
href="mailto:cfe-dev@lists.llvm.org" moz-do-not-send="true">cfe-dev@lists.llvm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Motivation<br>
===<br>
<br>
Over the last decade we have developed an interactive,
interpretative <br>
C++ (aka REPL) as part of the high-energy physics (HEP) data
analysis <br>
project -- ROOT [1-2]. We invested a significant effort to
replace the <br>
CINT C++ interpreter with a newly implemented REPL based on
llvm -- <br>
cling [3]. The cling infrastructure is a core component of the
data <br>
analysis framework of ROOT and runs in production for
approximately 5 <br>
years.<br>
<br>
Cling is also a standalone tool, which has a growing
community outside <br>
of our field. Cling’s user community includes users in
finance, biology <br>
and in a few companies with proprietary software. For example,
there is <br>
a xeus-cling jupyter kernel [4]. One of the major challenges
we face to <br>
foster that community is our cling-related patches in llvm
and clang <br>
forks. The benefits of using the LLVM community standards for
code <br>
reviews, release cycles and integration has been mentioned a
number of <br>
times by our "external" users.<br>
<br>
Last year we were awarded an NSF grant to improve cling's
sustainability <br>
and make it a standalone tool. We thank the LLVM Foundation
Board for <br>
supporting us with a non-binding letter of collaboration which
was <br>
essential for getting this grant.<br>
<br>
<br>
Background<br>
===<br>
<br>
Cling is a C++ interpreter built on top of clang and llvm. In
a <br>
nutshell, it uses clang's incremental compilation facilities
to process <br>
code chunk-by-chunk by assuming an ever-growing translation
unit [5]. <br>
Then code is lowered into llvm IR and run by the llvm jit.
Cling has <br>
implemented some language "extensions" such as execution
statements on <br>
the global scope and error recovery. Cling is in the core of
HEP -- it <br>
is heavily used during data analysis of exabytes of particle
physics <br>
data coming from the Large Hadron Collider (LHC) and other
particle <br>
physics experiments.<br>
<br>
<br>
Plans<br>
===<br>
<br>
The project foresees three main directions -- move parts of
cling <br>
upstream along with the clang and llvm features that enable
them; extend <br>
and generalize the language interoperability layer around
cling; and <br>
extend and generalize the OpenCL/CUDA support in cling. We are
at the <br>
early stages of the project and this email intends to be an
RFC for the <br>
first part -- upstreaming parts of cling. Please do share your
thoughts <br>
on the rest, too.<br>
<br>
<br>
Moving Parts of Cling Upstream<br>
---<br>
<br>
Over the years we have slowly moved some patches upstream.
However we <br>
still have around 100 patches in the clang fork. Most of them
are in the <br>
context of extending the incremental compilation support for
clang. The <br>
incremental compilation poses some challenges in the clang <br>
infrastructure. For example, we need to tune CodeGen to work
with <br>
multiple llvm::Module instances, and finalize per each <br>
end-of-translation unit (we have multiple of them). Other
changes <br>
include small adjustments in the FileManager's caching
mechanism, and <br>
bug fixes in the SourceManager (code which can be reached
mostly from <br>
within our setup). One conclusion we can draw from our
research is that <br>
the clang infrastructure fits amazingly well to something
which was not <br>
its main use case. The grand total of our diffs against
clang-9 is: `62 <br>
files changed, 1294 insertions(+), 231 deletions(-)`. Cling is
currently <br>
being upgraded from llvm-5 to llvm-9.<br>
<br>
A major weakness of cling's infrastructure is that it does not
work with <br>
the clang Action infrastructure due to the lack of an <br>
IncrementalAction. A possible way forward would be to
implement a <br>
clang::IncrementalAction as a starting point. This way we
should be able <br>
to reduce the amount of setup necessary to use the incremental
<br>
infrastructure in clang. However, this will be a bit of a
testing <br>
challenge -- cling lives downstream and some of the new code
may be <br>
impossible to pick straight away and use. Building a mainline
example <br>
tool such as clang-repl which gives us a way to test that
incremental <br>
case or repurpose the already existing clang-interpreter may
be able to <br>
address the issue. The major risk of the task is avoiding code
in the <br>
clang mainline which is untested by its HEP production
environment.<br>
There are several other types of patches to the ROOT fork of
Clang, <br>
including ones in the context of performance,towards C++
modules <br>
support (D41416), and storage (does not have a patch yet but
has an open <br>
projects entry and somebody working on it). These patches can
be <br>
considered in parallel independently on the rest.<br>
<br>
Extend and Generalize the Language Interoperability Layer
Around Cling<br>
---<br>
<br>
HEP has extensive experience with on-demand python
interoperability <br>
using cppyy[6], which is built around the type information
provided by <br>
cling. Unlike tools with custom parsers such as swig and sip
and tools <br>
built on top of C-APIs such as boost.python and pybind11,
cling can <br>
provide information about memory management patterns (eg
refcounting) <br>
and instantiate templates on the fly.We feel that
functionality may not <br>
be of general interest to the llvm community but we will
prepare another <br>
RFC and send it here later on to gather feedback.<br>
<br>
<br>
Extend and Generalize the OpenCL/CUDA Support in Cling<br>
---<br>
<br>
Cling can incrementally compile CUDA code [7-8] allowing
easier set up <br>
and enabling some interesting use cases. There are a number of
planned <br>
improvements including talking to HIP [9] and SYCL to support
more <br>
hardware architectures.<br>
<br>
<br>
<br>
The primary focus of our work is to upstreaming functionality
required <br>
to build an incremental compiler and rework cling build
against vanilla <br>
clang and llvm. The last two points are to give the scope of
the work <br>
which we will be doing the next 2-3 years. We will send here
RFCs for <br>
both of them to trigger technical discussion if there is
interest in <br>
pursuing this direction.<br>
<br>
<br>
Collaboration<br>
===<br>
<br>
Open source development nowadays relies on reviewers. LLVM is
no <br>
different and we will probably disturb a good number of people
in the <br>
community ;)We would like to invite anybody interested in
joining our <br>
incremental C++ activities to our open every second week
calls. <br>
Announcements will be done via google group:
compiler-research-announce <br>
(<a
href="https://groups.google.com/g/compiler-research-announce"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://groups.google.com/g/compiler-research-announce</a>).<br>
<br>
<br>
<br>
Many thanks!<br>
<br>
<br>
David & Vassil<br>
<br>
References<br>
===<br>
[1] ROOT GitHub <a
href="https://github.com/root-project/root" rel="noreferrer"
target="_blank" moz-do-not-send="true">https://github.com/root-project/root</a><br>
[2] ROOT <a href="https://root.cern" rel="noreferrer"
target="_blank" moz-do-not-send="true">https://root.cern</a><br>
[3] Cling <a href="https://github.com/root-project/cling"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/root-project/cling</a><br>
[4] Xeus-Cling <br>
<a
href="https://blog.jupyter.org/xeus-is-now-a-jupyter-subproject-c4ec5a1bf30b"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://blog.jupyter.org/xeus-is-now-a-jupyter-subproject-c4ec5a1bf30b</a><br>
[5] Cling – The New Interactive Interpreter for ROOT 6, <br>
<a
href="https://iopscience.iop.org/article/10.1088/1742-6596/396/5/052071"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://iopscience.iop.org/article/10.1088/1742-6596/396/5/052071</a><br>
[6] High-performance Python-C++ bindings with PyPy and Cling,
<br>
<a href="https://dl.acm.org/doi/10.5555/3019083.3019087"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://dl.acm.org/doi/10.5555/3019083.3019087</a><br>
[7] <br>
<a
href="https://indico.cern.ch/event/697389/contributions/3085538/attachments/1712698/2761717/2018_09_10_cling_CUDA.pdf"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://indico.cern.ch/event/697389/contributions/3085538/attachments/1712698/2761717/2018_09_10_cling_CUDA.pdf</a><br>
[8] CUDA C++ in Jupyter: Adding CUDA Runtime Support to
Cling', <br>
<a href="https://zenodo.org/record/3713753#.Xu8jqvJRXxU"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://zenodo.org/record/3713753#.Xu8jqvJRXxU</a><br>
[9] HIP Programming Guide <br>
<a
href="https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html</a><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">cfe-dev@lists.llvm.org</a><br>
<a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>