LLVM Clang 16 vs. GCC 13 Compiler Performance On Intel Raptor Lake

[Volta]

Does clang compile kernel yet? If not it can lick GCC boots.

[Volta]

So the libjxl got compiled with -O2 for gcc, and -O3 for clang?.. And why use -O3 -march=native -O2 on gcc? It seems the last -O2 is a bug.

Nice catch. It seems someone's cheating here.

[discordian]

Does clang compile kernel yet? If not it can lick GCC boots.

There are already features like CFI_CLANG that you wont get without clang, the trajectory is clear.

[marios]

Does clang compile kernel yet? If not it can lick GCC boots.

Yes, and for some stupid reason only clang lto is mainlined. So, it not only compiles, but it has the potential to run faster.

[marios]

It might or it might not be a core gcc problem. The problem might be at the raptor lake code. One compiler had already screwed up Adler lake's big-little in the past. It might be a similar situation.

[hubicka]

Different compilers make different choices for what optimization levels mean. If GCC’s developers do not want to enable optimizations as part of them, then it is fair to let benchmarks reflect that.

-fno-semantic-interposition is not an optimization. It is flag telling compiler to ignore ELF interposition rules. Doing so enables other optimizations (such as inlining, constant propagation etc.). GCC at -O3 optimization levels should be standard conforming (with few well justified exceptions), so enabling semantic interposition would need agreement outside of GCC community on updating ELF standard.

-fsemantic-interposition is similar in nature to -ffast-math and other options we have to be more lenient about standards.
Just because some compiler do equivalent of -ffast-math as part of -O3 does not mean that GCC should do it.
Just like -ffast-math, -fsemantic-interposition is now enabled by -Ofast.

Semantic interposition is an useful feature, but I would personally not be offended if was opt-in rather then opt-out, since shared libraries are much more complex then what ELF was originally designed for. See discussion at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100937
Sime distros compile with -fno-semantic-interposition by default.

For benchmarking the quality of compiler optimizations it is however quite important to be sure that all compilers considered adhere to similar set of rules. Sadly we tend to diverge between clang and GCC in what individual optimization settings really means.

[discordian]

-fno-semantic-interposition is not an optimization. It is flag telling compiler to ignore ELF interposition rules. Doing so enables other optimizations (such as inlining, constant propagation etc.). GCC at -O3 optimization levels should be standard conforming (with few well justified exceptions), so enabling semantic interposition would need agreement outside of GCC community on updating ELF standard.

The example you provided contained a function that is not marked to be exported, so ELF interposition is not an argument. Which functions are eligible to be exported is not standardized, the sane thing to do would add a macro notifying that. gcc leaves valid optimizations on the table, unless your example is missing some crucial details.

(in an ideal world, the information how the symbol is to be used comes from the linker and not marks in the source-code, requiring at least some mild form of LTO or turning the build-process upside-down)

[hubicka]

The example you provided contained a function that is not marked to be exported, so ELF interposition is not an argument. Which functions are eligible to be exported is not standardized, the sane thing to do would add a macro notifying that. gcc leaves valid optimizations on the table, unless your example is missing some crucial details.

(in an ideal world, the information how the symbol is to be used comes from the linker and not marks in the source-code, requiring at least some mild form of LTO or turning the build-process upside-down)

Both GCC and Clang require -fvisibility=hidden to not export the symbol. Making -fvisibility=hidden a default would break a lot of existing packages that does not mark exported symbols.

If you compile the testcase with -fvisibility=hidden, GCC will optimize return to 1. GCC has quite careful logic about what can be interposed:

1. Interposition is possible only with -fpic or weak symbols
2. Inline functions or comdats can not be be semantically interposed (but can be interposed to different, equivalent definition possibly optimized with different optimization flags or compiled by other compiler)
3. With -flto, one can use resolution file to hide symbols at link-time (as you suggest) and GCC will be informed about this (it will see that the symbol is not LDPR_PREVAILING_DEF_IRONLY and optimize accordingly)
4. If you compile with -fpic but link resulting object into non-shared binary, GCC will know this from linker plugin too and disable inteprosition.

Problem is that Clang exports the symbol in my testcase yet does not expect the interposition to happen. This is not considered to be a good idea in GCC (as discussed few times at the mailing-list).

[discordian]

Both GCC and Clang require -fvisibility=hidden to not export the symbol. Making -fvisibility=hidden a default would break a lot of existing packages that does not mark exported symbols.

Even more packages wont care, and the remaining deserve to be fixed (the C/C++ standard knows nothing about public/hidden symbols, and depending on compiler historic compiler behavior aint a good idea). TBH, I thought the visibility default were a configuration option when compiling gcc, seems I remembered this wrong - using mostly toolchains with wrappers and buildsystems where -fvisibility=hidden is used transparently.

If you compile the testcase with -fvisibility=hidden, GCC will optimize return to 1. GCC has quite careful logic about what can be interposed:

1. Interposition is possible only with -fpic or weak symbols
   

1. And that comes with a cost: inefficent code and relocations.
   

2. Inline functions or comdats can not be be semantically interposed (but can be interposed to different, equivalent definition possibly optimized with different optimization flags or compiled by other compiler)
3. With -flto, one can use resolution file to hide symbols at link-time (as you suggest) and GCC will be informed about this (it will see that the symbol is not LDPR_PREVAILING_DEF_IRONLY and optimize accordingly)