-gline-tables-only is better passed to --enable-debug or
--enable-debug-symbols than via abuse of --enable-optimize.
--enable-optimize was being passed -O2 because passing
-gline-tables-only would have removed optimizations. This has the side
effect of changing the optimization level on macOS, though, so there
we keep the override.
--disable-debug is the default, remove it.
--enable-project=browser is the default, remove it.
--enable-optimize is the default, remove it.
--enable-debug-symbols is the default, remove it.
--disable-sandbox is the default on tsan builds, remove it.
--enable-optimize="-O2 -g" is, essentially, the default, remove it.
--with-android-min-sdk=21 is the default, remove it.
X11 builds only have the X11 headers, so technically speaking the
cairo-gtk3 toolkit is fine because it does the right fallback, but
using cairo-gtk3-x11-only is more explicit and would avoid surprises.
MOZ_DEBUG_SYMBOLS has been a no-op for essentially forever.
Differential Revision: https://phabricator.services.mozilla.com/D227311
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
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.
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
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.
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
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.
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
When the injected code is used by elfhack, the debug info is thrown away
because elfhack doesn't know what to do with it, but in the case of
relrhack, the normal linker can handle it, so there's no reason not to
include the debug info anymore.
Differential Revision: https://phabricator.services.mozilla.com/D192904
When .rel.plt and .relr.dyn are the same size, after the section header
for .relr.dyn has been updated, it matches the condition for .rel.plt,
and we ended up undoing the change.
Differential Revision: https://phabricator.services.mozilla.com/D192981
On ARM, lld places the .ARM.exidx section between .rel.dyn/.relr.dyn and
.rel.plt. This means we can't swap .relr.dyn and .rel.plt (well, we
could, if we also moved and rewrote the .ARM.exidx section, but that's
more work than we ought to do).
But we only need to swap the sections when we want the binary to be
compatible with older versions of glibc, which we don't care about on
desktop ARM Linux (we don't ship such builds), and don't need at all
on ARM Android. Ultimately, this is a bug in lld
(https://github.com/llvm/llvm-project/issues/68178).
Differential Revision: https://phabricator.services.mozilla.com/D190006
Old versions of llvm-readelf didn't have parens in its output for `-d`.
So instead of looking for parens, look for word boundaries.
Differential Revision: https://phabricator.services.mozilla.com/D188897
Elfhack is the main reason we're not using lld on Linux/Android
shippable builds, because the way it works doesn't go well with how lld
lays out ELF binaries. By leveraging the linker itself (BFD and lld both
having recently gained the ability to generate the compact relocation
info themselves), we can achieve a similar result to what elfhack is
doing, while allowing to use lld.
See more in-depth background on https://glandium.org/blog/?p=4297
Differential Revision: https://phabricator.services.mozilla.com/D187089
