> You might wonder if we tried LTO with GCC, or tried upgrading to GCC 8.x. As a matter of fact, I did. Enabling LTO turned up linker errors
So... they just gave up on gcc, and then per the remainder of the blog post spent "3 months" fighting linker behavior to get LTO working on clang? That seems like a surprising asymmetry, and makes me wonder if the reported performance gains weren't the real reason for the switch.
> Considering the expected future advantages from using clang (cross-language inlining with Rust, consistency between platforms), it seemed a better deal to switch to clang than to try to address those issues.
No, they anticipated switching over to clang in the future so rather than spend "3 months" fighting GCC's linker then do it all over again switching to clang, they just switched.
> So... they just gave up on gcc, and then per the remainder of the blog post spent "3 months" fighting linker behavior to get LTO working on clang?
Given that they're trying to align their C++ and Rust build tools -- the latter being based on LLVM -- the lack of interest in solving issues experienced with GCC is understandable. Also, given the complexity of the application and the platform diversity involved spending only "3 months" on such troubles is heroic performance.
The blog post does also say: "Considering the expected future advantages from using clang (cross-language inlining with Rust, consistency between platforms), it seemed a better deal to switch to clang than to try to address those issues."
I wonder how this compares to a native GCC build. I always build Firefox myself (as I do with everything) and is always been noticeably faster than the binary. I hope this doesn't mean there will be problems doing GCC builds in the future.
Probably this refers only to the pre-compiled builds offered by Mozilla? The distribution packagers build Firefox from source before pushing them to the repository so it would make sense to use the default compiler for the distribution.
On a relevant note, is there any linux distribution that defaults to clang instead of GCC? Up until a couple of years ago the kernel would not even build with clang.
I guess having the app update itself may have some appeal for LTS and enterprise distros, where you cannot get the latest-greatest release from the distro vendor. On something like Arch Linux, it's pretty pointless and actually counter-productive: By the time, the package lands in the stable channel of the distro, you know that it works well with all your system libraries because someone tested it.
> You might have read that Mozilla recently switched Windows builds to clang-cl... As of next nightly (as of writing, obviously), all tier-1 platforms are now built with clang with LTO enabled.
Wait they just gave on GCC's because they could not get linker optimizations working... However, they are surprised Clang with linker optimizations was faster than GCC without...
I failed to mention it originally, but updated the post with this: it's worth noting that comparing GCC+PGO vs. clang+LTO or GCC+PGO vs. clang+PGO was a win for clang overall in both cases, although GCC was winning on a few benchmarks. If I remember correctly, clang without PGO/LTO was also winning against GCC without PGO.
I would not say ancient, but yea GCC 6 is getting old. I know GCC has had additional optimizations added since then. Although, I am curious how GCC 7+ was breaking binary compatibility? Calling convention, name mangling what?
> This doesn’t mean GCC is being unsupported. As a matter of fact, we still have automated jobs using GCC for some static analysis, and we also have jobs ensuring everything still builds with a baseline of GCC 6.x.
Did you even read it? Also ~10% improvement in speeds is worth switching, IMO.
