|
|
|
|
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).
Many thanks!
David & Vassil
References
===
[1] ROOT GitHub https://github.com/root-project/root[2] ROOT https://root.cern[3] Cling https://github.com/root-project/cling[4] Xeus-Cling
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[6] High-performance Python-C++ bindings with PyPy and Cling,
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[8] CUDA C++ in Jupyter: Adding CUDA Runtime Support to Cling',
https://zenodo.org/record/3713753#.Xu8jqvJRXxU[9] HIP Programming Guide
https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
Hi Vassil,
Thank you for the very detailed email. I am not directly involved in clang-dev anymore, but I would love to see Cling get folded back into mainline LLVM development. The Cling project is really cool and I think that it doesn’t get the recognition it deserves,
-Chris
> On Jul 9, 2020, at 1:46 PM, Vassil Vassilev via cfe-dev < [hidden email]> 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).
>
>
>
> Many thanks!
>
>
> David & Vassil
>
> References
> ===
> [1] ROOT GitHub https://github.com/root-project/root> [2] ROOT https://root.cern> [3] Cling https://github.com/root-project/cling> [4] Xeus-Cling 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> [6] High-performance Python-C++ bindings with PyPy and Cling, 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> [8] CUDA C++ in Jupyter: Adding CUDA Runtime Support to Cling', https://zenodo.org/record/3713753#.Xu8jqvJRXxU> [9] HIP Programming Guide https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by David Blaikie via cfe-dev
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).
>
>
>
> Many thanks!
>
>
> David & Vassil
>
> References
> ===
> [1] ROOT GitHub https://github.com/root-project/root> [2] ROOT https://root.cern> [3] Cling https://github.com/root-project/cling> [4] Xeus-Cling
> 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> [6] High-performance Python-C++ bindings with PyPy and Cling,
> 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> [8] CUDA C++ in Jupyter: Adding CUDA Runtime Support to Cling',
> https://zenodo.org/record/3713753#.Xu8jqvJRXxU> [9] HIP Programming Guide
> https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
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.
> On Jul 9, 2020, at 7:25 PM, Hal Finkel via cfe-dev < [hidden email]> 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).
>>
>>
>>
>> Many thanks!
>>
>>
>> David & Vassil
>>
>> References
>> ===
>> [1] ROOT GitHub https://github.com/root-project/root>> [2] ROOT https://root.cern>> [3] Cling https://github.com/root-project/cling>> [4] Xeus-Cling 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>> [6] High-performance Python-C++ bindings with PyPy and Cling, 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>> [8] CUDA C++ in Jupyter: Adding CUDA Runtime Support to Cling', https://zenodo.org/record/3713753#.Xu8jqvJRXxU>> [9] HIP Programming Guide https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> 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
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
I do not know enough about cling, but I like what you describe very much, am particularly intrigued about how your approach could also be appropriated to do ahead-of-time constexpr metaprogramming as well, which also involves incrementally adding declarations to the translation unit.
Dave
> On Jul 9, 2020, at 11:43 PM, JF Bastien via cfe-dev < [hidden email]> 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.
>
>
>> On Jul 9, 2020, at 7:25 PM, Hal Finkel via cfe-dev < [hidden email]> 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).
>>>
>>>
>>>
>>> Many thanks!
>>>
>>>
>>> David & Vassil
>>>
>>> References
>>> ===
>>> [1] ROOT GitHub https://github.com/root-project/root>>> [2] ROOT https://root.cern>>> [3] Cling https://github.com/root-project/cling>>> [4] Xeus-Cling 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>>> [6] High-performance Python-C++ bindings with PyPy and Cling, 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>>> [8] CUDA C++ in Jupyter: Adding CUDA Runtime Support to Cling', https://zenodo.org/record/3713753#.Xu8jqvJRXxU>>> [9] HIP Programming Guide https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> [hidden email]
>>> 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
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by David Blaikie via cfe-dev
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.
>
>
>> On Jul 9, 2020, at 7:25 PM, Hal Finkel via cfe-dev < [hidden email]> 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).
>>>
>>>
>>>
>>> Many thanks!
>>>
>>>
>>> David & Vassil
>>>
>>> References
>>> ===
>>> [1] ROOT GitHub https://github.com/root-project/root>>> [2] ROOT https://root.cern>>> [3] Cling https://github.com/root-project/cling>>> [4] Xeus-Cling 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>>> [6] High-performance Python-C++ bindings with PyPy and Cling, 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>>> [8] CUDA C++ in Jupyter: Adding CUDA Runtime Support to Cling', https://zenodo.org/record/3713753#.Xu8jqvJRXxU>>> [9] HIP Programming Guide https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> [hidden email]
>>> 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
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by David Blaikie via cfe-dev
On 7/10/20 8:09 PM, David Rector wrote:
> I do not know enough about cling, but I like what you describe very much, am particularly intrigued about how your approach could also be appropriated to do ahead-of-time constexpr metaprogramming as well, which also involves incrementally adding declarations to the translation unit.
Wow, I do not think we have thought of something like that. Cling
keeps a single clang compiler instance in memory and each new input just
"adds" to it -- nothing fancy on the frontend. The more interesting part
happens in CodeGen where we produce multiple llvm::Modules. Maybe some
parts from that could be reused to pursue the direction you are
intrigued about.
>
> Dave
>
>> On Jul 9, 2020, at 11:43 PM, JF Bastien via cfe-dev < [hidden email]> 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.
>>
>>
>>> On Jul 9, 2020, at 7:25 PM, Hal Finkel via cfe-dev < [hidden email]> 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).
>>>>
>>>>
>>>>
>>>> Many thanks!
>>>>
>>>>
>>>> David & Vassil
>>>>
>>>> References
>>>> ===
>>>> [1] ROOT GitHub https://github.com/root-project/root>>>> [2] ROOT https://root.cern>>>> [3] Cling https://github.com/root-project/cling>>>> [4] Xeus-Cling 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>>>> [6] High-performance Python-C++ bindings with PyPy and Cling, 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>>>> [8] CUDA C++ in Jupyter: Adding CUDA Runtime Support to Cling', https://zenodo.org/record/3713753#.Xu8jqvJRXxU>>>> [9] HIP Programming Guide https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by David Blaikie via cfe-dev
Hi Vassil,
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!
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)? On Thu, 9 Jul 2020 at 13:46, Vassil Vassilev via cfe-dev < [hidden email]> 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).
Many thanks!
David & Vassil
References
===
[1] ROOT GitHub https://github.com/root-project/root
[2] ROOT https://root.cern
[3] Cling https://github.com/root-project/cling
[4] Xeus-Cling
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
[6] High-performance Python-C++ bindings with PyPy and Cling,
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
[8] CUDA C++ in Jupyter: Adding CUDA Runtime Support to Cling',
https://zenodo.org/record/3713753#.Xu8jqvJRXxU
[9] HIP Programming Guide
https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by David Blaikie via cfe-dev
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.
-Hal
>
>
>>
>>
>>> On Jul 9, 2020, at 7:25 PM, Hal Finkel via cfe-dev
>>> < [hidden email]> 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).
>>>>
>>>>
>>>>
>>>> Many thanks!
>>>>
>>>>
>>>> David & Vassil
>>>>
>>>> References
>>>> ===
>>>> [1] ROOT GitHub https://github.com/root-project/root>>>> [2] ROOT https://root.cern>>>> [3] Cling https://github.com/root-project/cling>>>> [4] Xeus-Cling
>>>> 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>>>> [6] High-performance Python-C++ bindings with PyPy and Cling,
>>>> 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>>>> [8] CUDA C++ in Jupyter: Adding CUDA Runtime Support to Cling',
>>>> https://zenodo.org/record/3713753#.Xu8jqvJRXxU>>>> [9] HIP Programming Guide
>>>> https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html>>>>
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> [hidden email]
>>>> 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
>>> [hidden email]
>>> 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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by David Blaikie via cfe-dev
Hi Richard,
On 7/10/20 11:10 PM, Richard Smith
wrote:
Hi Vassil,
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!
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)?
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/.
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:
1. Land as many cling/"incremental compilation"-related patches
as we can in clang.
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.
3. Rework cling to use that infrastructure -- ideally,
implementing it's specific meta commands and other domain-specific
features such as dynamic scopes.
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.
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.
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.
Am I making sense?
On Thu, 9 Jul 2020 at 13:46,
Vassil Vassilev via cfe-dev < [hidden email]>
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).
Many thanks!
David & Vassil
References
===
[1] ROOT GitHub https://github.com/root-project/root
[2] ROOT https://root.cern
[3] Cling https://github.com/root-project/cling
[4] Xeus-Cling
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
[6] High-performance Python-C++ bindings with PyPy and Cling,
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
[8] CUDA C++ in Jupyter: Adding CUDA Runtime Support to
Cling',
https://zenodo.org/record/3713753#.Xu8jqvJRXxU
[9] HIP Programming Guide
https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by David Blaikie via cfe-dev
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!
-Hal
On Jul 9, 2020, at 7:25 PM, Hal Finkel via cfe-dev <[hidden email]> 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).
Many thanks!
David & Vassil
References
===
[1] ROOT GitHub https://github.com/root-project/root
[2] ROOT https://root.cern
[3] Cling https://github.com/root-project/cling
[4] Xeus-Cling 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
[6] High-performance Python-C++ bindings with PyPy and Cling, 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
[8] CUDA C++ in Jupyter: Adding CUDA Runtime Support to Cling', https://zenodo.org/record/3713753#.Xu8jqvJRXxU
[9] HIP Programming Guide https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html
_______________________________________________
cfe-dev mailing list
[hidden email]
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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-- Hal FinkelLead, Compiler Technology and Programming LanguagesLeadership Computing FacilityArgonne National Laboratory
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
On 7/11/20 12:00 AM, JF Bastien 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!
Thanks for the clarification. Sure, we can do that I was hoping
that to be part of the particular patch review process. Also, if
that's the preference, we can write a short-ish doc with some
patch classification and explanations. Btw, I've uploaded the
cling-specific patches against the clang-9 codebase:
https://github.com/vgvassilev/clang/commits/upgrade_llvm90 Our
production LLVM-5 is patch free, I had to introduce some patches
in llvm-9 but thanks to Lang I know how to get rid of them.
-Hal
On Jul 9, 2020, at 7:25
PM, Hal Finkel via cfe-dev <[hidden email]>
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).
Many thanks!
David & Vassil
References
===
[1] ROOT GitHub https://github.com/root-project/root
[2] ROOT https://root.cern
[3] Cling https://github.com/root-project/cling
[4] Xeus-Cling 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
[6] High-performance Python-C++ bindings with PyPy
and Cling, 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
[8] CUDA C++ in Jupyter: Adding CUDA Runtime Support
to Cling', https://zenodo.org/record/3713753#.Xu8jqvJRXxU
[9] HIP Programming Guide https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html
_______________________________________________
cfe-dev mailing list
[hidden email]
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
[hidden email]
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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by David Blaikie via cfe-dev
On 7/10/20 4:00 PM, JF Bastien 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?
-Hal
-Hal
On Jul 9, 2020, at 7:25
PM, Hal Finkel via cfe-dev <[hidden email]>
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).
Many thanks!
David & Vassil
References
===
[1] ROOT GitHub https://github.com/root-project/root
[2] ROOT https://root.cern
[3] Cling https://github.com/root-project/cling
[4] Xeus-Cling 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
[6] High-performance Python-C++ bindings with PyPy
and Cling, 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
[8] CUDA C++ in Jupyter: Adding CUDA Runtime Support
to Cling', https://zenodo.org/record/3713753#.Xu8jqvJRXxU
[9] HIP Programming Guide https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html
_______________________________________________
cfe-dev mailing list
[hidden email]
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
[hidden email]
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
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by David Blaikie via cfe-dev
On Fri, 10 Jul 2020 at 13:59, Vassil Vassilev via cfe-dev < [hidden email]> wrote:
Hi Richard,
On 7/10/20 11:10 PM, Richard Smith
wrote:
Hi Vassil,
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!
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)?
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/.
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:
1. Land as many cling/"incremental compilation"-related patches
as we can in clang.
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.
3. Rework cling to use that infrastructure -- ideally,
implementing it's specific meta commands and other domain-specific
features such as dynamic scopes.
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.
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.
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.
Am I making sense? Yes, the above all makes sense to me. I agree that there should be only one thing named 'cling', and that it should broadly have the feature set that current 'cling' has. I think there are a couple of ways we can get there while still providing the a minimalist interpreter to a broader audience: either we can build a simpler clang-interpreter and a more advanced cling binary from a common set of libraries, or we could produce a configurable binary that's able to serve both rules depending on configuration or a plugin or scripting system.
One other thing I think we should consider: there will be substantial overlap between the incremental compilation, code generation, REPL, etc. of cling and that of lldb. For the initial integration of cling into LLVM, there's probably not much we can do about that, but it would seem beneficial for both cling and lldb if common parts could be shared where possible. As an extreme example, if we could fully unify the projects to the point where a user could switch into an 'lldb mode' in the middle of a cling session to do step-by-step debugging of code entered into the REPL, that would seem like an incredibly useful feature. Perhaps there's some common set of base functionality that can be factored out of lldb and cling and unified. It would likely be a good idea to start talking to the lldb folks about that early, in case it guides your work porting cling to trunk.
On Thu, 9 Jul 2020 at 13:46,
Vassil Vassilev via cfe-dev < [hidden email]>
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).
Many thanks!
David & Vassil
References
===
[1] ROOT GitHub https://github.com/root-project/root
[2] ROOT https://root.cern
[3] Cling https://github.com/root-project/cling
[4] Xeus-Cling
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
[6] High-performance Python-C++ bindings with PyPy and Cling,
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
[8] CUDA C++ in Jupyter: Adding CUDA Runtime Support to
Cling',
https://zenodo.org/record/3713753#.Xu8jqvJRXxU
[9] HIP Programming Guide
https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
On Jul 10, 2020, at 2:58 PM, Richard Smith via cfe-dev < [hidden email]> wrote:
One other thing I think we should consider: there will be substantial overlap between the incremental compilation, code generation, REPL, etc. of cling and that of lldb. For the initial integration of cling into LLVM, there's probably not much we can do about that, but it would seem beneficial for both cling and lldb if common parts could be shared where possible. As an extreme example, if we could fully unify the projects to the point where a user could switch into an 'lldb mode' in the middle of a cling session to do step-by-step debugging of code entered into the REPL, that would seem like an incredibly useful feature. Perhaps there's some common set of base functionality that can be factored out of lldb and cling and unified. It would likely be a good idea to start talking to the lldb folks about that early, in case it guides your work porting cling to trunk.
This is a really good point. I’m not sure how much awareness there is on this list, but the Swift REPL is worth looking at if you haven’t seen it. It is built on/in LLDB, and provides some really nice user experience features.
For example, if you evaluate an expression that crashes, you get a full backtrace and integrated debugger experience. There are a couple of examples on this page, and more detailed info online:
-Chris _______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by David Blaikie via cfe-dev
On 7/11/20 12:58 AM, Richard Smith
wrote:
On Fri, 10 Jul 2020 at 13:59, Vassil Vassilev via
cfe-dev < [hidden email]> wrote:
Hi Richard,
On 7/10/20 11:10 PM, Richard Smith wrote:
Hi Vassil,
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!
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)?
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/.
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:
1. Land as many cling/"incremental
compilation"-related patches as we can in clang.
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.
3. Rework cling to use that infrastructure -- ideally,
implementing it's specific meta commands and other
domain-specific features such as dynamic scopes.
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.
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.
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.
Am I making sense?
Yes, the above all makes sense to me. I agree that there
should be only one thing named 'cling', and that it should
broadly have the feature set that current 'cling' has. I
think there are a couple of ways we can get there while
still providing the a minimalist interpreter to a broader
audience: either we can build a simpler clang-interpreter
and a more advanced cling binary from a common set of
libraries, or we could produce a configurable binary that's
able to serve both rules depending on configuration or a
plugin or scripting system.
Good point. We could make it extendable, and actually that
should be a design goal. The question how exactly is not very
clear to me. Can you elaborate on what you had in mind as
configuration or scripting system (plugin system I think I know
what you meant). I will give an example with 3 distinct features
in cling which we have implemented over the years and had
different requirements:
* AST-based
automatic differentiation with the clad
library -- here we essentially extend cling's runtime by
providing a `clad::differentiate`, `clad::gradient`,
`clad::hessian` and `clad::jacobian` primitives. Each primitive is
a specially annotated wrapper over a function, say `double
pow2(double x) { return x*x; }; auto pow2dx =
clad::differentiate(pow2,/*wrt*/0);`. Here we let clang build a
valid AST and the plugin creates the first order derivative and
swaps the DeclRefExpr just before codegen so that we call the
derivative instead. This is achievable by the current clang plugin
system ( a bit problematic on windows as clang plugins do not work
there ).
* Language extensions which require Sema support -- we have a
legacy feature which should define a variable on the prompt if not
defined (something like implicit auto) `cling[] i = 13;` should be
translated into `cling[] auto i = 13;` if I is undefined. We solve
that by adding some last resort lookup callback which marks `i` of
dependent type so that we can produce an AST which we can later
'fix'.
* Language extensions which require delayed lookup rules (aka
dynamic scope) -- ROOT has an I/O system bound to cling people can
write:`if (TFile::Open("file_that_has_hist_cpp_obj.root"))
hist->Draw();`. Here we use the approach from the previous
bullet and synthesize `if
(TFile::Open("file_that_has_hist_cpp_obj.root"))
eval<void>("hist->Draw()", /*escape some context*/...);`.
The implementation of these three features can be considered as
possible with current clang. The issue is that it seems more like
hacking clang rather than extending it. If we can come up with a
sound way of implementing these features that would be awesome.
One other thing I think we should consider: there will be
substantial overlap between the incremental compilation,
code generation, REPL, etc. of cling and that of lldb.
I would love to hear opinions from the lldb folks. We have
chatted number of times and I have looked at how they do it. I
think lldb spawns (used to spawn last time I looked) a compiler
instance per input line. That is not acceptable for cling due to
its high-performance requirements. Most of the issues that need
solving for lldb comes from materializing debug information to
AST. LLDB folks, correct me if I am wrong.
That being said doesn't mean that we should not aim for
centralizing the incremental compilation for both projects. We
should but may be challenging because of the different focus which
defines project priorities.
For the initial integration of cling into LLVM, there's
probably not much we can do about that, but it would seem
beneficial for both cling and lldb if common parts could be
shared where possible. As an extreme example, if we could
fully unify the projects to the point where a user could
switch into an 'lldb mode' in the middle of a cling session
to do step-by-step debugging of code entered into the REPL,
that would seem like an incredibly useful feature. Perhaps
there's some common set of base functionality that can be
factored out of lldb and cling and unified. It would likely
be a good idea to start talking to the lldb folks about that
early, in case it guides your work porting cling to trunk.
Indeed. There have been user requests to be able to run
step-by-step in cling. That would be the ultimate long term goal!
On Thu, 9 Jul 2020
at 13:46, Vassil Vassilev via cfe-dev < [hidden email]>
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).
Many thanks!
David & Vassil
References
===
[1] ROOT GitHub https://github.com/root-project/root
[2] ROOT https://root.cern
[3] Cling https://github.com/root-project/cling
[4] Xeus-Cling
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
[6] High-performance Python-C++ bindings with PyPy
and Cling,
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
[8] CUDA C++ in Jupyter: Adding CUDA Runtime Support
to Cling',
https://zenodo.org/record/3713753#.Xu8jqvJRXxU
[9] HIP Programming Guide
https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by David Blaikie via cfe-dev
On 7/11/20 1:50 AM, Chris Lattner
wrote:
On Jul 10, 2020, at 2:58 PM, Richard Smith via cfe-dev <[hidden email]> wrote:
One other thing I think we should
consider: there will be substantial overlap between
the incremental compilation, code generation, REPL,
etc. of cling and that of lldb. For the initial
integration of cling into LLVM, there's probably not
much we can do about that, but it would seem
beneficial for both cling and lldb if common parts
could be shared where possible. As an extreme example,
if we could fully unify the projects to the point
where a user could switch into an 'lldb mode' in the
middle of a cling session to do step-by-step debugging
of code entered into the REPL, that would seem like an
incredibly useful feature. Perhaps there's some common
set of base functionality that can be factored out of
lldb and cling and unified. It would likely be a good
idea to start talking to the lldb folks about that
early, in case it guides your work porting cling to
trunk.
This is a really good point. I’m not sure how much awareness
there is on this list, but the Swift REPL is worth looking at if
you haven’t seen it. It is built on/in LLDB, and provides some
really nice user experience features.
For example, if you evaluate an expression that crashes, you
get a full backtrace and integrated debugger experience. There
are a couple of examples on this page, and more detailed info
online:
Thanks Chris! The comments
coming from John McCall allude to this that we need some broader
discussion on how we do things for incremental compilation. I
still have not forgotten that I need to get back to him with that
;)
That's one of the challenges I see. Currently upstreaming our
patches did not have enough context. Now I hope that we can start
with something minimal (and likely wrong) but we will have a
common tool in the context of which we can discuss how to make
things better. Putting swift-repl folks, lldb folks and cling
folks in one virtual room may be helpful.
-Chris
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by David Blaikie via cfe-dev
Vassil is right, it's just one Clang instance per expression. This is by design as it allows LLDB's expression evaluator to be flexible and it also makes the code simpler and clearer.
Regarding the REPL part: LLDB's expression parser for C++ isn't meant to be a full REPL. There is only some limited data sharing between each expression (e.g., result types and a few specifically marked declarations from the user) as the goal is to make an AST that fits the context where the expression is evaluated. That means that we need to support that a user can type "MyStruct" and in one expression it might refer to a struct type, but in the next expression (which could by at some other point in the program) it might be a typedef, or a macro, or a Objective-C class, or a global/local variable name, or a member variable as the evaluation context changed into a class, or a keyword in the current C-language, or also a struct but with a different definition or not even anything at all.
I really don't see a sane way to support just this one simple feature with with Cling's single shared AST + incremental CodeGen approach.
Also LLDB's expression parser doesn't really have a lot of non-LLDB specific code left that could be shared with other projects. We used to have a bunch of Clang in the expression parser but most of it is be gone by now. The rest is really LLDB-specific (e.g., configuring Clang to match the target we are trying to debug, a lot of code for setting up the right evaluation context of the location where the program is stopped).
Having said that, I think Cling should be upstream any shared code we can find between Cling and LLDB should be shared. Feel free to add me to patches and I'll see what I can find.
- Raphael
On 7/11/20 12:58 AM, Richard Smith
wrote:
On Fri, 10 Jul 2020 at 13:59, Vassil Vassilev via
cfe-dev < [hidden email]> wrote:
Hi Richard,
On 7/10/20 11:10 PM, Richard Smith wrote:
Hi Vassil,
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!
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)?
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/.
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: 1. Land as many cling/"incremental
compilation"-related patches as we can in clang.
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.
3. Rework cling to use that infrastructure -- ideally,
implementing it's specific meta commands and other
domain-specific features such as dynamic scopes. 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. 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. 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. Am I making sense?
Yes, the above all makes sense to me. I agree that there
should be only one thing named 'cling', and that it should
broadly have the feature set that current 'cling' has. I
think there are a couple of ways we can get there while
still providing the a minimalist interpreter to a broader
audience: either we can build a simpler clang-interpreter
and a more advanced cling binary from a common set of
libraries, or we could produce a configurable binary that's
able to serve both rules depending on configuration or a
plugin or scripting system.
Good point. We could make it extendable, and actually that
should be a design goal. The question how exactly is not very
clear to me. Can you elaborate on what you had in mind as
configuration or scripting system (plugin system I think I know
what you meant). I will give an example with 3 distinct features
in cling which we have implemented over the years and had
different requirements: * AST-based
automatic differentiation with the clad
library -- here we essentially extend cling's runtime by
providing a `clad::differentiate`, `clad::gradient`,
`clad::hessian` and `clad::jacobian` primitives. Each primitive is
a specially annotated wrapper over a function, say `double
pow2(double x) { return x*x; }; auto pow2dx =
clad::differentiate(pow2,/*wrt*/0);`. Here we let clang build a
valid AST and the plugin creates the first order derivative and
swaps the DeclRefExpr just before codegen so that we call the
derivative instead. This is achievable by the current clang plugin
system ( a bit problematic on windows as clang plugins do not work
there ). * Language extensions which require Sema support -- we have a
legacy feature which should define a variable on the prompt if not
defined (something like implicit auto) `cling[] i = 13;` should be
translated into `cling[] auto i = 13;` if I is undefined. We solve
that by adding some last resort lookup callback which marks `i` of
dependent type so that we can produce an AST which we can later
'fix'. * Language extensions which require delayed lookup rules (aka
dynamic scope) -- ROOT has an I/O system bound to cling people can
write:`if (TFile::Open("file_that_has_hist_cpp_obj.root"))
hist->Draw();`. Here we use the approach from the previous
bullet and synthesize `if
(TFile::Open("file_that_has_hist_cpp_obj.root"))
eval<void>("hist->Draw()", /*escape some context*/...);`.
The implementation of these three features can be considered as
possible with current clang. The issue is that it seems more like
hacking clang rather than extending it. If we can come up with a
sound way of implementing these features that would be awesome.
One other thing I think we should consider: there will be
substantial overlap between the incremental compilation,
code generation, REPL, etc. of cling and that of lldb.
I would love to hear opinions from the lldb folks. We have
chatted number of times and I have looked at how they do it. I
think lldb spawns (used to spawn last time I looked) a compiler
instance per input line. That is not acceptable for cling due to
its high-performance requirements. Most of the issues that need
solving for lldb comes from materializing debug information to
AST. LLDB folks, correct me if I am wrong. That being said doesn't mean that we should not aim for
centralizing the incremental compilation for both projects. We
should but may be challenging because of the different focus which
defines project priorities.
For the initial integration of cling into LLVM, there's
probably not much we can do about that, but it would seem
beneficial for both cling and lldb if common parts could be
shared where possible. As an extreme example, if we could
fully unify the projects to the point where a user could
switch into an 'lldb mode' in the middle of a cling session
to do step-by-step debugging of code entered into the REPL,
that would seem like an incredibly useful feature. Perhaps
there's some common set of base functionality that can be
factored out of lldb and cling and unified. It would likely
be a good idea to start talking to the lldb folks about that
early, in case it guides your work porting cling to trunk.
Indeed. There have been user requests to be able to run
step-by-step in cling. That would be the ultimate long term goal!
On Thu, 9 Jul 2020
at 13:46, Vassil Vassilev via cfe-dev < [hidden email]>
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).
Many thanks!
David & Vassil
References
===
[1] ROOT GitHub https://github.com/root-project/root
[2] ROOT https://root.cern
[3] Cling https://github.com/root-project/cling
[4] Xeus-Cling
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
[6] High-performance Python-C++ bindings with PyPy
and Cling,
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
[8] CUDA C++ in Jupyter: Adding CUDA Runtime Support
to Cling',
https://zenodo.org/record/3713753#.Xu8jqvJRXxU
[9] HIP Programming Guide
https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
|
In reply to this post by David Blaikie via cfe-dev
On 7/11/20 12:10 AM, Hal Finkel wrote:
On 7/10/20 4:00 PM, JF Bastien 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. 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 <[hidden email]>
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).
Many thanks!
David & Vassil
References
===
[1] ROOT GitHub https://github.com/root-project/root
[2] ROOT https://root.cern
[3] Cling https://github.com/root-project/cling
[4] Xeus-Cling 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
[6] High-performance Python-C++ bindings with PyPy
and Cling, 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
[8] CUDA C++ in Jupyter: Adding CUDA Runtime
Support to Cling', https://zenodo.org/record/3713753#.Xu8jqvJRXxU
[9] HIP Programming Guide https://rocmdocs.amd.com/en/latest/Programming_Guides/HIP-GUIDE.html
_______________________________________________
cfe-dev mailing list
[hidden email]
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
[hidden email]
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
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
|
|
Locked
