Title

Building LLVM at rev.ng: a report

Authors

Alessandro Di Federico ([email protected]), rev.ng
Filippo Cremonese ([email protected]), rev.ng

Distribution

We build and distribute LLVM both for development purposes (sort of an SDK) and as a library for our application.

Abstract

At rev.ng we're building a LLVM-based decompiler with Qt UI.
Our development environment is Linux-only.

We build and distribute LLVM as:

1. a Linux toolchain for the whole project, using libc++;
2. a Windows (and soon macOS) cross-toolchain for the whole project, using libc++;
3. a library used by our application (the decompiler);

Our own package manager, orchestra, produces binaries that can be used by end-users and developers.
Thanks to RPATH magic, all of our binaries are portable (run them from your $HOME) and do not require root to be installed.
Also, since we build and link against an ancient glibc, the binaries can run on distributions as old as Debian 7, despite being built on modern systems.
We build LLVM in debug -O0, debug -O2, debug + ASan and release.

We'd like to report (and hopefully get feedback) on issues we regularly face when building LLVM:

1. issues building clang and libc++/libc++abi for Windows;
2. issues arising when a release build of an application uses a debug build of LLVM (or an ASan build);
3. constraints in the version of LLVM we want/have to use as a library (for the decompiler, for building mesa...) and the desire to use the most recent version of clang as a toolchain;
4. dealing with failures in LLVM tests due to our particular set up (building as "root", building as C++20...);
5. struggles in passing the right flags to the compiler when dealing with custom/ancient build systems;
6. discussion on having a set of well-defined, documented and CI-tested build configurations that are supported/known to work;

What makes your distribution of LLVM unique?

• We produce Linux binaries compatible with ancient glibc (i.e., Linux distros)
• We cross-compile for Windows from Linux
• We build portable installations of LLVM
• We support mixing different build modes across different projects (debug LLVM and a non-debug application using it)

What might others learn from your experience?

Struggles and workarounds in building (and cross-building) recent and ancient packages using an clang/libc++ based toolchain.

What could be improved in upstream LLVM to make working with it easier as a downstream packager?

• Have a set of build configurations well-document, supported and CI-tested by upstream
• Make cross-compiling libc++ easier

Title

Swift on Windows

Author

Saleem Abdulrasool [email protected]

Distribution

A LLVM based toolchain meant to target Windows (X86, X64, ARM, ARM64), Android (X86, X64, ARM, ARM64) for C, C++, [Objective-C, Objective-C++,], Swift.

Abstract (optional)

TODO

What's unique about the environment you package LLVM for? (optional)

The distribution tries to be nearly hermetic (LLVM is not yet sufficient for this for Windows), with coverage for C/C++/Swift in a single toolchain that is meant to target multiple platforms from Windows. The distribution includes all the tools for cross-compiling C/C++/Swift on Windows to Windows and non-Windows targets, as well as components to serve an IDE experience (e.g. language server, indexing, package manager, etc).

What makes your distribution of LLVM unique? (optional)

The distribution contains significant divergence from upstream including support for an entire language ecosystem. Additionally, the distribution contains support libraries for the ecosystem. The toolchain actually must integrate with MSVC distributed components and bridge content from Microsoft vended toolchains into the custom toolchain.

What might others learn from your experience? (optional)

What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)

Reducing build time, complexity, binary size. A current installed toolchain is ~2.5 GiB without debug info. With debug info, a distribution is ~10 GiB. This excludes the language runtime.

Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.

Title

Android's Dream of a Stable Toolchain

Author

Pirama Arumuga Nainar, [email protected], Google
Stephen Hines, [email protected], Google (@stephenhines)

Distribution

AOSP LLVM toolchain is used to build the Android platform, the Android kernel and host tools (LLDB server, OpenJDK, adb etc). It also ships with Android Studio and NDK to build native applications.

Abstract (optional)

Our distribution of LLVM supports Linux, MacOS and Windows and uses tools from LLVM ecosystem (lld, compiler-rt builtins, libc++) whenever possible.

In this talk, we'll briefly discuss the distribution (components, build options etc) first and then focus on some operational challenges we face:

• first-party feature development
• continuous, nightly, testing
• managing reverts and cherry-picks
• cross-testing for Windows

What's unique about the environment you package LLVM for? (optional)

