Monthly LLVM libc meeting

Runtimes C
1

Hello,

I’m setting up a regular (every 4 weeks) meeting for developers of, and anyone interested in, LLVM’s libc (partly inspired by the one being set up for libc++).

The goal is to provide a space for future and current libc developers and users where we can discuss what we’re working on, what is open for more work, and what is blocking us.

There should be an event on the LLVM community events calendar by the time this is posted.

The meeting will be held on Google Meet (meet.google.com/otv-dmps-mcc) at 09:00 PST/PDT which is also 12:00 EST/EDT and 18:00 CET/CEST. The first meeting will be on Thursday, October 26th, 2023, and then every four weeks after that (excluding holidays, such as US Thanksgiving).

The meeting notes will be posted on this thread after each meeting, and the agenda will be posted before each meeting. If you want to add to the agenda, the easiest way is to send a message in the #libc channel in discord, or send me a message on discourse/discord.

3 Likes
2

Here’s the agenda for tomorrow’s meeting:

  • Introductions
    • Explaining the structure of this meeting
      • Start with the topics in the agenda
      • If we get through those, move to Q&A/open discussion
      • If we finish with that, end the meeting, even if it’s early.
  • (michaelrj): How many people are interested in working on the project, and how many are interested in using the project?
    • How can we enable what you’re doing?
    • What needs to be done before the libc is “complete” for your purposes?
  • Here’s what we’re working on:
    • (michaelrj): working on finalizing printf for google use
    • (lntue): working on double precision math functions
  • (jhuber): GPU math status?
  • (mcgrathr): How should special compiler flags be handled?
    • Should we allow changes that make certain compiler flags necessary for optimal performance?
      • This can cause problems for customers that don’t use our build system
3

Here are the notes from today’s meeting (lightly edited):

  • What needs to be done before the libc is “complete” for your use case?
    • Jhuber: Using LLVM libc for GPUs
      • Waiting on compiler fixes to land before varargs are available, as well as math tests for the GPU.
      • Tue is working on improving the exhaustive math tests so that they can test against the host system, since if we test that against MPFR then we can know they all match.
    • Phosek: Using LLVM libc for Fuchsia and Pigweed
      • Fuchsia is a microkernel OS
        • Currently using an old fork of musl, they want to move to something with better non-linux support, and getting updates.
        • Fuchsia needs a complete C library, and ideally C++ as well.
        • The Fuchsia libc has been slowly replacing parts of musl with functions from LLVM libc.
      • Pigweed is an embedded framework
        • LLVM libc would be a replacement for newlib
        • Most embedded systems don’t need all of libc
          • Memory functions, math, maybe sprintf
        • The libc might be complete for embedded, testing is ongoing.
        • The pixel buds pro are the first product they’re trying to move to LLVM libc, and it looks like all the functions they need are available.
        • There are other ones in progress, but they may need more. Every embedded system is different.
  • What are people interested in working on?
    • Lucian: Curious about streams, security and performance critical functions.
      • For security critical functions: The networking functions are very relevant, as well as having more fuzzers for existing string functions.
      • Having better support for operating with sanitizers, which traditionally intercept the libc functions since other libcs like glibc don’t cooperate with the sanitizer
        • Fuchsia builds sanitizers into their libc, since they build from source, and they’d be willing to upstream their internal API.
        • They’d also be interested in (if possible) working with several libc vendors to make this API more generally available.
      • Fortify source is something we’d like to support, but haven’t yet.
        • We’d like to coordinate our fortify source development with clang, since that would make the implementation cleaner within libc.
      • Another option would be matching the hardening modes that libc++ has.
  • Here’s what we’re working on:
    • (michaelrj): working on finalizing printf for google use
    • (lntue): working on single precision math functions and some initial support for C23 math functions
    • (jhuber): Poked at scanf, but has had issues getting it to compile. Also would like to build libc for GPUs and CPUs at the same time.
      • One of the important things for the GPU build is that it has to be built with an up-to-date clang since it requires some magic builtins only added to clang.
        • The current problem is that the libc cmake assumes that there’s only one target at a time.
        • It might be easier to just run cmake multiple times as separate builds using the runtimes build.
        • We might need to add ordering to the runtimes build, since it currently builds in any order.
        • The current way that libc++ can do multiple builds for multiple targets is by putting them in lib/target-triple/…
        • Another way would be to build the libcs with different suffixes (e.g. libc-target-triple.a)
        • One of the things being considered for the runtimes build is having a list of targets to build for, as well as a list of which of those can run tests.
  • Status of GPU math functions
    • The next step is getting exhaustive testing running so that we can test against the openCL standard.
    • We’d like to be able to provide multiple implementations so that we can provide a switch between speed and accuracy.
  • How do we balance having broad hardware support vs having the best performance
    • Using ifuncs to select a specific implementation is the standard method, but not necessarily the best one.
    • One way to handle this is to treat libc sources as part of your program, which allows for more targeted optimization but harms portability
    • How do we inform external users about special flags that certain files need?
      • Some users don’t use our provided build system, so having flags that are necessary for optimal performance can be a stumbling block if they aren’t made aware
      • We should probably add those flags to our config system since it’s JSON and so fairly easy to consume for downstream users
  • Lucian brought up the idea of benchmarking functions using shortcuts through undefined behavior, such as what strlen does: https://github.com/llvm/llvm-project/blob/main/libc/src/string/string_utils.h#L61
    • We currently have benchmarking for memory functions, math functions, and strtof.
    • Having more benchmarks would be nice.
      • Are we benchmarking to check our own performance or to compare against other libcs?
  • It would be nice to make our test suite available to use with other libc implementations
    • (michaelrj) I’d like to follow the design that libc++ uses, which is having the main test suite and marking some parts as testing internal details.
      • This allows us to have tests that check our implementation thoroughly, but also work for other libcs that only match us in the public API.
4

Just as a heads up: There will be no meeting on November 23rd since it falls on US Thanksgiving, currently the plan is to have the next meeting on December 21st.