LLVM Embedded Toolchains Working Group sync up

2023-03-30: Multilib, profiling runtime

Participants

  1. Gulfem Savrun Yeniceri

  2. Henry Cox

  3. Mandeep Singh Grang

  4. Michael Jones

  5. Nathan Sidwell

  6. Prabhu Rajasekaran

  7. Paul Kirth

  8. Petr Hosek

  9. Pierre

  10. Siva Chandra

  11. Stan

  12. Vince Del Vecchio

  13. Yung-Chia Lin

  14. Peter Smith

  15. Volodymyr Turanskyy

Agenda

  1. Multilib code reviews.

  2. Other code reviews in progress.

  3. Embedded profiling runtime. Include profiling lib? · Issue #197 · ARM-software/LLVM-embedded-toolchain-for-Arm · GitHub and Profiling contribution by rgrr · Pull Request #204 · ARM-software/LLVM-embedded-toolchain-for-Arm · GitHub

  4. Building runtimes for bare-metal.

Discussion

Multilibs code review

  • RFC and list of patches [RFC] Multilib - #5 by mplatings

  • Peter: The reviews are accepted by Arm, need confirmation from others in the community.

  • Petr: Will follow up on remaining reviews shortly.

  • Peter: A related question: In case there is a newlib installed from a distro package: how to make it work with clang?

    • Option could be to provide the config file to point there.

    • Could we inject an external multilib config file to use an existing set of multilibs?

    • Petr: There was a comment in the review that now the location of the yaml file is hardcoded - would be great to allow configuring it via a command line option, would solve this use case as well.

Other code reviews

Profiling runtime

  • Peter: A request raised for the LLVM Embedded Toolchains for Arm Issue #197

  • One option is to create a trivial runtime that would dump the counters somewhere as suggested in the issue discussion thread.

  • Wider question is how to add bare-metal support to the compiter_rt?

  • The PR Pull Request #204 suggests an implementation based on reusing compiler_rt pieces, which goes in the right direction, but only provides a very narrow Arm semihosting-specific implementation. How to generalise?

  • Can we provide an interface inside compiler_rt that can be used to tailor actual implementation of storing the data, suitable for bare-metal use cases as well?

  • Petr: The idea makes sense, the profile runtime is not in the best shape now, it would be great to refactor it and rewrite in C++. Would be good to have a header-only minimal implementation to allow easy reuse between actual implementations.

  • The team is very much interested in the implementation, but there was a lack of time to progress.

  • https://cs.opensource.google/fuchsia/fuchsia/+/main:src/lib/llvm-profdata/llvm-profdata.cc is an example of a minimal runtime we use for our kernel, we would like to break it up and upstream individual pieces so it can be reused for other embedded targets.

  • Exists a local patch in progress, the team will need help to progress it upstream.

  • Best way to start would be to do clean up/refactoring.

  • People who have downstream modifications - would be useful to know what kind of changes are there and why, i.e. how to refactor to accommodate for these? Examples:

    • Split of data to minimise the size of the resulting executable.

    • Size of counters: 32 vs 64 bits.

    • One runtime is used for both profiling and code coverage, thus maintains data for both - could be configurable.

  • Petr may post on Discourse a list of ideas for refactoring based on internal discussions.

  • A good topic to discuss in EuroLLVM 2023.

Building runtimes for bare-metal