For background on these calls, see here.
Reminder: the purpose is to coordinate between active contributors. If you have support questions etc then it’s best to post to LLVM’s Discourse or Discord.
We have a call every alternate Thursday at 4pm BST. If you have topics to discuss, please email me ahead of time or add to the agenda.
Attendees are required to adhere to the LLVM Code of Conduct For any Code of Conduct reports, please contact me, and also email conduct@llvm.org.
Dial-in details:
We have a shared calendar that may help in keeping track, which is
accessible through:
Agenda (copied from the linked doc - if you have additional items please add them):
- GCC vs LLVM at -Os level – LLVM’s inlining is much more aggressive than GCC’s at Os. In fact, GCC at -Os is more comparable to LLVM -Oz. This becomes an issue when porting open source code from GCC to LLVM, e.g. Zephyr.
- Zcmp incompatibility with frame pointer enablement. There are several past discussions on this topic and how Zcmp instruction generation is disabled in LLVM when frame pointer is enabled. It is surprising Zcmp was ratified contradicting the ABI spec. Frame pointer use is very popular, and disabling it is not an option for some projects, yet they want to take advantage of push/pop savings. Creating a new ABI to enable both is problematic because it impacts beyond the compiler, like debuggers and pre-compiled libs. Is anyone proposing a new Zcmp that is compatible with the ABI? How others are coping with this limitation?
- Aditya Kumar [Please review] RFC Improved VPlan-native Path (Outer loop vectorization): RFC: Improved VPlan-native Path
- Are there interesting workloads that can use outer loop vectorization in RISC-V ?
- Kito: Target attribute for function: Moving c-api doc forward? Controversial and unclear part has been removed, only cpu, tune and arch with full arch string and additional extension feature remain.
- Heads up
- AOB