It's not like we publish the ReleaseNotes from the clang toolchain
artifact, and it's only going to be a recurrent source of patch conflict
when the upstream release notes change.
Differential Revision: https://phabricator.services.mozilla.com/D196529
We use UPLOAD_DIR rather than UPLOAD_PATH because UPLOAD_DIR is handled
by run-task to be set properly from a relative path.
As the snaps rightfully unset MOZ_AUTOMATION, we add another way to
enable the use of the symbols server.
Differential Revision: https://phabricator.services.mozilla.com/D196399
AC_SUBSTs with a lower-case key are not really supposed to be used,
although that has never been enforced, and at least one of them is
used in practice.
At least, that's the theory behind using files to store their value in
config.statusd (added in bug 1402012). Because obviously, on
case-insensitive file systems, a variable that is upper case will use
the same file as the lower case one. If their value is the same, then
fine, but if they aren't, thing go bad.
Until bug 1867457, that held true for TARGET_CPU and target_cpu: their
value was the same. But bug 1867457 changed that. But target_cpu is only
there because it's set by autoconf itself, and we don't care about it.
The result is that the value of target_cpu takes precedence because it's
set last, and overwrites the value of TARGET_CPU in config.statusd,
subsequently making the value read in GenerateAtomicOperations.py wrong.
Differential Revision: https://phabricator.services.mozilla.com/D195959
AC_SUBSTs with a lower-case key are not really supposed to be used,
although that has never been enforced, and at least one of them is
used in practice.
At least, that's the theory behind using files to store their value in
config.statusd (added in bug 1402012). Because obviously, on
case-insensitive file systems, a variable that is upper case will use
the same file as the lower case one. If their value is the same, then
fine, but if they aren't, thing go bad.
Until bug 1867457, that held true for TARGET_CPU and target_cpu: their
value was the same. But bug 1867457 changed that. But target_cpu is only
there because it's set by autoconf itself, and we don't care about it.
The result is that the value of target_cpu takes precedence because it's
set last, and overwrites the value of TARGET_CPU in config.statusd,
subsequently making the value read in GenerateAtomicOperations.py wrong.
Differential Revision: https://phabricator.services.mozilla.com/D195959
In many cases, using CONFIG["CPU_ARCH"] will silently do the unexpected
thing now that it doesn't exist anymore. In case there are in-flight
patches using it, it's better to avoid those causing subtle problems
after a rebase by making most uses of the variable throw an exception.
Differential Revision: https://phabricator.services.mozilla.com/D195158
This is 5% faster on my setup, mostly thanks to unrolling being
possible.
We also skip the early loop exit. Most of the bits of `bits` are generally set, so it's ok to do a
few more extra operations if we do them faster.
Differential Revision: https://phabricator.services.mozilla.com/D193366
This is 20% faster on my setup, and according to llvm-mca, the IPC for
the false branch (which is the hottest one) goes from 3 to 5.7, thanks
to unrolling and conditional moves.
Only activated on non-Android target though, as it breaks at runtime.
Basically, most of the bits of `bits` are generally set, so it's ok to do a
few more extra operations as we do them faster.
Differential Revision: https://phabricator.services.mozilla.com/D193366
Introduce functions which create and invoke the Windows file-picker in a
separate thread. This thread is created with a new single-threaded COM
apartment to avoid implicitly creating a nested modal loop on the main
STA thread.
Technically, no functional changes: these functions aren't actually
invoked yet. (That will occur in an upcoming commit.)
Differential Revision: https://phabricator.services.mozilla.com/D193735
The async file-picker creates a new thread, but the thread name was not
added to the permitted-thread-names list. Amended.
Differential Revision: https://phabricator.services.mozilla.com/D195170
This is done for both Android and regular builds, and it brings a nice
1% perf improvement on Windows, and 2% on Android.
Do not get rid of Speedometer2 yet, adding Speedometer3 already brings
an interesting performance boost.
To update to the latest version run
> ./mach vendor third_party/webkit/PerformanceTests/Speedometer3/moz.yaml
Differential Revision: https://phabricator.services.mozilla.com/D194040
