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
In the future we should re-write this checker but for now this solution is acceptable.
Differential Revision: https://phabricator.services.mozilla.com/D51242
--HG--
extra : moz-landing-system : lando
This is just drive-by, but it confused me. We require at least clang 4 to build
nowadays.
Differential Revision: https://phabricator.services.mozilla.com/D50646
--HG--
extra : moz-landing-system : lando
sccache-dist / icecream preprocess the file and then send it to a builder.
That means that the file contains #line directives or equivalents in order for
diagnostics and such to work correctly.
Unfortunately our clang-plugin build fails catastrophically if you include a
third-party header, as it doesn't account for them.
Use SourceManager::getPresumedLoc to get filenames, as it accounts for them,
unlike just getFilename.
Differential Revision: https://phabricator.services.mozilla.com/D50633
--HG--
extra : moz-landing-system : lando
"here" is a bad click target, giving it a proper name helps everyone.
Depends on D50035
Differential Revision: https://phabricator.services.mozilla.com/D50036
--HG--
extra : moz-landing-system : lando
I opted to go with what I perceived as the more expedient route
of leaving lz4 roughly where it is and just adding to that. The
biggest complication was xxhash, which is included elsewhere.
I'm not generally proficient with build-related things though so
my solution may be wrong and not just ugly.
Differential Revision: https://phabricator.services.mozilla.com/D30640
--HG--
rename : mfbt/lz4.c => mfbt/lz4/lz4.c
rename : mfbt/lz4.h => mfbt/lz4/lz4.h
extra : moz-landing-system : lando
This logic is very 'mozill-central' specific and should live outside of mach
core if possible. Luckily we already have a concept of a 'pre_dispatch_handler'
that is meant for exactly this type of use case.
Differential Revision: https://phabricator.services.mozilla.com/D47668
--HG--
extra : moz-landing-system : lando
I opted to go with what I perceived as the more expedient route
of leaving lz4 roughly where it is and just adding to that. The
biggest complication was xxhash, which is included elsewhere.
I'm not generally proficient with build-related things though so
my solution may be wrong and not just ugly.
Differential Revision: https://phabricator.services.mozilla.com/D30640
--HG--
rename : mfbt/lz4.c => mfbt/lz4/lz4.c
rename : mfbt/lz4.h => mfbt/lz4/lz4.h
extra : moz-landing-system : lando
Right now toolchain tasks that aren't dependencies of requested tasks
will run in response to source code changes only if the files are in the
sparse profile. That is, taskgraph calculates the digest based on just
the files in those directories that are in the sparse profile, and will
rebuild it when those files change. This changes ensures that more
geckodriver files are used to calculate the digest, and thus changes
to them will cause geckodriver to be rebuilt.
As more things depend on the geckodriver toolchain tasks directly this
becomes less valuable and can be removed from the sparse profile.
Differential Revision: https://phabricator.services.mozilla.com/D47459
--HG--
extra : moz-landing-system : lando
Since we've upgraded to clang 9, clang-format changed and now uses dynamic libraries
for the clang tooling lib that it leverages.
Differential Revision: https://phabricator.services.mozilla.com/D47265
--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
In clang 9, the signature of `registerPPCallbacks` changed and it no longer provides us a `CompilerInstance` [0]. I couldn't find a way to reach the `CompilerInstance` from the new structures, so I've inserted a level into the class hierarchy that mimics the old functionality.
With this patch, clang-tidy compiles with either clang-8 or clang-9, so we can land this independently in preparation for bug 1573211.
[0] For reference: the new signature was introduced in bbc89dcb29, the old overload was marked deprecated in e9087fe75c and removed in ee737a84d7.
Differential Revision: https://phabricator.services.mozilla.com/D46702
--HG--
extra : moz-landing-system : lando
David Major
Nihanth Subramanya
Dorel Luca
Ricky Stewart
Andi-Bogdan Postelnicu
Ciure Andrei
Edwin Takahashi
Nathan Froyd
Christian Holler
Emilio Cobos Álvarez
Chris Manchester
Andreea Pavel
Cosmin Sabou
Marco Castelluccio
Jan-Erik Rediger
Wes Kocher
Sylvestre Ledru
Daniel Varga
Doug Thayer
Tom Ritter
Ed Lee
Andrew Halberstadt
Ricky Stewart
dimi
Nick Alexander
Brindusan Cristian