Installing in Ubuntu when already have clang

[libbyshoop]

I was able to take a look at how to 'install OpenCilk' on my machine running Ubuntu 22.04 'jammy' linux. It appears to me that for OpenCilk, a new version of clang and clang++ would be installed. I have already used 'apt' to install the latest clang/clang++ and llvm from Ubuntu, which were needed for the Chapel compiler. clang and clang++ are found in /usr/bin on my system due to this. And /usr/bin/clang is a symbolic link to /usr/lib/llvm-14/bin/clang (similarly for clang++). So my question is this: is it best to have separate versions of clang/clang++ in /opt/opencilk? It seems that when I go to compile OpenCilk code, I would use the full path to that version. And more generally, is this the design choice, to have a different version of clang, or is the ultimate plan to hopefully fold your work into clang that I could install from Ubuntu apt?

[neboat]

Yes, installing OpenCilk installs a new version of clang and clang++ on the system.

There are a couple of reasons for this.

First, Cilk is a language extension to C/C++, not a library. Cilk adds new keywords to C/C++ that make it easy to expose logical parallelism in a program. By providing a language extension, the compiler can automatically handle many tricky issues with spawning logically parallel computation that programmers would otherwise have to handle themselves, including issues with passing parameters and handling return values. (This paper provides a nice, though quite technical, discussion of some of the issues.)

Second, the OpenCilk compiler extends the mainstream Clang/LLVM compiler with Tapir, which adds first-class support for parallelism to LLVM's internal representation of code. By using Tapir, the OpenCilk compiler analyzes and optimizes parallel programs much more effectively than mainstream compilers. Furthermore, Tapir allows us to provide simple yet powerful infrastructure for making efficient tools to analyze parallel programs, including tools to find race bugs in Cilk programs and tools to measure and profile their parallel scalability.

We would certainly be interested in upstreaming some or all of our compiler changes into the mainline Clang/LLVM compiler. But upstreaming any of these changes is not a simple undertaking. We are exploring options on this front, but it seems unlikely to happen in the short term.

For the shorter term, we are working to improve how we distribute OpenCilk and its version of clang/clang++. In particular, we're looking into ways to package OpenCilk for various package managers, including those of mainstream Linux distributions. Ideally, that effort would provide a way to install OpenCilk via Ubuntu apt. Fortunately, OpenCilk's version of clang is an extension of the mainline version, meaning that OpenCilk's clang can, in principle, do anything that mainline clang can do. That means one could install OpenCilk clang/clang++ on Ubuntu and use something like update-alternatives to safely "swap in" OpenCilk's clang/clang++ as the default clang/clang++ on the system. But there are a lot of different package managers to contend with, and it turns out the clang package on most systems, including Ubuntu, is quite complicated. As such, this work is still ongoing.

[libbyshoop]

Hello, This all makes sense and is what I expected. For the moment, I will install your version of clang in /opt/opencilk and use the full path to the compiler in my makefiles or when compiling from the command line. Thank you so much for this information! Libby Shoop Professor of Computer Science Mathematics, Statistics, and Computer Science Department Macalester College Saint Paul MN

…

On Wed, Apr 17, 2024 at 5:12 PM Tao B. Schardl ***@***.***> wrote: Yes, installing OpenCilk installs a new version of clang and clang++ on the system. There are a couple of reasons for this. First, Cilk is a *language* extension to C/C++, not a library. Cilk adds new keywords to C/C++ that make it easy to expose logical parallelism in a program. By providing a language extension, the compiler can automatically handle many tricky issues with spawning logically parallel computation that programmers would otherwise have to handle themselves, including issues with passing parameters and handling return values. Second, the OpenCilk compiler extends the mainstream Clang/LLVM compiler with Tapir <https://dl.acm.org/doi/10.1145/3018743.3018758>, which adds first-class support for parallelism to LLVM's internal representation of code. By using Tapir, the OpenCilk compiler analyzes and optimizes parallel programs much more effectively than mainstream compilers. Furthermore, Tapir allows us to provide simple yet powerful infrastructure for making efficient tools to analyze parallel programs, including tools to find race bugs in Cilk programs and tools to measure and profile their parallel scalability. We would certainly be interested in upstreaming some or all of our compiler changes into the mainline Clang/LLVM compiler. But upstreaming any of these changes is not a simple undertaking. We are exploring options on this front, but it seems unlikely to happen in the short term. For the shorter term, we are working to improve how we distribute OpenCilk and its version of clang/clang++. In particular, we're looking into ways to package OpenCilk for various package managers, including those of mainstream Linux distributions. Ideally, that effort would provide a way to install OpenCilk via Ubuntu apt. Fortunately, OpenCilk's version of clang is an extension of the mainline version, meaning that OpenCilk's clang can, in principle, do anything that mainline clang can do. That means one could install OpenCilk clang/clang++ on Ubuntu and use something like update-alternatives <https://manpages.ubuntu.com/manpages/trusty/man8/update-alternatives.8.html> to safely "swap in" OpenCilk's clang/clang++ as the default clang/clang++ on the system. But there are a lot of different package managers to contend with, and it turns out the clang package on most systems, including Ubuntu, is quite complicated. As such, this work is still ongoing. — Reply to this email directly, view it on GitHub <#240 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN3QSBLQY5O5ABSTEKTOVDY54FXXAVCNFSM6AAAAABGMDXRMGVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TCNBYG4ZTI> . You are receiving this because you authored the thread.Message ID: ***@***.*** com>