LLVM Embedded Toolchains Working Group sync up

Community
90

2026-02-26

Agenda

  1. Reviews and RFCs

  2. Follow up on previous topics

  3. Community

Discussion

Peter: AArch64 PAuthABI command line interface

  • AArch64 PAuthABI is similar to to Apple arm64e ABI. There is no official Linux target for it, but it is possible to implement on bare-metal.

  • Interest for barmetal is to use e.g. with trusted firmware. RFC is in progress by Peter.

  • There is environment part in the target triple that may be used.

  • There is actually a whole family of ABIs depending on what exactly types of pointers to sign or not. May need sort of “profiles” - predefined signing schemas.

  • Question: Is the environment part of triple a good option to use here? Any better ideas?

    • Alternatively we can use the abi command line option or a sub-architecture, etc.

  • Eli: Triple may not be the best to define the ABI - pieces of ABI aspects would be missing, so better to look for different options.

  • Peter will post the RFC and the discussion will continue there.

cstdlib command line option

  • Petr: string is used to represent the library selection in the PR. Unlike other libs like unwind, that use an enum.

    • Providing an enum would follow the structure of other code, but fix the list of libraries and require downstream patches for vendor specific libraries.

    • Keeping it as a string give more flexibility, but less error prone in the code.

  • Another idea: provide a special option to provide a definition of the C library, e.g. a yaml file that will define multiple library properties, not just the name. How this would compare vs the multilibs yaml and GCC spec files?

  • Daniel: multilibs and config files are used now in different toolchains, so already to competing ways.

  • Peter: Overall data driven is good to give flexibility to define vendor specific libraries.

  • Michael: It would be good have a config to tell the compiler what the capabilities of the library are, e.g. for the modular printf - tell what variants are available.

  • Daniel: Note that now a log of knowledge of what is available in a libc is hardcoded in clang based on triple.

  • Daniel: Check what is already in the driver today - what can we abstract out?

  • Daniel: We should make sure we can combine all these config files together cfg - multilib - future yaml - …

  • Volodymyr: The original RFC suggested using a string as well: in ATfE the libraries are self contained so the only thing needed is to point to the correct multilib top level folder to pick up the yaml file.

  • How to conclude? It may be worth giving the opportunity to experiment, instead of trying to (over-)engineer upfront? We should make sure to highlight these are experimental and can change in the future to align between all these different ways to configure as above.

Petr: Yaml vs hardcoded multilibs for Arm targets

  • Some projects are migrated to Arm and their teams are asking for multilibs, however they are not using the multilib yaml yet.

  • Typical RISCV multilibs are hardcoded in Baremetal driver - there is no such for Arm.

  • ATfE only uses multilibs yaml, however generation of yaml is not in upstream.

  • Question: Would it be OK to hardcode a common set of Arnm multilibs in the driver? Only use yaml for more complex configs/sets of libs.

  • Peter: How to define the “common” set - match the GCC set? How to avoid going into the adding just “one more” loop? May be match distro provided sets?

  • Petr: Suggestion to start with GCC set. Also try to define one set across all drivers in central place.

  • Peter: From ATfE point of view, we are not against having the hardcoded set as long as it does not interfere with yaml multilibs.

  • Peter: Alternative could be to generate the multilibs yaml from by tablegen in upstream LLVM Project.

  • Petr: Or convert yaml into JSON to read in CMake to drive builds?

  • Volodymyr: It may be possible to generate both yaml and JSON from one source.

  • Petr: Note that libc went away from tablegen generation to yaml files because of dependency on LLVM - use of tablegen has own issues.

  • Volodymyr: From ATfE side we want to upstream libc multilibs builds into the LLVM Project so that is is possible to build ATfE with LLVM libc from upstream itself. Would allow more and easier testing.

    • Petr: There is some support already for building multiple variants, but very heavy.

    • Ninetendo team also interested - now they use yaml/Python and generate 100s of lib variants.

    • How to implement multilibs directly in the build - there is a conceptual idea how this can be done, but needs details and refactoring of existing CMake.

    • Another example, flang runtime builds are separate now - plan to include into main logic, which make it even more complex. Requires a major cleanup to proceed.

    • Need capacity for the refactoring! Petr can help, but has limited time.

    • Another complexity is that there are too many ways to build runtimes today, likely many of them are legacy and not used.

    • Peter: Ideas: Create a new “compiler-rt2” like a new pass manager, instead of refactoring in place?

    • Petr: Agreed, “clang-rt” in fact is better name to match the name of the libraries installed.

Fallback FP implementations in LLVM libc

  • Michael: There is a GSoC project this year to replace basic/fallback FP implementations in libc - is this even used? Are there people having/using only C compiler, i.e. without C++ compiler?

  • Peter: There may be downstream build systems that do so.

  • Petr: Should not prevent upstream from making the change even if such exists for someone downstream.

LLVM libc code size

  • Petr: Bigger projects are being migrated to clang now, which triggered a new issue: code size with LLVM libc is significantly bigger.

  • Working hard to cut down the size, however still bigger than newlib (or news-nano - not sure) for Cortex-M33 and Cortex-M55 targets: FP math and Helium are used.

  • Code size needs more attention, e.g. provide a tracker for size in upstream.

  • Math lib contributes a lot of data, e.g. tables and constants - it is more precise, but is it important for embedded?

    • Peter: in Arm Compiler there were 3 variants: fast-math (much less precision), middle/balanced option and strict math option.

    • There are routines that we can contribute from Arm Libc, but they would not meet precision requirements set by libc now

    • => Agreed to discuss in the next libc sync

EuroLLVM 2026

  • Peter, Petr and Michael are going.