This was the last flag that the PrintOptions bitfield was tracking.
So, this patch is effectively converting that bitfield (and its alias
"PrintOptionsBits") into a new, simpler boolean field named
"isPrintSelectionRBEnabled".
Differential Revision: https://phabricator.services.mozilla.com/D92542
The original commit message for the order files says "It's OK if these files are slightly out of date", and that's true. However, in the 11 months since then, our builds have undergone major changes that affect large numbers of final symbol names, like switching from Frontend to IR PGO, and enabling the new pass manager. I think at this point a refresh wouldn't hurt.
I generated these files by locally creating a "stage 2.5" PGO build that's both `-fprofile-use` _and_ `-finstrument-functions-after-inlining`, and otherwise following the instructions from bug 1444171. Doing this at the `use` stage rather than the `gen` stage lets us get around the problem of mixing IR and Frontend instrumentation. It also gets us a more accurate picture of the final optimizations.
I haven't exhaustively run this through Talos. I did some spot checks, most were within noise, Speedometer maaybe gets 0.6%. I don't think this is worth hogging the talos machines for a full run, we can get the results after landing.
If for no other reason, this is worth doing to reduce 8000 lines of warning LNK4037 (order file refers to a nonexistent symbol) in build logs down to about 15.
Differential Revision: https://phabricator.services.mozilla.com/D72171
Specifically, this renames
* nsTArray_CopyChooser to nsTArray_RelocationStrategy
* the Copy template argument of nsTArray_base to RelocationStrategy
* nsTArray_CopyWithConstructors to nsTArray_RelocateUsingMoveConstructor
* nsTArray_CopyWithMemutils to nsTArray_RelocateUsingMemutils
* DECLARE_USE_COPY_CONSTRUCTORS to MOZ_DECLARE_RELOCATE_USING_MOVE_CONSTRUCTOR
Differential Revision: https://phabricator.services.mozilla.com/D66243
--HG--
extra : moz-landing-system : lando
We're planning on switching to IR-based profiling, so we can't use the
frontend-based instrumentation to collect the order in which functions
are executed...at least not during the build itself. Performance tests
indicate that not having the order information decreases performance
significantly. So we're going to check in static files for Win32 and
Win64 and use those to perform the ordering. It's OK if these files are
slightly out of date; as of this writing, builds that generate and then
use these files complain that ~1/3 of the functions can't be found (!).
We're just trying to do something slightly smarter than whatever the
linker default is.
Differential Revision: https://phabricator.services.mozilla.com/D31132
--HG--
extra : moz-landing-system : lando
Daniel Holbert
Kristen Wright
Henri Sivonen
Bob Owen
David Major
Tetsuharu OHZEKI
Simon Giesecke
Marco Bonardo
Tom Schuster
Ehsan Akhgari
Narcis Beleuzu
Noemi Erli
Emma Malysz
Masatoshi Kimura
Boris Zbarsky
Jonathan Kingston
Nathan Froyd