gecko-dev/build/mozconfig.win-common

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

16 строки
628 B
Plaintext
Исходник Обычный вид История

# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
TOOLTOOL_DIR=${TOOLTOOL_DIR:-$topsrcdir}
export DUMP_SYMS="${MOZ_FETCHES_DIR}/dump_syms/dump_syms"
if [ -z "$USE_ARTIFACT" ]; then
if [ -n "$TASKCLUSTER_PGO_PROFILE_USE" ]; then
Bug 1572216 - move LTO defaulting into mozconfig.win-common; r=glandium Some recent changes to how we set cross-language LTO for Windows resulted in compilation-time decreases and small performance regressions on a few benchmarks. The changes intended to remove explicit enablement of cross-language LTO for all builds, but rely on shippable builds being built with PGO and moz.configure's clever defaulting of cross-language LTO for PGO'd builds on Windows, which would then enable cross-language LTO for only shippable builds. Obviously something went wrong with those changes. The problem was our defaulting wasn't visible to moz.configure's logic for how to pass command-line options to the JS subconfigure. We set the value (`cross`) after the value for `--enable-lto` has been determined, and the default value is off (that is, `--disable-lto`). Since moz.configure is very thorough in passing configure options down into JS, it dutifully looked at what the default value of `--enable-lto` was supposed to be, and passed `--disable-lto` to JS's configure. There's some evidence that we knew our defaulting was a little sketchy: we'd only attempt cross-language LTO when we were performing the PGO use phase, and only if the value of `--enable-lto` wasn't explicitly passed. Which was a fine idea--you don't want to override what the user was trying to do--but in the case of JS backfired on us: the value *was* coming from the explicitly-passed command-line option of `--disable-lto`. So JS didn't enable any kind of LTO, with attendant consequences. This problem *didn't* happen before the aforementioned change because we were explicitly specifying that `--enable-lto=cross` should be passed in the mozconfig, which ensured that the correct setting was passed into JS. We were just setting `--enable-lto=cross` for *all* builds, which was less than desirable. The easiest way to fix all this is simply to put the `--enable-lto=cross` setting in the Windows mozconfigs, conditional on `MOZ_PGO_PROFILE_USE`. That placement captures the intent of the previous attempt at defaulting, but without the troubles described above: the option explicitly appears on the command line, and moz.configure will correctly pass it through to the JS subconfigure. This also makes our Windows configuration closer to our Linux configuration (the Linux configuration enables cross-language LTO for both PGO phases, which is arguably a bug). Differential Revision: https://phabricator.services.mozilla.com/D41080 --HG-- extra : moz-landing-system : lando
2019-08-09 16:22:08 +03:00
export MOZ_LTO=cross
ac_add_options --enable-profile-use=cross
ac_add_options --with-pgo-jarlog="${MOZ_FETCHES_DIR}/en-US.log"
ac_add_options --with-pgo-profile-path="${MOZ_FETCHES_DIR}/merged.profdata"
fi
fi