Firefox Is Now Built With Clang+LTO Everywhere, Sizable Performance Wins For Linux

[BaronHK]

Also, worth pointing out:

Fedora granted an exception to allow Firefox to be built with Clang.

Unfortunately, they ran with the fake news from Mozilla that Clang builds work better, even though Mozilla never tried running a copy of Firefox that was built with anything newer than GCC 6 against the current version of Clang.

Along the way, it was pointed out that Clang brings its own problems.

Notably,

1. Some security features of the GNU C/C++ Compiler don't work on Clang, but you'd never notice if you just casually build a program because things like Stack Clash Protection are not implemented at all in Clang, and its compatibility with GCC is implementing Stack Clash Protection in a way where the build doesn't fail, but you're actually not protected at all. (It's a no-op.).

D_Fortify_Source=2 apparently doesn't work correctly either.

2. The debuginfos that Clang produces are inferior to GCC, so good luck trying to get usable backtrace data if the program fails.

Thanks to the decision to build with Clang, Fedora's Firefox users are more likely to be successfully attacked by rogue web content and potentially malicious WebExtensions that slip past the Review Process on AMO because Clang doesn't support the security hardening features that are currently enabled in the RPM .spec to build Firefox with GCC.

[BaronHK]

"Mozilla developers did try GCC LTO as well as switching to the newest GCC8 release, but ran into problems."

Actually, in the article you linked to, they said that they had not tried GCC 8. Only GCC 7, and the problem they ran into with GCC 7 was that it broke binary compatibility on old GNU/Linux distributions and that LTO was broken.

BTW, LTO on the Mac is broken right now and there are 77 blocker bugs, including problems with XCode, macOS itself, *and* Clang.

"More details on these exciting compiler advancements for Firefox[...]"

More anti-copyleft bs from Phoronix....

[xpris]

Default Firefox 62 on OpenMandriva Lx 3. This distro build all (almost all) package with Clang from long time. If you want look how Firefox working with Clang just test it. Proof Firefox build with Clang: https://imgur.com/a/fZTRWVo

[ssokolow]

GCC doesn't parse asm statement templates (the string). You need to specify it as an operand and then sure enough it will work. That's proper code. Otherwise it's just a hack.

Yeah. It's pretty standard for compilers to require that inline assembly specify its operands and scratch space separately so the optimizer will know to work around them.

Here's the syntax, as given in the GCC manual:

[FONT=courier new]asm [volatile] ( AssemblerTemplate
                 : OutputOperands
                 [ : InputOperands
                 [ : Clobbers ] ])

asm [volatile] goto ( AssemblerTemplate
                      :
                      : InputOperands
                      : Clobbers
                      : GotoLabels)[/FONT]

[Weasel]

Yes, but it is not hard for GCC to check inline asm statements and check if the "unused" function is not called there. Not sure, does GCC issue warning in this case? If so, yes, Mozilla devs should pay more attention on errors and if they ignore them, GCC has right to remove it.

GCC doesn't parse asm statement templates (the string). You need to specify it as an operand and then sure enough it will work. That's proper code. Otherwise it's just a hack.

But anyway, what is the result of such removal? Broken build because you are too aggresive.

I don't see why a compiler should punish correctly written applications by being "less aggressive" (it will optimize less) because some dumbies use hacks they don't understand the consequences of.

[pyler]

Your fallacy is that you think this is "correct code" when it's not.
...

Yes, but it is not hard for GCC to check inline asm statements and check if the "unused" function is not called there. Not sure, does GCC issue warning in this case? If so, yes, Mozilla devs should pay more attention on errors and if they ignore them, GCC has right to remove it.

But anyway, what is the result of such removal? Broken build because you are too aggresive.

[hubicka]

Have these been reported to Mozilla?

The benchmarks was done by Mozilla folks, so yes.

[Weasel]

If the correct code is miscompiled/not compiled by GCC with LTO, you recommend us to annotate code with attribute ((used)) and other attributes?

Your fallacy is that you think this is "correct code" when it's not.

There's no guarantee in the standard that a variable or function or whatever that is not used will even exist at all in the output. If you use top level asms and other hacks like that and don't mark them as used, GCC will remove them, rightfully. The attribute is meant to tell the compiler that the thing in question is actually used, despite nothing referencing it in some way (except for hacks of course), so it should not discard it.

Removing unused stuff is normal compiler behavior, and has nothing to do with LTO. It breaks with LTO because, with LTO, the compiler can truly see that it really is not used (since it can "see" in all the source files). This stinks of bad design to me: designed by someone who thinks that LTO doesn't exist and that all files are compiled "separately".

In other words: the code is just bad and makes bad assumptions and whoever wrote it should feel bad.

[carewolf]

If the correct code is miscompiled/not compiled by GCC with LTO, you recommend us to annotate code with attribute ((used)) and other attributes?

No, nobody is going to waste time to do it.

The code is wrong. The only reason you don't get the same failures with clang is because they optimize less aggressively, but that can change any release. Fixing bugs now is better than waiting for them to become a problem.

[pyler]

If the correct code is miscompiled/not compiled by GCC with LTO, you recommend us to annotate code with attribute ((used)) and other attributes?

No, nobody is going to waste time to do it.