LLVM Embedded Toolchains Working Group sync up

Community
73

2024-11-07

Participants

  1. Alexey Karyakin

  2. Ana Pazos

  3. Anmol Paralkar

  4. Anton Rapetov

  5. Garrett Van Mourik

  6. henry

  7. Jonathon Penix

  8. Ken Matsui

  9. Paul Kirth

  10. Peter Smith

  11. Petr Hosek

  12. Sam Elliott

  13. Stan Kvasov

  14. Ties Stuij

  15. Tue Ly

  16. Vince Del Vecchio

  17. Volodymyr Turanskyy

  18. YUNG-CHIA LIN

Agenda

  1. Code reviews:

  2. LLVM libc printf code size optimization.

  3. Default for frame pointer for Arm bare-metal.

  4. Community: LLVM DevMeeting follow ups:

Discussion

Code reviews

  • Multilib custom flags

    • Sam: Extra build args make sense. Need to clarify if these are cc1 args or ones for the driver itself?

      • Petr: Slightly prefer driver args, as they are more user friendly (not internal details that people may not be familiar with).

      • Peter: Agreed, we also wanted more stability, thus depend on public args. No restrictions or strong opinion though.

    • Petr: Overall no big concerns over the RFC, next step - review the implementation.

Petr: LLVM libc printf code size opt

  • Petr presented slides by Daniel to summarize the 3 options being considered.

  • (1) A special function like “iprintf” is in clang and does not use FP, available for emscripten and xcore targets.

    • Could be “_small_printf” or similar name to highlight that it is non-standard.

    • => benefit - already is in clang; there is a prototype implementation.

    • Ana: We tried to upstream the same into Musl C library, but it was rejected because it is not a standard C API. LLVM libc team considers that it is OK to have extensions in LLVM libc. May use a different name to avoid confusion, can use underscores to highlight not standard

  • (2) Weak implementations of multiple functions per format specifier to print or such; compiler will generate a strong reference only to used sub-functions, the rest would be garbage collected to save size.

    • Peter: This approach was used in Arm Lib C.

    • => compiler implementation will be a bit more complicated, than the 1st option.

  • (3) Call site splitting - most involved implementation - replace (rewrite) printf with multiple calls to simpler functions in place.

    • Peter: code size can grow, because of expansion in place, so depends on actual usage in an app.

    • Petr: idea: try to do it as constexpr implementation in C++?

    • Vince: what is the expected advantage of this? If there are only few simple/constant args, then can save on parsing the format string and replace with only basic function calls

  • RFC about these options would be great, Arm team can also add details of our current implementation in Arm Lib C to the RFC.

Peter: frame pointers on or off by default?

Dev Meeting follow up

  • Workshop went well, very good participation.

  • Petr: setup a feedback form, feedback so far: people would appreciate having a full day workshop. Deep dives were great, wanted more. Petr will take to organizers. May skip talks next time as well to give more time for discussions.

  • Petr: ELF TLS in LLVM libc - tried to avoid TLS implementation so far, can make configurable (a function call vs TLS).

    • There are other more critical things now, e.g. semihosting.

    • Peter: TLS is useful if there is a lot of usage of thread local variables, otherwise the impact is small.

  • Peter: PIC in embedded discussion was insightful.

    • In most cases, not used, but if it is needed, then there is no workaround.

    • clang can do PIC, ROPI, RWPI today, but they do not work for C++ really.