We only enabled hardening with an explicit --enable-hardening because we
needed a patch. That patch was applied to upstream clang 8.0.1, so we
can now enable automatically whenever using the right version.
The explicit --enable-hardening was also not applied to win64-aarch64
debug builds, and this indirectly enables it there too, matching other
debug builds. This also avoids breaking debug builds when enabling
winchecksec on cross builds.
Differential Revision: https://phabricator.services.mozilla.com/D68161
--HG--
extra : moz-landing-system : lando
Several developers have reported hangs on native Mac builds. I think we should disable the flag on Mac hosts. Even if we could fix the current hangs, without coverage in CI for this build configuration, we're asking for more trouble down the road.
Differential Revision: https://phabricator.services.mozilla.com/D67007
--HG--
extra : moz-landing-system : lando
It turns out clang-cl adds an explicit /DEFAULTLIB:/full/path/to/runtime
to all the .obj it creates, which makes the linker add it on its own.
Differential Revision: https://phabricator.services.mozilla.com/D66368
--HG--
extra : moz-landing-system : lando
LLVM's new pass manager has been in the works for several years and has better optimization (sometimes much better) than the legacy pass manager. I think it's in good enough shape for us to try at this point.
While we only really need the new pass manager for shippable builds, as a general principle I'd like to use it as much as possible, to help catch bugs for upstream. Therefore this patch enables the new pass manager by default for all clang builds, with the only exceptions being compilers older than version 9, and xcode clang where we can't trust the version number. There isn't a specific problem with older versions; I just don't want to sign up for the support cost of debugging people's local builds that may be fixed already.
I don't expect it to be necessary, but just in case, an opt-out is available via `ac_add_options --disable-new-pass-manager`.
Differential Revision: https://phabricator.services.mozilla.com/D66109
--HG--
extra : rebase_source : 91df800146700e4958b8e645ebbd3cf7b11a2f1e
extra : source : 2f5aba2e2c099a1df26e3444ccec2be0b4ff4613
LLVM's new pass manager has been in the works for several years and has better optimization (sometimes much better) than the legacy pass manager. I think it's in good enough shape for us to try at this point.
While we only really need the new pass manager for shippable builds, as a general principle I'd like to use it as much as possible, to help catch bugs for upstream. Therefore this patch enables the new pass manager by default for all clang builds, with the only exceptions being compilers older than version 9, and xcode clang where we can't trust the version number. There isn't a specific problem with older versions; I just don't want to sign up for the support cost of debugging people's local builds that may be fixed already.
I don't expect it to be necessary, but just in case, an opt-out is available via `ac_add_options --disable-new-pass-manager`.
Differential Revision: https://phabricator.services.mozilla.com/D66109
--HG--
extra : moz-landing-system : lando
With this and all the previous changes, the necessary mozconfig for
local cross-builds only contains DIA_SDK_PATH, WINDOWSSDKDIR and
--target.
Differential Revision: https://phabricator.services.mozilla.com/D65295
--HG--
extra : moz-landing-system : lando
This was cargo culted from the autoconf equivalent, and while it makes a
command that does "$(PROG) foo" work because it becomes ": foo", that
may or may not actually be a desirable outcome.
OTOH, we do have some places where there are some "ifdef PROG" that are
just plain wrong when PROG is always actually set.
One place I do know that does check if the value is not ":" is for
OBJCOPY, which is still set from autoconf.
All in all, looking at all the check_prog(allow_missing=True) we have in
python configure, it doesn't seem anything is checking for ":", and that
doesn't seem like the right status quo.
Differential Revision: https://phabricator.services.mozilla.com/D65276
--HG--
extra : moz-landing-system : lando
- Remove the separate option() for MT, because it dates back from when
we needed `MT` not being an absolute path, but that hasn't been true
since bug 1290040.
- Extend what was done in bug 1617794 to MT, although the long term move
is to not rely on MT at all.
- Patch leftovers from bug 1613799.
Differential Revision: https://phabricator.services.mozilla.com/D64712
--HG--
extra : moz-landing-system : lando
Depending on the target, the assembler for Windows builds is one of ml,
ml64, or armasm64. Only for the latter currently are we looking for the
assembler with the .exe extension. All of them should be looked for the
same way, and we pick including the extension.
Differential Revision: https://phabricator.services.mozilla.com/D64260
--HG--
extra : moz-landing-system : lando
We're feeding old-configure with compiler and assembler as found by
python configure via ac_cv_* variables (abusing the autoconf cache).
When doing so, and when the assembler was provided via an environment
variable, while python configure resolves the path, old-configure
doesn't get the resolved path, because we're currently passing it the
path that was passed via the environment.
Now pass the resolved path instead.
Differential Revision: https://phabricator.services.mozilla.com/D64258
--HG--
extra : moz-landing-system : lando
While this works on Windows, because os.pathsep is `;`, it actually
doesn't work on non-Windows, because clang-cl is still expecting `;`,
but os.pathsep is `:`.
Differential Revision: https://phabricator.services.mozilla.com/D62862
--HG--
extra : moz-landing-system : lando
After a C++ language version bump, It's possible to wind up in
situations where we are using a new enough compiler version, but the
libstdc++ version in use is not new enough to support new language
features: self-compiled clang with system libraries, clang from `mach
bootstrap` prior to C++ language version bump (and thus including a new
libstdc++ with the boostrapped clang), etc.
Previously, such a situation would mean that things would work fine, and
then start breaking as soon as new library features started to be used.
Let's try to catch the problem earlier, when the update happens, by
verifying that the libstdc++ version is at least as new as the GCC
version we're requiring.
Differential Revision: https://phabricator.services.mozilla.com/D57516
--HG--
extra : moz-landing-system : lando
I need this to support individual #[cfg] in enum variants, which is used for
Image::PaintWorklet.
Differential Revision: https://phabricator.services.mozilla.com/D62160
--HG--
extra : moz-landing-system : lando
fts.h is also missing on musl. Since the Solaris fallback implementation
does not use any non-standard functions, use that as the fallback when
the FTS interface is not available.
Also, fix an issue with the readdir implementation. Previously, the
absolute directory path was passed to the recursive add_dir_entries()
call, which would then prepend install path again.
Differential Revision: https://phabricator.services.mozilla.com/D61407
--HG--
extra : moz-landing-system : lando
v0.12.2 at least is needed to have proper v2 lockfile support.
But v0.13.0 contains extra fixes, and features that wgpu and the style system
plan to use, so let's just update to that.
Differential Revision: https://phabricator.services.mozilla.com/D61334
--HG--
extra : moz-landing-system : lando
It generates a lot of noise and we don't want to fix them. In particular, all
the cycle collector macros are like this.
Differential Revision: https://phabricator.services.mozilla.com/D59646
--HG--
extra : moz-landing-system : lando
This gets rid of the last use of the 'which' module left in the tree. So not
only will this help 'configure' become a little more Python 3 compatible, but
we can now remove 'third_party/python/which'.
Differential Revision: https://phabricator.services.mozilla.com/D37427
--HG--
extra : moz-landing-system : lando
This gets rid of the last use of the 'which' module left in the tree. So not
only will this help 'configure' become a little more Python 3 compatible, but
we can now remove 'third_party/python/which'.
Differential Revision: https://phabricator.services.mozilla.com/D37427
--HG--
extra : moz-landing-system : lando
The doubling of `when` is needed: the `try_run` when ensures that we
only execute the compiler on OS X, and the `@depends` when ensures that
we don't look at the `None` result (which would normally indicate
failure) on non-OS X hosts.
Differential Revision: https://phabricator.services.mozilla.com/D57636
--HG--
extra : moz-landing-system : lando
This is needed to support min() / max() / clamp(), as LengthPercentage will have
a potential heap allocation and the current copy-assignment operators just do
bitwise copies.
Differential Revision: https://phabricator.services.mozilla.com/D57300
--HG--
extra : moz-landing-system : lando
-Wempty-init-stmt is a new clang diagnostic that diagnoses empty C++17 init-statements of if, switch, and range-based for statements:
void test() {
if(; // <- warning: init-statement of 'if' is a null statement
true)
;
switch (; // <- warning: init-statement of 'switch' is a null statement
x) {
...
}
for (; // <- warning: init-statement of 'range-based for' is a null statement
int y : S())
;
}
Differential Revision: https://phabricator.services.mozilla.com/D54866
--HG--
extra : moz-landing-system : lando
Make the $PYTHON3 build var point to a full virtualenv bootstrapped with
the same libraries as the $PYTHON Python 2 build var. This allows us to
upgrade build tasks from $PYTHON to $PYTHON3.
This patch adds some debug logging and documentation to the Python
2 virtualenv so that it is easier to diagnose issues that may arise
from running two different Python interpreters in re-entrant
multiprocess routines.
Differential Revision: https://phabricator.services.mozilla.com/D50819
--HG--
extra : moz-landing-system : lando
Nothing looks at the value of this option. We seem to have settled on the `--enable-profile-{generate,use}=cross` approach instead.
Differential Revision: https://phabricator.services.mozilla.com/D56588
--HG--
extra : moz-landing-system : lando
This includes more bitflag operators, which means we can remove some slightly
ugly code.
Differential Revision: https://phabricator.services.mozilla.com/D56308
--HG--
extra : moz-landing-system : lando
Local PGO builds now use 3-tier machinery under the hood. Instead of a
single object directory that gets cleaned in between the instrumented
and profile-use builds, now the instrumented build uses a separate
'${objdir}/instrumented' directory. This makes it easier to handle
within mach since we can drive the two builds with environment variables
and keep all build artifacts separate, without needing to do manual
cleanup in between.
Differential Revision: https://phabricator.services.mozilla.com/D50098
--HG--
extra : moz-landing-system : lando
In automation this is normally handled by mozconfigs, but we should
disable it automatically during the profile-generate stage for users if
they have LTO enabled in their mozconfig while doing a 3-tier PGO build.
Differential Revision: https://phabricator.services.mozilla.com/D50097
--HG--
extra : moz-landing-system : lando
This change does not fully enable C++17, as we still need standard
library support from some platforms.
Differential Revision: https://phabricator.services.mozilla.com/D54202
--HG--
extra : moz-landing-system : lando
This change does not fully enable C++17, as we still need standard
library support from some platforms.
Differential Revision: https://phabricator.services.mozilla.com/D54202
--HG--
extra : moz-landing-system : lando
Make the $PYTHON3 build var point to a full virtualenv bootstrapped with
the same libraries as the $PYTHON Python 2 build var. This allows us to
upgrade build tasks from $PYTHON to $PYTHON3.
This patch adds some debug logging and documentation to the Python
2 virtualenv so that it is easier to diagnose issues that may arise
from running two different Python interpreters in re-entrant
multiprocess routines.
Differential Revision: https://phabricator.services.mozilla.com/D50819
--HG--
extra : moz-landing-system : lando
Detect if Unix utilities on win32 are being picked up from a foreign
installation of MinGW, such as the tools packaged with Git for Windows.
If autoconf dies during `./mach configure` and foreign tools are found
in $PATH then warn the user that their $PATH may need to change to fix
the problem.
Differential Revision: https://phabricator.services.mozilla.com/D52960
--HG--
extra : moz-landing-system : lando
Detect if Unix utilities on win32 are being picked up from a foreign
installation of MinGW, such as the tools packaged with Git for Windows.
If autoconf dies during `./mach configure` and foreign tools are found
in $PATH then warn the user that their $PATH may need to change to fix
the problem.
Differential Revision: https://phabricator.services.mozilla.com/D52960
--HG--
extra : moz-landing-system : lando
We need this for "full" C++17 support (everything is supported, but some
C++17 features still have bugs) and this change also brings Linux into
parity with our Mac requirements.
MANUAL PUSH: build toolchains on inbound to avoid clogging autoland
Differential Revision: https://phabricator.services.mozilla.com/D51450
When running Cargo on Windows, `HOST_LINKER` is required by
`cargo-host-linker.bat`. So we should use windows.configure to set HOST_LINKER
when host OS is Windows and target OS isn't Windows.
Differential Revision: https://phabricator.services.mozilla.com/D37241
--HG--
extra : moz-landing-system : lando
Restore the env= argument to the subprocess.Popen() call that runs
autoconf in old.configure. The argument appears to have been removed by
accident in changeset f47e966507eb.
Differential Revision: https://phabricator.services.mozilla.com/D52293
--HG--
extra : moz-landing-system : lando
When we first enabled ThinLTO on our builds, we got great performance gains, but also large size increases due to aggressive inlining. There is an LLVM option called -import-instr-limit that limits the size of functions that may be imported (the threshold is subject to modification by PGO). Chromium found a good balance between speed and performance by using a value of 10. In initial testing, on Windows and Linux that value can save us many megabytes from libxul without noticeable speed regressions. For Mac, which doesn't yet have PGO, we have to use a higher limit to avoid over-restricting the optimizer which caused slowdowns on my try pushes.
Differential Revision: https://phabricator.services.mozilla.com/D51463
--HG--
extra : moz-landing-system : lando
It's nicer to have everything in one place, and because we support
clang-cl, we can have a single definition for the error flag too.
Differential Revision: https://phabricator.services.mozilla.com/D45705
--HG--
extra : moz-landing-system : lando
The option was removed entirely several months ago, and this bit was missed.
Differential Revision: https://phabricator.services.mozilla.com/D46296
--HG--
extra : moz-landing-system : lando
Getting rid of unneeded code and having fewer global defines are both
worthy things.
Differential Revision: https://phabricator.services.mozilla.com/D45726
--HG--
extra : moz-landing-system : lando
A previous patch defined `_LIBCPP_HIDE_FROM_ABI` to the empty string.
This definition worked for normal (opt/debug) builds, but
PGO-instrumented builds fell over with some linker errors. A closer
look at the definition of `_LIBCPP_HIDE_FROM_ABI`:
```
#ifndef _LIBCPP_HIDE_FROM_ABI_PER_TU
# ifndef _LIBCPP_HIDE_FROM_ABI_PER_TU_BY_DEFAULT
# define _LIBCPP_HIDE_FROM_ABI_PER_TU 0
# else
# define _LIBCPP_HIDE_FROM_ABI_PER_TU 1
# endif
#endif
#ifndef _LIBCPP_HIDE_FROM_ABI
# if _LIBCPP_HIDE_FROM_ABI_PER_TU
# define _LIBCPP_HIDE_FROM_ABI _LIBCPP_HIDDEN _LIBCPP_INTERNAL_LINKAGE
# else
# define _LIBCPP_HIDE_FROM_ABI _LIBCPP_HIDDEN _LIBCPP_EXCLUDE_FROM_EXPLICIT_INSTANTIATION
# endif
#endif
```
says that there are two macros involved there: one to set hidden visibility
(which we don't want), and another to exclude the function definition
from explicit instantiation. The semantics of this are not obvious (the
clang documentation only documents this attribute in terms of C++
templates; the particular case we're interested in sets the attribute on
normal function definitions). But roughly, what this does is that it
forces the compiler to see that an equivalent function definition is
provided external to the compilation unit, so it doesn't have to keep
the annotated function definition around.
Differential Revision: https://phabricator.services.mozilla.com/D45073
--HG--
extra : moz-landing-system : lando
If the run task generates bad profile data, the merge step in the
profile-use task will fail. However, retrying the profile-use task
doesn't fix the problem, and there isn't a straightforward way to retry
the run task in this situation. Instead we can add a clang toolchain to
all the run tasks, and perform the merge there.
This means the output from the run task will always be a successfully
merged file called 'merged.profdata', and we no longer need to perform
the merge as part of the profile-use build as a GENERATED_FILES step.
Depends on D45262
Differential Revision: https://phabricator.services.mozilla.com/D45263
--HG--
extra : moz-landing-system : lando
This is needed in the following patch, but the diff is more clear with
this split out.
Differential Revision: https://phabricator.services.mozilla.com/D45262
--HG--
extra : moz-landing-system : lando
One less thing for configurations to vary is a good thing. This change
also means that when we do NDK bumps that introduce some kind of weird
incompatible change, configuration with a newly-pulled tree and an old
NDK halts at configure, rather than giving weird build errors.
Differential Revision: https://phabricator.services.mozilla.com/D44705
--HG--
extra : moz-landing-system : lando
We define some libc++-internal macros to avoid conflicts between the way
we do symbol visibility and the way libc++ expects visibility to work.
Newer NDK versions use a newer libc++ which changes the way the macro we
were using works. To enable building with newer libc++ versions, let's
also define macros appropriate to those versions as well.
Differential Revision: https://phabricator.services.mozilla.com/D44510
--HG--
extra : moz-landing-system : lando
We have an `ndk_version_major` and an `ndk_version_minor` that have a
lot of duplicated code in them. We could factor them into a single
function, but it seems better to just pull their logic into `ndk_version`
directly, rearranging that function to be IMHO more understandable.
Differential Revision: https://phabricator.services.mozilla.com/D44506
--HG--
extra : moz-landing-system : lando
Also don't pass universal_newlines to check_cmd_output. That was added
to make python 3 happier when check_cmd_output still returned bytes, to
hint subprocess to return a unicode string, but now that
check_cmd_output does the decoding, that's not needed anymore.
Differential Revision: https://phabricator.services.mozilla.com/D43205
--HG--
extra : moz-landing-system : lando
This change looks a lot more complicated than it actually is.
The motivating issue is that on x86-64 android, the NDK uses gold as its
default linker, and on this platform gold has some bugs in how it handles
`.note.*` sections that lead to `strip` and `objcopy` produce invalid
binaries...or at least invalid binaries according to `elfhack`. When
`elfhack` complains, the build stops, which is suboptimal. Instead, let's
use bfd `ld`, which doesn't have these problems.
Except that when we make the change to provide `--enable-linker` with a
platform-specific default, the lint configure tests complain that the
provided help string is not using the proper format. So we tack on the
sekret `{|}` string to satisfy the linter.
Differential Revision: https://phabricator.services.mozilla.com/D43098
--HG--
extra : moz-landing-system : lando
For some reason, cargo incremental doesn't work as well as it should,
and doesn't perform as well as sccache does. So when building with
sccache, disable cargo incremental. This brought a no-change clobber
build with 100% cache from 3:50 to 2:05 on a beefy AWS instance I was
testing this with.
Differential Revision: https://phabricator.services.mozilla.com/D43188
--HG--
extra : moz-landing-system : lando
Bug 1575135 changed check_cmd_output to return unicode strings, but a
couple places were already trying to do their own decoding, which now
can fail. Remove those.
Interesting the decoding was previously broken on Windows, this
actually fixes it (the output of hg config is not actually utf-8 on
Windows).
Differential Revision: https://phabricator.services.mozilla.com/D43044
--HG--
extra : moz-landing-system : lando
The configure sandbox has wrapped subprocess methods to add its own
encoded environment if none is provided, since bug 1520394. It only
makes sense that it normalizes the environment that comes in too,
avoiding caller in the configure sandbox to have to do it themselves.
OTOH, and while we're here, none of get_cmd_output, old_configure or the
sandbox were actually using the right encoding for this conversion, so
fix the configure sandbox to use the right one, and make it stop using
encode(), which does deep recursion that is not necessary here, and that
I'm trying to remove entirely.
Also while here, remove an unused import of encode().
Differential Revision: https://phabricator.services.mozilla.com/D42608
--HG--
extra : moz-landing-system : lando
There are a few problems with the strategy currently used to find the
rust target. For example, we don't find a target for arm freebsd, and we
pick the wrong target for armel linux. Both are related to how things
currently work when multiple targets have the same (cpu, endianness,
os).
So, to derive the rust target, we now use a more fine-grained approach.
Differential Revision: https://phabricator.services.mozilla.com/D41481
--HG--
extra : moz-landing-system : lando
This warning, new in clang 9, is noisy about patterns like:
```
unsigned long x = ...
if (x > 4294967295)
```
The condition is always false on 32-bit and LLP64 systems, but on LP64 it's a valid test.
Differential Revision: https://phabricator.services.mozilla.com/D42346
--HG--
extra : moz-landing-system : lando
Disable -ftrivial-auto-var-init for DllBLocklistWin.cpp with clang-cl because the file's interceptions happen so early in the main process that the loader hasn't yet resolved the import of memset (used by -ftrivial-auto-var-init) from vcruntime140.dll.
Disable -ftrivial-auto-var-init on Linux32 because it causes some xpcshell test failures.
Differential Revision: https://phabricator.services.mozilla.com/D42273
--HG--
extra : moz-landing-system : lando
As a consequence, we can replace the encoded_open function that did the
same in an opt-in manner.
Differential Revision: https://phabricator.services.mozilla.com/D42605
--HG--
extra : moz-landing-system : lando
Because most calling places in python configure don't actually want to
deal with encodings, although in practical terms they should, make
get_cmd_output handle it itself.
Places that explicitly do want bytes can keep using subprocess directly.
Differential Revision: https://phabricator.services.mozilla.com/D42604
--HG--
extra : moz-landing-system : lando
This is not something that happens under normal circumstances, but it
can happen when you go fancy and run multiple configures in parallel
with different objdirs, and old-configure doesn't exist in the first
place ; then one configure may overwrite old-configure while another is
starting to execute it, resulting in the latter nor executing
old-configure completely.
Differential Revision: https://phabricator.services.mozilla.com/D42428
--HG--
extra : moz-landing-system : lando
Just like C++14 sized deallocation support, we don't want to support
this. We shouldn't be using `new` on over-aligned types anyway.
Differential Revision: https://phabricator.services.mozilla.com/D41819
--HG--
extra : moz-landing-system : lando
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
This patch makes BuildEnvironmentNotFoundException a subclass of AttributeError as well, because hasattr in
python3 no longer catches all tracebacks but only AttributeError, and we use both hasattr and
BuildEnvironmentNotFoundException to guard against a handful of buildconfig variables in a few places
where it is OK to not have a buildenvironment.
We also use universal_newlines in real_host in init.configure (since I found
that fix while working on the AttributeError one) so that we get the right string type back from the process call
Lastly this patch also uses BytesIO for calling into a ReducedConfigureSandbox as its stdout and stderr pipes,
This ensures that related code handling the sandbox doesn't complain about getbuffer() missing in StringIO in py3.
Differential Revision: https://phabricator.services.mozilla.com/D36605
--HG--
extra : moz-landing-system : lando
By default, the linker chooses a "generic" 32-bit CPU to optimize for,
and LLVM's "generic" 32-bit CPU model doesn't include some features that
are helpful for performance on microbenchmarks. We explicitly specify a
CPU model to ensure the model we want is selected.
On x86-64, we explicitly force a generically good processor model, even
though the automatically selected one didn't seem to hurt benchmarks.
Differential Revision: https://phabricator.services.mozilla.com/D40479
--HG--
extra : moz-landing-system : lando
This change gives us the ability to selectively turn on cross-language
PGO, just like we have the ability to selectively turn on cross-language LTO.
There is room for things to go wrong here: it's not guaranteed that
`--enable-profile-generate=cross` will always be used with
`--enable-profile-use=cross`. Nothing bad will happen in the sense that
the build will succeed, but it's possible that we miss out on
optimizations on the Rust side. Either we fail to generate profile data
for the Rust code, or the Rust compiler fails to use the profile data.
In the future, we may want to default to cross-language PGO to avoid
these kind of mismatches.
Differential Revision: https://phabricator.services.mozilla.com/D39727
--HG--
extra : moz-landing-system : lando
To do properly checks on LLVM version correspondence between `clang` and
`rustc`, we need information about both of those compilers to be
available. The current placement of the LTO/PGO checks is after we know
something about `clang`, but before we know something about `rustc`.
Therefore we need to move those checks after we've gathered information
about `rustc`.
The PGO bits come along for this bug because the LTO bits depend on
them, and we're going to need the Rust information for cross-language
PGO checks in a different bug. So we might as well move everything all
at once.
Differential Revision: https://phabricator.services.mozilla.com/D39390
--HG--
rename : build/moz.configure/toolchain.configure => build/moz.configure/lto-pgo.configure
extra : moz-landing-system : lando
This change will eventually enable us to cross-check `rustc`'s version
with `clang`'s version when doing cross-language LTO/PGO and avoid
people running into peculiar errors at link time.
Differential Revision: https://phabricator.services.mozilla.com/D39388
--HG--
extra : moz-landing-system : lando
Toolchain path for Windows version is `<NDK ROOT>/toolchains/llvm/prebuilt/windows-x86_64` etc, so it isn't '`winnt`.
So we has to replace `host.kernel.lower()` with `windows`.
Differential Revision: https://phabricator.services.mozilla.com/D39474
--HG--
extra : moz-landing-system : lando
...rather than people running into peculiar crashes running their tests
because functions are pointing at the wrong thing.
It would be more robust to version-check `ld`, but I figure people
wanting to do local cross-language LTO builds is rare enough that
setting an environment variable and rerunning configure is not a huge
hardship.
Differential Revision: https://phabricator.services.mozilla.com/D36742
--HG--
extra : moz-landing-system : lando
...rather than people running into peculiar crashes running their tests
because functions are pointing at the wrong thing.
It would be more robust to version-check `ld`, but I figure people
wanting to do local cross-language LTO builds is rare enough that
setting an environment variable and rerunning configure is not a huge
hardship.
Differential Revision: https://phabricator.services.mozilla.com/D36742
--HG--
extra : moz-landing-system : lando
This build re-uses the PGO profile from the win64 build in the
win64-aarch64-shippable-no-eme part of the aarch64 build. Even though
the profile isn't generated on the smae platform, we still get enough of
a performance win to make this worthwhile.
Note that the pgo_flags() in configure need to be tweaked slightly since
we don't supprt the -fprofile-generate flag for aarch64 (we don't build
the clang_rt.profile lib there). So we always want to return the flags
namespace to make sure we get the use_* versions of flags, which we do
need.
Differential Revision: https://phabricator.services.mozilla.com/D38928
--HG--
extra : moz-landing-system : lando
There is less incentive to keep things building with older versions of
clang for OSX builds, and we're going to require an objective-C feature
that was added in clang 5.
Differential Revision: https://phabricator.services.mozilla.com/D38581
--HG--
extra : moz-landing-system : lando
Actually we set _DEPEND_CFLAGS to both host and target compiler. But if host and target are different compiler type, we may pass invalid option.
Differential Revision: https://phabricator.services.mozilla.com/D38457
--HG--
extra : moz-landing-system : lando
This change is a little bit of a cheat, because of course MSVC doesn't
do cross-language LTO by default, but it seems consistent.
Depends on D33317
Differential Revision: https://phabricator.services.mozilla.com/D33318
--HG--
extra : moz-landing-system : lando
Bogdan Tara
Aaron Klotz
James Willcox
Christian Holler
Mike Hommey
Ricky Stewart
David Major
Noemi Erli
Arthur Iakab
Andi-Bogdan Postelnicu
Andreea Pavel
Tyson Smith
Mihai Alexandru Michis
Stephen A Pohl
Tooru Fujisawa
Chris Manchester
Brindusan Cristian
Marco Bonardo
Coroiu Cristina
Nathan Froyd
Emilio Cobos Álvarez
Michael Forney
Sylvestre Ledru
Csoregi Natalia
Cosmin Sabou
Gabriele Svelto
Andrew Halberstadt
Nicholas Nethercote
Chris Peterson
Māris Fogels
Tom Ritter
Mike Shal
Razvan Maries
Gurzau Raul
Sebastian Hengst
shindli
Ciure Andrei
Makoto Kato
Marco Castelluccio
Dorel Luca
Cameron Kaiser
Justin Wood
Simon Sapin
Agi Sferro