The advantage of having multiple C compilers has always been broader platform support and competition to improve compiler speed, error messages, and codegen quality. Conspicuously, one complete non-advantage of having multiple C compilers is portability of a codebase between compilers; the C specification contains too much implementation-defined behavior (including undefined behavior) and is too anemic (requiring compilers to come up with nonstandard extensions to support things like assembly and SIMD) for compiler-portability to be anything other than a nightmare for large projects. C projects even have a hard time upgrading to new versions of the same compiler, which helps to explain why so many shops are still using positively ancient versions of GCC.

I had the good fortune to work on a code base that started as a blank emacs buffer and was compiled with both g++ and clang++ from the get go (and built on multiple platforms, with maximal warnings enabled). The two compilers surfaced different bugs in our codebase which, in addition to finding actual (semantic) bugs has been quite valuable for portability and maintainability.

(Also, as others have noted, the existence of clang has really been good for gcc).

We saw significant performance gains when moving from GCC (6) to clang (6). I don't think it'd be particularly hard to switch back at this point; this article provides some solid data for doing so.

Yeah, but to be fair the work to actually enable LTO was very significant (at least as far as we outside the community could see via stuff like the blog post here) and involved a ton of toolchain-specific hackery and work with the clang upstream.

Given that same level of effort (c.f. the article we're discussing) it seems like you could have done as well or better by moving to a more recent gcc instead. Or better, by working with both at coming up with a portable way to get LTO working.

I'm not really concerned with what you use to build (I mean, you have to pick some compiler at the end of the day), just with what seems to be "needlessly tight coupling" between clang/llvm and Firefox in a way that hurts the interoperable toolchain ecosystem.

What are you referring to by "a ton of toolchain-specific hackery" and "a portable way to get LTO working"? It seems like there are very specific things you have in mind, but I'm unclear what bits of work you're referencing. Unless you're thinking of the cross-language LTO work, which is still in progress and is of course clang/llvm-specific? I'd love to see that feature work with GCC, but it's simply not feasible at the present time.

Regardless, that feature being enabled when you're using suitable versions of clang/llvm/rustc doesn't preclude using LTO with other compilers.

I would be happy to help with solving GCC related issues and look into performance regressions relative to clang (I am still in process of looking into -O2 performance and plan to set up talos next)

And even worse, it's generating worse and ridiculously bigger code. So they spend a lot of effort for worse result.

And apparently they don't catch serious problems in their build system on their own (profile feedback pass timing out and truncating data)

Overall not a great result at all for Mozilla. Where is the regression testing for performance? They are not data driven?

"And even worse, it's generating worse and ridiculously bigger code. So they spend a lot of effort for worse result."

GCC aggressively size optimizes cold regions, and LLVM doesn't bother. This would be pretty easy to fix, but outside of binary size, need to prove it actually matters (the test harness here is a pretty darn old CPU)

The "don't catch serious problems in build system" is the bigger worry, imho.

I have re-tested on my skylake notebook and updated the blog. It confirms darn old CPU I use as my benchmark machine. Maybe it is bit more sensitive to the difference which is expected for non-server CPU.

GCC does "almost full LTO" with partitioning, while clang does thinLTO that does make most of code size/speed tradeoffs without considering whole program context, so it may be interesting to get both alternatives closer in code size/performance metrics.

I have got Firefox developer account of level1 and I am looking into official benchmarking architecture which I have now updated to GCC 8 with LTO+PGO.

Regression testing for performance is checked via several test suites (Talos, for instance, with numerous subtests: https://wiki.mozilla.org/Performance_sheriffing/Talos/Tests) and monitored by our ever-dutiful performance sheriffs (https://wiki.mozilla.org/Performance_sheriffing).