We did some benchmarking and saw a 3% increase in the instruction counts for all benchmarks with -fno-omit-frame-pointer. Shorter compile times is a really important feature for clang/llvm, so we can't afford to fall behind other Linux distributions (or users manually building clang) in this area. As a result, I'm going to propose that the LLVM sub-projects packaged for Fedora opt out of the -fno-omit-frame-pointer change: llvm, clang, lld, lldb, compiler-rt, libcxx, libcxxabi, libomp, python-lit, llvm-unwind, flang, mlir, llvm-bolt, libclc, llvm-test-suite, polly See https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer Here are the benchmark results: http://llvm-compile-time-tracker.com/compare.php?from=7504e9a19346b33fd2e0fcdcbd43ecee3d676b86&to=62b69b2e10d7b0eb48c13febac447d76d89d192d&stat=instructions:u
Are we certain that the instruction count increase translates directly to noticeable increases in compile times? Looking at the other metrics on the page you linked, it seems more of a wash whether there's a noticeable slowdown caused by building with frame pointers. It'd be great if we could ensure that there's a direct impact on compilation times before opting LLVM out. I fully expect there to be a slowdown though, since in my own benchmarking with gcc built with frame pointers, compiling the kernel turned out to be roughly 2% slower. I understand that short compilation times are important, but given the profiling improvements made possible by building with frame pointers, a 2% slowdown in compilation speed seems worth it if we look at the improved profiling experience made possible by building with frame pointers. For the compiler packages themselves, it's not a huge problem if they opt out, since it'll only mean we can't profile the compiler binaries. However, I'm a bit more worried about opting out libcxx and the other libraries, since that means all packages linking against these libraries won't be able to do proper stack unwinding due to the missing frame pointers in these libraries. Can we at least reconsider the opt out for the library packages? Finally, were these benchmarks done on LLVM built with LTO? I expect that building LLVM with LTO enabled would improve the results due to more code being inlined, reducing the number of frame pointer instructions that need to be executed.
(In reply to Daan De Meyer from comment #1) > Are we certain that the instruction count increase translates directly to > noticeable increases in compile times? Looking at the other metrics on the > page you linked, it seems more of a wash whether there's a noticeable > slowdown caused by building with frame pointers. It'd be great if we could > ensure that there's a direct impact on compilation times before opting LLVM > out. I fully expect there to be a slowdown though, since in my own > benchmarking with gcc built with frame pointers, compiling the kernel turned > out to be roughly 2% slower. Instruction count is a stable and consistent way we have for measuring performance changes. It's true that it may not correlate 1:1 to a runtime difference, but this is the metric we use for evaluating changes in llvm and 3% is considered a regression. Trying to get accurate timing results is very difficult and depends on a lot of factors including CPU type, VM vs no VM, etc. and we just don't have the resources to set up the same kind of automation for these kinds of metrics. Would you be able to do a benchmark of clang using the same method you used for gcc? > > I understand that short compilation times are important, but given the > profiling improvements made possible by building with frame pointers, a 2% > slowdown in compilation speed seems worth it if we look at the improved > profiling experience made possible by building with frame pointers. For the > compiler packages themselves, it's not a huge problem if they opt out, since > it'll only mean we can't profile the compiler binaries. There are already a lot of people that are profiling and trying to improve the performance of clang/llvm without this Fedora change. I also feel like there are a lot of assumptions that profiling will be able to clearly identify what is slow and that fixing it will be easy. > However, I'm a bit more worried about opting out libcxx and the other libraries, since that > means all packages linking against these libraries won't be able to do > proper stack unwinding due to the missing frame pointers in these libraries. > Can we at least reconsider the opt out for the library packages? > Which other libraries besides libcxx are you concerned about? > Finally, were these benchmarks done on LLVM built with LTO? I expect that > building LLVM with LTO enabled would improve the results due to more code > being inlined, reducing the number of frame pointer instructions that need > to be executed. Yes, it mentions in the configuration name above the tables it the compiler was built with LTO or not.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
All packages except python-lit, libclc, and llvm-test-suite have opted out of -fno-omit-frame-pointers. For those 3 packages, the -fno-omit-frame-pointers flag is not very impactful.