• Linux, MacOS and Windows toolchains using primarily tools from the LLVM ecosystem.
• Cross-runtimes (compiler-rt, libunwind, openmp) for Android-supported architectures.
• Multitude of users (Android platform, kernel, NDK) with varied adoption and support time frames.

What makes your distribution of LLVM unique? (optional)

We don't track an LLVM release but follow LLVM ToT closely. (This also applies to other toolchain maintainers within Google).

What might others learn from your experience? (optional)

What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)

Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.

I work with a few teams at Google who ship LLVM-based toolchains to both Google and open-source developers. All of these toolchains have custom pipelines designed to generate PGO profiles, which, when applied to the toolchain, make compiling and linking roughly 10-20% faster.

I'd be more than happy to give a lightning talk going over:

• The benefits the teams I work with see from PGO
• How these teams have implemented their pipelines
• Tools that exist in upstream LLVM that make generating & applying PGO profiles straightforward

I think this information would be useful and interesting to distributors who are interested in shipping PGO'ed toolchains, but who currently choose not to do so. Bonus points if it starts conversations of the form "we'd do PGO if only we had $X feature," where $X isn't terribly difficult to implement and land upstream. ;)

please click subscribe in the bottom right to subscribe for updates.

Title

LLVM-MinGW

Author

Martin Storsjö, [email protected], No affiliation

Distribution

A packaging of LLVM together with MinGW headers/libraries, usable both as native and cross compiler for targeting Windows on X86 and ARM. Available at https://github.com/mstorsjo/llvm-mingw.

Abstract (optional)

LLVM-MinGW is a freely redistributable toolchain consisting of Clang, LLD and the other binutils replacements, together with MinGW headers and libraries.

MinGW, short for Minimalistic GNU for Windows, consists of a set of freely redistributable (reimplemented from scratch) GCC compatible platform headers, link libraries and a small set of (statically linked) extra compatibility functions. It's traditionally used with GCC and binutils and libstdc++, and it uses the Itanium C++ ABI contrary to MSVC. It produces native Windows executables, not reliant on any extra runtime (contrary to Cygwin).

Clang and the LLVM tools can impersonate both GCC/MinGW and MSVC.

Clang, LLD and the other LLVM provided tools work fine as drop-ins in an existing MinGW environment, but LLVM-MinGW is a toolchain bootstrapped from scratch using only LLVM tools, and using compiler-rt/libc++/libc++abi/libunwind instead of libgcc and libstdc++.

The toolchain originated from a desire to target Windows on ARM; GCC and binutils don't support Windows on ARM (nor ARM64), thus none of those tools could be used. It serves as something of a reference example of a fully LLVM based MinGW configuration, while the MSYS2 project now also provides such environments (with a different setup).

The toolchain tries to provide tools in the same way as a GCC/binutils based MinGW toolchain, to allow building e.g. most autotools based projects with a simple ./configure --host=aarch64-w64-mingw32.

What's unique about the environment you package LLVM for? (optional)

Windows, as a target environment, is a bit different from most other targets, by there being two fairly different environments (MSVC vs MinGW) with bigger or smaller differences along pretty much every single level of the stack.

Fun fact: The toolchain was developed while actually implementing the support in LLVM/LLD for targeting Windows on ARM64, and the toolchain was used for building a demo app (VLC) that was showcased when Microsoft presented Windows on ARM64 for developers.

What makes your distribution of LLVM unique? (optional)

What might others learn from your experience? (optional)

The ups and downs of cross compilation and cross testing, how one can get fairly decent testing and QA on commodity hardware without a budget. Staying at top-of-tree without out of tree patches has been a good strategy.

What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)

Scheduling

