2014-07-04 03:28:43 +04:00
|
|
|
# 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/.
|
|
|
|
|
|
2017-01-11 20:00:24 +03:00
|
|
|
TOOLTOOL_DIR=${TOOLTOOL_DIR:-$topsrcdir}
|
|
|
|
|
export MAKECAB=$TOOLTOOL_DIR/makecab.exe
|
2020-01-16 17:14:13 +03:00
|
|
|
export DUMP_SYMS="${MOZ_FETCHES_DIR}/dump_syms/dump_syms.exe"
|
2019-06-20 01:05:52 +03:00
|
|
|
|
|
|
|
|
if [ -z "$USE_ARTIFACT" ]; then
|
2019-12-09 21:03:57 +03:00
|
|
|
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
|
2019-12-10 22:48:04 +03:00
|
|
|
ac_add_options --enable-profile-use=cross
|
2019-06-20 01:05:52 +03:00
|
|
|
ac_add_options --with-pgo-jarlog="${WORKSPACE}/fetches/en-US.log"
|
2019-09-11 00:56:15 +03:00
|
|
|
ac_add_options --with-pgo-profile-path="${WORKSPACE}/fetches/merged.profdata"
|
2019-06-20 01:05:52 +03:00
|
|
|
fi
|
|
|
|
|
fi
|
