The author has done some excellent work. I would love to make this kind of deep-dive compiler / optimization regression part of my own team's continuous improvement because it is so important to stay on top of, but every time I try to dive into LTO/PGO it ends up getting deprioritized. Articles like this are inspiring and informative.
as someone not familiar with compilation, what's the purpose of moving from GCC to Clang ? especially if performance aren't better ? (I think it's what they are trying to do)
How so? GCC can (and is) used to compile all sorts of proprietary software. I can't imagine a scenario where its license would be any kind of an issue with the toolchain of a Free project.
> clang also has far better error messages than gcc.
This was true a number of years ago, but I believe GCC's diagnostics have gotten much better in response to competition and don't believe it to be true anymore (although my experience is with C code, not C++ — maybe Clang is better there).
Another distinction is that GCC continues to hold a significant lead in producing accurate debuginfo, which is invaluable to me as a developer.
I think both compilers give good error messages (C++14 and C++17). Sometimes one is clearer, sometimes the other, so what I usually do if I can't immediately figure out what the compiler is complaining about is to try the other one and see if that clears things up or at least narrows it down a bit. Works surprisingly often :)
GCC was designed to be extensible and portable (after all it ended up ported to more architectures than any other compiler). The political limitation was more subtle.
Originally FSF did not want to make it easy let GCC store
its intermediate language and read it back. That was because it would let others to build proprietary frontends and back-ends which is against RMS' vision. This has changed and LTO does precisely that (and indeed in addition to technical difficulties this political issue delayed its arrival in GCC). So this political block of extensibility is long gone (and I am happy for that).
A lot has changed in compilation between mid 1980's GCC was started and early 2000's. LLVM design reflects its time. Almost 20 years passed since that and both projects needs to evolve and develop strategies of doing so.
Regardless of the LTO relaxation, I believe it is still the position of the FSF and GCC that any middleware that links in to GCC itself is GPL-infected. Obviously, this is not the case for LLVM/Clang.
Clang has much better error reporting and warnings. It's maybe not enough to switch completely, but worth it to compile in both compilers to catch more bugs. Then you can still release the binaries that are faster and throw away the binaries that are slower.
The difference isn't that large anymore. gcc has also implemented color diagnostics and caret highlighting, and they have continuously added new helpful warnings, e.g. the upcoming -Winit-list-lifetime in gcc 9 (nothing comparable available for clang)
This is awesome. I don't have a dog in the GCC-vs-Clang hunt, but I love love love that the two are leapfrogging each other. It would suck if, say, Clang were so much better than GCC that they stopped doing cool work on it (and vice versa). Everyone benefits from this particular friendly competition!
Great job, both teams. Please keep up the great work!
FWIW, I doubt the GNU project would stop working on GCC, even if it were rarely used. GNU Hurd and similar rarely used projects barrel on under the GNU banner.
The work wouldn't stop, but people would continue to do the same things they know how to do. Friendly competition gives new ideas. Clang basically forced nicer error messages on GCC. Sanitizers started with clang and were ported to GCC.
Not sure if directly related to the article, but curious, if you compare GCC and Clang and review GCC's logic to improve Clang, have you violated a license? Similarly if you assume API is copyrightable and covered by the license, one wonders about violations just reimplementing GCC extensions. (just spitballing because in general something is not a violation that is not pursued as such)
PS: I found it too ironic to mention in the blog, but I had to uninstall mobile firefox to get the two-level application needed to submit a patch :)). For some reason Google authentificator requires over 30MB to take a picture of bar code.
It's ironic that Mozilla evangelizes against browser monoculture, while at the same time Firefox is increasingly using a language that has supports one frontend
(rustc) and one backend (LLVM) only, and it is degrading support for all C++ compilers except one.
This is such an apples-to-oranges comparison that I can't really see how you'd come to that conclusion unless you were already biased against Rust/LLVM/Firefox coming into it. Mozilla is against all browsers, i.e. every single piece of software that can be used to connect to the world-wide web--the most important and influential piece of technology in the last half century, being based on the same codebase. The fact that a browser is compiled by a single compiler is absolutely meaningless, because it still provides another option over other compilers. This doesn't have any bearing on the browser monoculture, and it has no bearing on C++/gcc's feasibility because there are still a thousand other compilers and projects not affected by this. The fact that Rust only works in one compiler is also pretty meaningless because that's not the problem Firefox set out to fix.
And say Mozilla did care about what compiler they were using because it locks them into one of them. They would go ahead and develop a new alternative Rust compiler with an alternative backend. Oh no! They're all using Glibc still! And GTK+! And the X.org monoculture!!!
The current goal behind Firefox is to provide an alternate browser that isn't based on Webkit, not to make sure that every piece of software is equally competitive.
I've been having too much fun the past week or so with my new computer and gentoo --- ldd as my linker, thin LTO, clang 7.0.1 building everything by default. There's far less breakage than you'd imagine.
So this may seem like a stupid question, but I have been doing a lot of work on static compilation for an embedded project, and noticed a huge improvement from adding -ffunction-sections and -fdata-sections plus link-time garbage collection with static linking. Would compiling firefox statically against musl and some static nss provider help?
I sorry if this question is phrased poorly, English is not my first language and I am new to build system issues.
from my limited understand using LTO is a better alternative to -ffunction-sections and -fdata-sections + gc-sections because the compiler and linker has more information. Size reductions are often a little bit better for LTO than for gc-sections. Check this article series: https://lwn.net/Articles/744507/
33 comments
[ 2.7 ms ] story [ 77.1 ms ] threadPretty unsurprising. Same reason why Firefox and Chrome still identify first and foremost as 'Mozilla.'
Whereas llvm/clang was designed as a library to be open and extensible, which lead to a lot of tooling being built around it.
Unrelated to license, clang also has far better error messages than gcc.
This was true a number of years ago, but I believe GCC's diagnostics have gotten much better in response to competition and don't believe it to be true anymore (although my experience is with C code, not C++ — maybe Clang is better there).
Another distinction is that GCC continues to hold a significant lead in producing accurate debuginfo, which is invaluable to me as a developer.
Originally FSF did not want to make it easy let GCC store its intermediate language and read it back. That was because it would let others to build proprietary frontends and back-ends which is against RMS' vision. This has changed and LTO does precisely that (and indeed in addition to technical difficulties this political issue delayed its arrival in GCC). So this political block of extensibility is long gone (and I am happy for that).
A lot has changed in compilation between mid 1980's GCC was started and early 2000's. LLVM design reflects its time. Almost 20 years passed since that and both projects needs to evolve and develop strategies of doing so.
- You can cross-compile from anything to Windows. (To MSVC ABI!)
Right now LLVM is fashionable and gcc is not. Little details, as in actually generating better code, are minor in comparison.
Great job, both teams. Please keep up the great work!
The page won't let me zoom all the way out.
The link is off. This link http://hubicka.blogspot.com/2018/12/even-more-fun-with-build... renders better in general.
PS: I found it too ironic to mention in the blog, but I had to uninstall mobile firefox to get the two-level application needed to submit a patch :)). For some reason Google authentificator requires over 30MB to take a picture of bar code.
And say Mozilla did care about what compiler they were using because it locks them into one of them. They would go ahead and develop a new alternative Rust compiler with an alternative backend. Oh no! They're all using Glibc still! And GTK+! And the X.org monoculture!!!
The current goal behind Firefox is to provide an alternate browser that isn't based on Webkit, not to make sure that every piece of software is equally competitive.
I sorry if this question is phrased poorly, English is not my first language and I am new to build system issues.