Due to timezones (I'm based in Europe), I'm practically only able to present between 09.00 and 14.00 PDT (with 11.30 to 14.00 PDT being more ideal).

Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.

cc @gburgessiv @serge-sans-paille @aleclearmind @berolinux @pirama-arumuga-nainar @zmodem @aaupov @hyp @petrhosek @skganesan @tstellar @smithp35 @mstorsjo @compnerd @Ericson2314 @carlocab @RoboTux

Hi speakers, thanks for taking the time to submit a CFP; we look forward to all of your talks. Let's use this issue to discuss issues or questions for speakers. You can also email me [email protected], chat on the LLVM discord in #clang-built-linux, or #clangbuiltlinux on IRC on Libera.

I've published a tentative schedule, please take a look and let me know if you'd like to move your talk earlier or later. We probably wont be able to accommodate all requests.

I'm hoping that speakers can join up to 1 hr before the doors open to test your setup; I think the room has a 200 person limit, and I can't save spaces. I don't know if that will be a problem, but the speakers should join before the conference starts to ensure they're able to join. I'll publish the room link soon.

Questions?

Title

Snapdragon LLVM Toolchain

Author

Sivakumar Ganesan, [email protected], Qualcomm Innovation Center

Distribution

Snapdragon LLVM Compiler Toolchain is distributed for building Android NDK and Bare metal images

Abstract (optional)

Snapdragon LLVM Compiler Toolchain, which is available for Android NDK and Bare metal images, enables use of compilers in a broader range of configurations, providing performance and code size advantage particularly on Qualcomm Snapdragon micro-architectures. Snapdragon LLVM compiler has provided performance gains to a variety of Android applications and libraries.
This talk will discuss on how Snapdragon LLVM compiler manages to stay close to the upstream HEAD and challenges faced during the distribution process

What's unique about the environment you package LLVM for? (optional)

What makes your distribution of LLVM unique? (optional)

• Stay close to upstream HEAD:
  We bring upstream patches and merge it in our source tree via automation. The patches are merged out-of-order as we encounter conflicts, build or test issues while bringing in each commit. We use this concept of drain point to bring in all commits till a commit of interest for distribution is merged
• Support Windows and Linux Host

What might others learn from your experience? (optional)

There are a wide range of challenges that we face when trying to distribute the toolchain. Some of those challenges include the following issues that are seen with upstream patches:

• Hard to determine dependencies between patches as upstream no longer uses svn id in commit message
• Do not know when patches are getting reverted
• cmake changes resulting in false positive builds, for example, builds missing some output binaries
• Major upstream code changes causing significant effort to make it downstream compatible

Another distribution challenge that we encounter is with the LLVM toolchain version that Android AOSP builds come with. New AOSP drops at times use a different LLVM upstream toolchain version resulting in build issues because of mismatch between upstream LLVM compiler and Snapdragon LLVM

What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)

Anything that makes the HEAD revision more stable: for instance, enforcing precheckin verification for each commit, means to determine dependent patches etc.

Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.

Title

Graphcore IPU LLVM toolchain & libraries

Author

Thomas Preud'homme [email protected] (Graphcore)

Distribution

LLVM toolchain and toolchain libraries for the Graphcore IPU

Abstract

Developing AI models for the Graphcore IPU is done using the Poplar SDK which relies on LLVM libraries as well as a firmware compiled using a LLVM toolchain. The Toolchain team at Graphcore provides a distribution of those components with an entirely new backend and a custom C library for other internal teams and customers' consumption.

Providing the best platform for the fast evolving AI ecosystem comes with some challenge:

• Frequent updates to the ISA resulting from software hardware co-design require more automation to incorporate those changes in the toolchain efficiently
• Some instructions without obvious IR representation that require novel testing technique for SelectionDAG lowering
• Not yet upstreamed target which leads to higher merging effort

What's unique about the environment you package LLVM for?

Our target architecture has a fast evolving specification with an entirely downstream support. We also have two separate sets of users: one that use the LLVM toolchain and another one which integrate LLVM libraries into a development framework distributed to customers. Finally, the Graphcore IPU follows the ongoing freestanding proposal which libc++ does not support yet.

What makes your distribution of LLVM unique?

Graphcore IPU LLVM backend is downstream-only and has tablegen files generated from the ISA documentation. It also features a SelectionDAG unit testing mechanism and has a very simple C runtime.

What might others learn from your experience?

• How to unit test SelectionDAG lowering rather than rely on IR lowering.
• Pros and cons of autogenerating tablegen from ISA documentation.
• Difficulties of maintaining a downstream only backend with a simple C runtime.

What could be improved in upstream LLVM to make working with it easier as a downstream packager?

Keeping more target-specific code in target-specific files is a relatively easy endeavour that would make merging from upstream easier for downstream targets. A more important effort would be to have a mechanism to inform people of non-breaking changes that both downstream and upstream code owner might take advantage of, such as new SDNode that could do with new lowering code. Finally, support for the ongoing freestanding C++ proposal would help us greatly but would require a significant ongoing effort to maintain.

Title

