Monthly LLVM libc meeting

Runtimes C
34

Notes from today’s meeting:

  • Nick’s moving on, won’t be a primary LLVM-libc maintainer going forward
    • Reviews might be slower, would appreciate help getting more reviewers
  • Michael hosts interns to work on wchar support
  • Three GSOC proposals relatively libc related
  • Moving the GPU build off of enable_projects
    • We’re moving to split the runtimes and projects in LLVM
    • The GPU build needs to create its own loaders, which currently depends on the libc printf sources
    • If we could provide the printf internals through /shared, then this would unblock moving stuff to projects
    • It might be useful to provide a switch between compile time dispatch and runtime dispatch, as well as making the code all header files which are built as an object for default linux builds.
    • Both GPUs and Android might be interested in access to an internal printf API, Fuchsia already has its own interface to the printf internals.
    • Previously Joseph made a patch to template the writer class:
    • Plan:
      • Move printf writer to compile time dispatch, with one of the options being runtime dispatch.
      • Make the printf core explicitly header-only, with an option to build it as an object file.
    • Other blocker for enable projects is the old benchmarking code, seems unused
      • Having benchmarks is useful, we should look into making a proper benchmarking suite eventually
  • Math function aliasing
    • Some targets have long double is double, and for those targets it would be ideal to make the long double functions aliases of the double functions
    • Doing this would create some issues for independence of functions, one way to do this would be to have a way for functions to block each other.
    • For providing math functions to LLVM, it might be best to move the implementations to header files so it can be shared. This could be another way to handle the issue, just have both entrypoints point to the same internal functions.
    • Roland: Aliases would be preferred, but there’s some complexity around the type mismatches and platform specifics.
    • Elliot: Bionic already has some alias trickery around ignoring unused locale_t arguments. One issue is that the alias needs to be in the same file as the original function, or at least in the same TU (includes can fudge things).
      • Bionic doesn’t use the alias attribute, just asm, which is how it can do the aliases for functions with different arguments
    • Nick: It may be possible to add aliases via objcopy, though it would require a postprocessing step.
    • Petr: Libc++ has also been trying to use aliases, found that MacOS does support aliases but not the alias attribute, have to use ASM. Not sure why clang doesn’t just do the right thing for the alias attribute.
    • Tue: Going to go forward with a proof of concept on the math functions, hopefully expand to more later.
    • It also might be useful to have dependencies between functions (e.g. need pthread_init to do anything with pthreads)
      • Ideally more automatic, figuring out cross dependencies manually is error prone
  • Interest in standardizing the fixed point type
    • Tue has heard interest in the floating point working group.
    • Looks like there will be a proposal to form a study group in WG14, or possibly just sent to the C floating point group
      • Petr: Important to include Leonard Chan, current fixed point expert from the Fuchsia side. Also there’s been significant interest internally.
    • LLVM-libc might end up being the first to implement the fixed point.
    • Aaron: Fixed point is seeming like a possibility for C2Y, if there is interest.
    • The Technical Report needs updating, there will be some changes before it gets standardized.
    • The technical report also covers address spaces, which is also possibly getting updated and standardized.
      • Having better language support for address spaces would be very helpful for embedded, but there’s more study to be done.
      • The address space attributes supported by clang and gcc are not following the TR. The committee would really appreciate input from people actually using address spaces.
      • GPUs are also very interested in address spaces.
        • AMD is using memory scopes for important algorithms, but may not be interested in standardizing
  • Nick’s projects
    • Building LLVM projects with LLVM-libc
      • If you use several carve-outs, libcxx and libcxxabi can be built, but the core LLVM needs widechars and some other stuff.
    • Cross compiling
      • Need to clean up our build system, and some code
      • Would be very helpful to clean up our buildbots, we will probably need to start building our own clang since at least the risc-v 64 bot isn’t getting updates.
1 Like