One of the recent changes made it so that the test doesn't start on its own unless the URL has "raptor".
I've confirmed that this
- Does not swamp out the profdata file
- Does not regress displaylist-mutate
- Improves the webaudio score
Differential Revision: https://phabricator.services.mozilla.com/D71197
Currently the linux64-clang-9-win-cross toolchain depends on the win64-clang-cl toolchain for a few files. This causes very long lead times when toolchains are rebuilt, because of the un-parallelizable chain of tasks win64-clang-cl -> linux64-clang-9-win-cross -> builds.
As a partial mitigation, this patch adds a single-stage clang-cl build for consumption by the cross toolchain. It's not a very high quality build, but good enough for the purpose it serves, while being faster to build.
Differential Revision: https://phabricator.services.mozilla.com/D70254
--HG--
rename : build/build-clang/clang-win64.json => build/build-clang/clang-win64-1stage.json
extra : moz-landing-system : lando
This commit removes `test_fix_stack_using_bpsyms.py`. That test can't easily be
modified to work with `fix_stacks.py` because it relies on internal
implementation details of `fix_stack_using_bpsym.py`. The unit testing done in
the `fix-stacks` repo provides test coverage that is as good or better.
Differential Revision: https://phabricator.services.mozilla.com/D66924
--HG--
extra : moz-landing-system : lando
Patches that are applied on top on `clang-10` repo are based on the original
patches from our trunk and have been rebased on top of `clang-10`.
Please see as an example: `find_symbolizer_linux.patch` copied to `find_symbolizer_linux_clang_10.patch`.
Differential Revision: https://phabricator.services.mozilla.com/D70063
--HG--
rename : build/build-clang/clang-linux64.json => build/build-clang/clang-10-linux64.json
rename : build/build-clang/find_symbolizer_linux.patch => build/build-clang/find_symbolizer_linux_clang_10.patch
rename : build/build-clang/llvmorg-11-init-4265-g2dcbdba8540.patch => build/build-clang/llvmorg-11-init-4265-g2dcbdba8540_clang_10.patch
rename : build/build-clang/rG7e18aeba5062.patch => build/build-clang/rG7e18aeba5062_clang_10.patch
rename : build/build-clang/rename_gcov_flush.patch => build/build-clang/rename_gcov_flush_clang_10.patch
rename : build/build-clang/tsan-hang-be41a98ac222.patch => build/build-clang/tsan-hang-be41a98ac222_clang_10.patch
rename : build/build-clang/unpoison-thread-stacks.patch => build/build-clang/unpoison-thread-stacks_clang_10.patch
extra : moz-landing-system : lando
The `linux64-clang-9-cross` toolchain was forked from `linux64-clang-9` in https://hg.mozilla.org/integration/autoland/rev/ca923afe3ed4 in order to pick up a patch for Windows compilation.
This is no longer necessary for two reasons:
1. Windows builds stopped depending on that patch in bug 1608460.
2. Even if we still needed that patch, the `linux64-clang-9` toolchain gained all of the Windows patches in bug 1618473.
Therefore the `clang-dist` task can go back to using unmodified `linux64-clang-9`.
Differential Revision: https://phabricator.services.mozilla.com/D70263
--HG--
extra : moz-landing-system : lando
Patches that are applied on top on `clang-10` repo are based on the original
patches from our trunk and have been rebased on top of `clang-10`.
Please see as an example: `find_symbolizer_linux.patch` copied to `find_symbolizer_linux_clang_10.patch`.
Differential Revision: https://phabricator.services.mozilla.com/D70063
--HG--
rename : build/build-clang/clang-linux64.json => build/build-clang/clang-10-linux64.json
rename : build/build-clang/find_symbolizer_linux.patch => build/build-clang/find_symbolizer_linux_clang_10.patch
rename : build/build-clang/llvmorg-11-init-4265-g2dcbdba8540.patch => build/build-clang/llvmorg-11-init-4265-g2dcbdba8540_clang_10.patch
rename : build/build-clang/rG7e18aeba5062.patch => build/build-clang/rG7e18aeba5062_clang_10.patch
rename : build/build-clang/rename_gcov_flush.patch => build/build-clang/rename_gcov_flush_clang_10.patch
rename : build/build-clang/tsan-hang-be41a98ac222.patch => build/build-clang/tsan-hang-be41a98ac222_clang_10.patch
rename : build/build-clang/unpoison-thread-stacks.patch => build/build-clang/unpoison-thread-stacks_clang_10.patch
extra : moz-landing-system : lando
This adds the ability to do four-stage PGO builds. This was surprisingly straightforward thanks to PGO being a well-supported scenario in LLVM's cmake.
For reference, the stages are:
stage1: Initial build with gcc
stage2: Instrumented build using stage1
stage3: Train by using the instrumented stage2 to build the clang tree
stage4: Optimize using the stage3 compiler and the profdata created with it
Differential Revision: https://phabricator.services.mozilla.com/D69080
--HG--
extra : moz-landing-system : lando
Separating out the mechanical/"boring" changes to make the next patch more clear. This patch adds the ability to build a fourth stage that for now doesn't do anything special.
I changed to using >= to make it more obvious that e.g. "here is what's going to happen for stage 2" -- the off-by-one was too hard on my brain.
Differential Revision: https://phabricator.services.mozilla.com/D69079
--HG--
extra : moz-landing-system : lando
Otherwise, PGO builds would fail to find asan at stage2 because the instrumented build uses `LLVM_BUILD_RUNTIME=No`.
Differential Revision: https://phabricator.services.mozilla.com/D69082
--HG--
extra : moz-landing-system : lando
This will partially atone for making builds longer with PGO.
Depends on D69618
Differential Revision: https://phabricator.services.mozilla.com/D69620
--HG--
extra : moz-landing-system : lando
This also does a few remaining python 2 incompatible changes to
.configure files.
Differential Revision: https://phabricator.services.mozilla.com/D69538
--HG--
extra : moz-landing-system : lando
This adds the ability to do four-stage PGO builds. This was surprisingly straightforward thanks to PGO being a well-supported scenario in LLVM's cmake.
For reference, the stages are:
stage1: Initial build with gcc
stage2: Instrumented build using stage1
stage3: Train by using the instrumented stage2 to build the clang tree
stage4: Optimize using the stage3 compiler and the profdata created with it
Differential Revision: https://phabricator.services.mozilla.com/D69080
--HG--
extra : moz-landing-system : lando
Separating out the mechanical/"boring" changes to make the next patch more clear. This patch adds the ability to build a fourth stage that for now doesn't do anything special.
I changed to using >= to make it more obvious that e.g. "here is what's going to happen for stage 2" -- the off-by-one was too hard on my brain.
Differential Revision: https://phabricator.services.mozilla.com/D69079
--HG--
extra : moz-landing-system : lando
Otherwise, PGO builds would fail to find asan at stage2 because the instrumented build uses `LLVM_BUILD_RUNTIME=No`.
Differential Revision: https://phabricator.services.mozilla.com/D69082
--HG--
extra : moz-landing-system : lando
This will partially atone for making builds longer with PGO.
Depends on D69618
Differential Revision: https://phabricator.services.mozilla.com/D69620
--HG--
extra : moz-landing-system : lando
Using @checking doesn't go well with the virtualenv creation, so print
the version information after the fact. And do so uniformely for python
2 and python 3.
Differential Revision: https://phabricator.services.mozilla.com/D69529
--HG--
extra : moz-landing-system : lando
This is yet another cargo-cult from virtualenv_python2, which is not
necessary because by the time we reach virtualenv_python3, the mozconfig
configure *has* been injected already.
Differential Revision: https://phabricator.services.mozilla.com/D69528
--HG--
extra : moz-landing-system : lando
It was cargo-culted from virtualenv_python2, but is not necessary
because virtualenv_python3 is not going to re-execute python, which is
what the dependency is there to avoid.
Differential Revision: https://phabricator.services.mozilla.com/D69527
--HG--
extra : moz-landing-system : lando