Clang vendor options: control new Clang and LLVM changes in a release

Author

Alex Lorenz, [email protected] / [email protected], Apple

Distribution

Apple's Xcode toolchain, used to build Apple's operating systems like iOS and macOS, and also by the App Store developers

Abstract (optional)

Clang and LLVM are constantly improving and are getting 100s of commits per week! Benefiting from all these changes in existing projects comes with unique challenges, for example, the existing code might not be compatible with newly added errors and warnings.

This talk presents clang vendor options and vendor flags. They can be used to selectively control how new Clang and LLVM changes are enabled. For example, a downstream vendor can use them to disable certain new features and/or diagnostics, to ensure that their compiler can continue compiling their existing code, while waiting for the software changes needed to fix the build failures caused by the new compiler changes. They can also be applied selectively to a subset of the user code. The new vendor options allow Apple’s clang team to test the main-tracking branch of Apple Clang on a continuous basis, and also simplifies the process of creating and managing new release branches.

What's unique about the environment you package LLVM for? (optional)

What makes your distribution of LLVM unique? (optional)

What might others learn from your experience? (optional)

What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)

Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.

Title

The LLVM embedded toolchain for Arm

Author

Peter Smith, [email protected] Arm

Distribution

A LLVM based toolchain for bare-metal embedded systems, initially focused on Cortex-M devices.

Abstract (optional)

For many years the GNU Arm Embedded toolchain has provided an open-source toolchain targeting embedded systems. The LLVM Embedded toolchain for Arm is a new open-source project with the goal of providing an LLVM based equivalent to the GNU Embedded toolchain. We would like the LLVM Embedded toolchain to lower the bar to entry of using LLVM in Embedded systems development. The project itself is a set of build scripts that combines tools and libraries from the llvm-project with the Newlib C-library to build the Toolchain from source. With the sample linker scripts it is simple to build and run a simple example that runs on the QEMU emulator. We have used, with a small enhancement, clang config files to approximate multilib and specs files for some hardware configurations. While sufficient for simple examples this will not scale well to the amount of Arm platforms that the GNU Arm Embedded Toolchain is able to support.

What's unique about the environment you package LLVM for? (optional)

The toolchain targets resource constrained devices in a freestanding environment. Targets need builds of libraries and custom linker scripts to match the memory model of the end device.

What makes your distribution of LLVM unique? (optional)

Packaging the LLVM tools and libraries with the newlib C library, with some built in configurations for common Cortex-M devices.

What might others learn from your experience? (optional)

Using configuration files in anger.
Using the bare-metal driver.
Integrating newlib

What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)

Some areas that the toolchain needs to improve that we'd like to work with the community on.

• Implementing multilib support in a way that can be upstreamed without hardcoding a library structure.
• Handling configuration choices that the GNU Embedded toolchain uses GCC specs files for (semihosting, non-semihosting etc).
• Supporting and testing more variants of compiler-rt for embedded A, R and M profile Arm CPUs.
• Implementing CI for a toolchain targeting microcontrollers. Ideally in a form that can report to the LLVM Community. For example, build-bots that cross-compile compiler-rt and run tests in emulators.

Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.

Title

LLVM Runtimes Build

Author

Petr Hosek, [email protected], Google

Abstract

While building Clang and LLVM tools is a simple and straightforward process, building a complete cross-compilation toolchain, that is, a toolchain that supports a number of different targets, can be a complicated endeavor that often involves custom scripts and infrastructure.

In particular, building LLVM runtimes like libc++ or compiler-rt can be especially challenging because runtimes have to be built with the just-built compiler for the target platform and cross-compiling these runtimes often requires custom build scripts to handle subtle bootstrap ordering issues.

In this talk, we are going to cover the LLVM runtimes build which was designed to simplify this process and allows building a complete LLVM-based cross-compiling toolchain with a single CMake invocation.

The LLVM runtimes build is already being used by a number of vendors and we hope that in the future it might become the default way of building LLVM-based toolchain distributions. If you are interested in using runtimes build, in this talk I hope to give you enough information to get you started.

Title

Homebrew LLVM

Author

Carlo Cabrera, [email protected]

Distribution

Homebrew is a package manager for macOS and Linux. We package LLVM for use by other packages that rely on it, and as an alternative toolchain for our users, who would otherwise be using their system compiler, or Homebrew GCC.

Abstract (optional)

