Pale Moon forum

I surfed around on the forums trying to find if there was any particular reason UXP does not use PGO and/or why Mozilla removed it from their Makefile.
Other than cited stability concerns and the lack of manpower (per Mozilla, even though they actually still patch it themselves on Windows builds), I didn't find much.

PGO Builds (after patching the Makefile to restore the compile time option) do still work in the tree, up until the linker haults with undefined reference to `gfxShapedWord* gfxFont::GetShapedWord. This was a known issue that occured in GCC6+ and was fixed in m-c 1389436.

Per the bug report:

The reason this happens is that there's a template method declared in gfxFont.h and defined in gfxFont.cpp, and used in both gfxFont.cpp and gfxTextRun.cpp. The split was done 3 years ago, and we've been lucky until now, that the instantiation of the template in gfxFont.cpp was not optimized out... until GCC 6 PGO, which, apparently, happily inlines the function in gfxFont.cpp, such that there's nothing left for gfxTextRun to find.

Applying the patch with minor modifications allows PGO to again build.
If this is a feature we would like to provide teir3 support for in the tree I can get an Issue/PR going. Obviously this is not needed for all applications, and is primarily a GNU/Linux optimization. I was just curious if there was any downside to patching our applications with PGO support.

Putting in that minimal patch to make it PGO-capable is fine, but you have to understand that building with PGO is untested, will not be tested as part of our normal development cycles, and will likely cause serious drawbacks because you are throwing out overall speed optimizations of the code base for the select routines that are being exercised in the profiling run. It's not recommended for any UXP-based application.

The crux of the matter is that PGO is designed for small programs with limited code size that greatly benefit from making very specific optimizations of code based on the practical use of it when run. On a program of UXP's size, you'll end up with maybe 0.5% of the functions speed optimized in a PGO build, and the rest being size-optimized. If you use overall speed optimization (/O2 and friends) then every function is evaluated for speed optimization, not just the select exercised elite few that happen to be spun 100k+ times in the profiling benchmarks, although it won't be done as aggressively (often disproportionaly unrolled, etc.).

In addition, you are pushing the limits of the linker when trying to use PGO with UXP's code size (having literally billions of instructions to consider when processing the recorded profile), no matter which one you are using, and any, even the slightest, compiler/linker bug will likely manifest itself as a stability problem. The way these bugs manifest themselves may be completely non-obvious and can have you hunt down a specific issue for weeks before realizing it was a linker bug, not a code bug (e.g. a debug build may not manifest the issue at all even if also PGOed). Mozilla has a long track record of having to exclude specific source files from PGO profiling for this very reason.

DO NOT trust benchmarking scores because Mozilla has long since cheated benchmarking with PGO by explicitly running benchmarking routines in their profiling run (!!), forcing the compiler to aggressively optimize those specific routines to get better scores with the drawback of dropping optimization on everything else.

Then you should note that there are several competing compiler techniques at work when you use LTO or PGO on our current tree. Unified compilation is in direct conflict with using LTO, for example. I do plan to reintroduce LTO (/GL /LTCG or the gcc equivalent) eventually, once unified building has been stripped out to a sufficient degree. PGO, however, will never be adopted for any of our main applications because of what I explained above.

It's funny, I am sure I said a condensed version of this just yesterday. Strange the way your mind can play tricks on you like that.

New Tobin Paradigm wrote: ↑

2019-07-23, 22:57

It's funny, I am sure I said a condensed version of this just yesterday. Strange the way your mind can play tricks on you like that.

If I remember correctly, someone else asked the same thing something like two or three months ago. Though it was on Github (again if I'm not mistaken.)