We aim to provide a complete LLVM distribution that is easy to understand for end-users, doesn't interfere with system installations (i.e. Apple LLVM), and is maintainable by our small team (~25 maintainers for a repository of ~6000 packages).

In this talk, I will present how we configure and test our LLVM build: what we do well, what we could do better, and what we struggle with.

What's unique about the environment you package LLVM for? (optional)

The packaging constraints alluded to above.

What makes your distribution of LLVM unique? (optional)

We seem to have this in common with some of the other submissions, but our distribution is:

• fully relocatable, and;
• works on a wide array of Linux distributions (we require a minimum Glibc version of 2.13)

What might others learn from your experience? (optional)

How to do a full PGO bootstrap build on macOS.

What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)

ABI versioning for libLLVM on macOS.

Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.

Title

LLVM in OpenMandriva: packages that still need GCC, -fgnuc-version=11.2 and other "fun"

Author

Bernhard Rosenkraenzer, [email protected], OpenMandriva

Distribution

OpenMandriva is the first Linux distribution that made LLVM/Clang its main compiler. It is used to build almost all of our packages (both main and unsupported) - but we don't consider export CC=gcc; export CXX=g++ a complete taboo.

Abstract (optional)

OpenMandriva is the first Linux distribution that made LLVM/Clang its main compiler. It is used to build almost all of our packages (both main and unsupported) - but we don't consider export CC=gcc; export CXX=g++ a complete taboo. This talk gives a quick overview of where we still have to resort to this, why we still use libstdc++ rather than libc++ and other blockers for a 100% LLVM toolchain.
It also explains why we change the default -fgnuc-version value to 11.2 and what we need to change there.

What's unique about the environment you package LLVM for? (optional)

First Linux distribution that uses LLVM/Clang as its main compiler, use of -fgnuc-version=11.2

What makes your distribution of LLVM unique? (optional)

Crosscompiling support built in for everything, -fgnuc-version=11.2

What might others learn from your experience? (optional)

What still needs to be done to get to a 100% LLVM distro and more

What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)

More help for not so experienced packagers who report "MyFavoriteApp 1.1 works great with gcc but crashes with clang. Obviously clang is to blame and needs to be fixed, let's switch back to gcc!" type "bugs" -- There's currently no really good place for newbie packagers to turn to for help. Also, a patch exchange for the couple of packages where upstream maintainers insist on not supporting clang could result in less duplicated work.

Title

Fedora / Red Hat LLVM Toolchain

Author

Tom Stellard, [email protected], Red Hat

Distribution

LLVM and various sub-projects packaged for Fedora Linux and Red Hat Enterprise Linux

Abstract (optional)

We provide LLVM packages for both Fedora Linux and Red Hat Enterprise Linux. Our goal it to provide up-to-date LLVM packages that integrate well with the rest of the distribution. We support both the toolchain and library for users within the distribution (i.e. other packages) and for end users as well.

In this presentation we will look at the process of building an LLVM package, from sources to all the way to RPMs in the dnf repos, and discuss some of the unique challenges we face packaging LLVM for a general purpose distribution.

What's unique about the environment you package LLVM for? (optional)

We have a number of distribution-wide rules for packaging, like shared library requirements, hardening flags, standard install paths, etc. that put constraints on how we can package LLVM.

What makes your distribution of LLVM unique? (optional)

We do 'stand-alone' builds of the LLVM sub-projects, which means that we build each sub-project separately rather than building them all together from the monorepo sources. We also require other packages (including other LLVM sub-projects) that ship in Fedora and Red Hat Enterprise Linux to use the LLVM dynamic libraries instead of the static ones.

What might others learn from your experience? (optional)

How to package LLVM for a Linux distribution.

What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)

More stable and/or smaller APIs for the LLVM libraries.

Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.

Title

Fuchsia Clang Toolchain

Author

Petr Hosek, [email protected], Google

Distribution

Fuchsia's Clang toolchain is used to build the Fuchsia platform, the Zircon kernel and host tools.

Abstract (optional)

The Fuchsia Clang toolchain is a complete C/C++ toolchain distribution that supports Fuchsia, Linux, macOS and Windows and includes a number of LLVM tools and runtime libraries.

It is used by Fuchsia to build the system that powers millions of devices, as well as other related projects such as Pigweed, Dart and Flutter.

In this talk, we will cover our toolchain distribution, how we build it, test it and distribute it to all our developers. We will also talk about our principles and discuss some of the challenges we face.

What's unique about the environment you package LLVM for? (optional)

We ship a complete, general purpose LLVM-based toolchain for C/C++. We use this toolchain to build an entire operating system that was developed from scratch and includes everything from bootloader, kernel, system libraries all the way up to user applications.

We currently support four host platforms:

• Linux AArch64 and x86-64;
• macOS x86-64;
• Windows x86-64.

We currently support nine target platforms:

• Fuchsia AArch64 and x86-64;
• Linux x86, x86-64, ARM and AArch64;
• macOS x86-64 and AArch64;
• Windows x86-64.

Our goal is to provide the same experience on every supported platform and we achieve that by using LLVM tools and libraries making our toolchain completely self-contained.

What makes your distribution of LLVM unique? (optional)

We follow the "live at HEAD" model and stay close to the tip-of-tree. We release new toolchains on a weekly cadence and we adopt new features at a rapid pace.

We rely extensively on automation. We continuously build toolchains and use every newly produced toolchain to build and test the entire system. This automation is what makes it feasible to "live at HEAD" and roll so frequently.

Everything we use, including the CMake cache files, is upstream and we do not have any downstream changes so anyone should be able to reproduce our toolchain build.

What might others learn from your experience? (optional)

How to build an LLVM-based cross-compiling toolchain with a single CMake invocation.

What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)

Support for cross-platform testing in lit which will be important for us to run tests on Fuchsia.

Automated way to report downstream test results since it is infeasible for us to cover every build configuration through upstream testing.

Title

Building, Testing, and Distributing Chromium's C++ Toolchain

Author

Hans Wennborg, [email protected], Google

Distribution

Chromium's C++ toolchain, used to build Chromium and Chromium-derived web browsers.

Abstract (optional)

Chromium uses an LLVM-based C++ toolchain to build the browser for all its supported platforms. This talk covers how we build the toolchain for best performance, test it to be confident it works, and distribute it to all our developers and infrastructure. In particular, it covers how we manage to stay so close to the HEAD revision.

What's unique about the environment you package LLVM for? (optional)

What makes your distribution of LLVM unique? (optional)

• Many host and target platforms: Windows, Mac, Linux, Android, iOS, Fuchsia

• Living at HEAD: rigorous CI, shipping a new toolchain semi-weekly, no local patches, your LLVM commit can be used to build tomorrow's shipping canary version of the browser

• Not a general-purpose toolchain release: building Chromium is the supported use case

• Lots of upstream contributions to support our needs: clang-cl, the new lld; and things which are possible when controlling the whole toolchain such as constructor type homing, global type hashing for PDBs, etc.

What might others learn from your experience? (optional)

What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)

Anything that makes the HEAD revision more stable.

Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.

Title

Switching to LLVM based toolchains in Yocto based distributions

Author

Bernhard Rosenkraenzer, [email protected], Huawei Open Source Technology Center

Distribution

Yet unnamed embedded distribution (current working title: All Scenarios OS)

Abstract (optional)

The Huawei Open Source Technology Center is working on a new distribution for embedded devices, using the Linux kernel for higher end devices and the Zephyr kernel for the low end.
Like many embedded distributions, it is based on Yocto - but unlike most others, it uses LLVM/Clang as its primary toolchain.

The talk shows how it can be done, and goes over some issues currently in the way.

What's unique about the environment you package LLVM for? (optional)

Multi-kernel, multi-architecture embedded distribution using clang as its primary compiler

What makes your distribution of LLVM unique? (optional)

Crosscompiling with a Yocto based build system

What might others learn from your experience? (optional)

How to use clang in a Yocto/OpenEmbedded environment

What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)

More help for not so experienced packagers who report "MyFavoriteApp 1.1 works great with gcc but crashes with clang. Obviously clang is to blame and needs to be fixed, let's switch back to gcc!" type "bugs" -- There's currently no really good place for newbie packages to turn to for help.

Title

Optimizing Clang with BOLT

Author

Amir Ayupov, [email protected], Facebook

Distribution

Abstract (optional)

https://github.com/facebookincubator/BOLT/blob/main/bolt/docs/OptimizingClang.md

BOLT (Binary Optimization and Layout Tool) is designed to improve the application performance by laying out code in a manner that helps CPU better utilize its caching and branch predicting resources.

The most obvious candidates for BOLT optimizations are programs that suffer from many instruction cache and iTLB misses, such as large applications measuring over hundreds of megabytes in size. However, medium-sized programs can benefit too. Clang, one of the most popular open-source C/C++ compilers, is a good example of the latter. Its code size could easily be in the order of tens of megabytes. Clang executable suffers from many instruction cache misses and can be significantly improved with BOLT, even on top of profile-guided and link-time optimizations.

What's unique about the environment you package LLVM for? (optional)

What makes your distribution of LLVM unique? (optional)

What might others learn from your experience? (optional)

How to apply BOLT optimizations to make Clang up to 15% faster on top of PGO and LTO.

What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)

We're working on preparing BOLT for inclusion into LLVM monorepo as a subproject, and upstreaming BOLT-specific patches is a major part of the effort. Engagement and productive collaboration with reviewers, maintainers and other interested parties on upstreaming reviews is critical for the success.

Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.

Title

LLVM integration test suite

Author

[email protected] sylvestre@{debian.org,ubuntu.org}

Distribution

Fedora, Debian/Ubuntu

Abstract (optional)

Both Fedora and Debian have the ability to gate their package through a test-suite. In the case of the LLVM compiler infrastructure, it basically means making sure that all components are properly integrated into a working toolchain that also interacts correctly with other toolchain's component. We also see this testsuite as a forcing function to bring consistency to LLVM packaging.

We shared our test cases and ended up with a collaborative repo for these test, unimaginatively named https://github.com/opencollab/llvm-toolchain-integration-test-suite with the secret agenda to integrate it at some point in the LLVM project itself.

What might others learn from your experience?

The kind of errors we detected early, an interest to use and contribute to the test suite.

Title

LLVM toolchains in Nixpkgs

Author

John Ericson, [email protected], Obsidian Systems

Distribution

Nixpkgs is best known the package set behind the NixOS Linux distribution, but also runs on macOS, and arbitrary cross compilation. LLVM is used on macOS by default, and may be used for any platform; recently we've added a pkgsLLVM to encourage LLVM use in more contexts.

Abstract (optional)

About 5 years ago, we in the Nix community set out to be one of the few distros/package sets to support whole-system cross compilation, meaning not just providing cross toolchains, but also building arbitrary packages. Overhauling our infrastructure to do this, we found that the packaging of compilers was the keystone upon which many of our out decisions rested. To cut down complexity, we decided to strive for a few related polices:

• Make cross compilation the default, native compilation should "just" be cross compilation such that "build = host".
• Packages shouldn't manage their own bootstrapping, the distro should.
• Compilers and run-times should be built separately, so every package installs artifacts just for one platform
• Runtime libraries should be "unspecial" --- like any other library --- at least one building.

LLVM has easily been the compiler most amendable to re-package according to these principles. We want to highlight what has gone well, the current state of the LLVM packaging in Nixpkgs, and what we are trying to get upstreamed into LLVM next.

What's unique about the environment you package LLVM for?

Very open-world goals --- Nixpkgs aims to be the "universal" package set, running or cross compiling everywhere possible. All the other cross compilation targets being discussed --- we're listening and want to support your platform too, no matter how exotic!

What makes your distribution of LLVM unique? (optional)

Very fine-grained, with all runtime libraries and tools being built separately, and installed in separate prefixes.

What might others learn from your experience? (optional)

Techniques to manage many configurations / bootstraps without drowning in complexity.

(obligatory plug :)) Of course, you may find like we do that Nixpkgs a great foundation with which to develop toolchains and push them to their limits, and want to just use Nixpkgs rather than borrow our techniques.

What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)

• Better support for "GNU install dirs" --- how we separate regular and "dev" packages instead of DESTDIR or manual separation.
• Perhaps giving the -B/-resource-dir division of labor a fresh review.
• Clarify compiler-rt <-> libc dependencies.
• Use of "target" in source code interfaces D44753

@sternenseemann just let me know about this conference, which I am quite grateful for as I've long hoped for a venue like this to discuss our work, and may have more information to provide about pkgsLLVM. I imagine our experience chasing after stray build failures in arbitrary packages using LLVM might also be of interest. If I had figured everything out earlier, I would have written the above knowing the answer of whether he had information to add, but as the deadlines looms I figured I better get something up ASAP. Sorry!