This patch adds both Ion and Baseline support for ADD when the arguments are
doubles or int32.
This is implmented as a strangler via the SharedIC, this falls back to the shared
IC if there's no attachment in CacheIR. This should allow preservation of performance
throughout.
To provide clobber safety to the float registers, this patch uses fixed temporaries on
LBinaryCache.
--HG--
extra : rebase_source : 35f32e5d0f99bb93845c41aadaf94693644192bd
XPIDL files are logically grouped together into a module, but the
current model for the moz.build frontend is that we emit individual
XPIDLFile objects, and leave it to the backend to reconstruct
module-ness from those. This setup causes a small amout of useless work
to be done (e.g. see XPIDLFile handling in
RecursiveMakeBackend.consume_object; such handling should only be done
once), and it would be cleaner to have the objects emitted reflect the
build system concepts as closely as possible. To that end, let's emit
XPIDLModule objects instead, which fortunately requires relatively few
changes.
The IDLManager in the moz.build backend is a bit weird. It maintains a
bunch of per-IDL file information, some of which isn't used, and
attempts to map module names to information about what entities the
module needs to be built. The former is done with Python dicts, and the
latter with Python tuples, both resulting in some contortions by the
clients of IDLManager to specify exactly what they need.
Let's clean this up, by making IDLManager to more clearly do two jobs:
1. Keep track of whether IDL files are globally unique; and
2. Map module names to the information needed to build them.
In the case of #2, we store everything as a straight Python object, so
we can use actual property accesses everywhere. We also provide a
stems() function on IDLManager to make some client code more
straightforward.
Doing this makes IDLManager much more XPIDL module-centric, and paves
the way for the same change to be made in the frontend as well.
XPIDL_SOURCES would benefit from being more explicit about what sort of
values it contains; let's define it as a list of SourcePath objects, and
propagate those objects into XPIDLFile frontend objects as well.
This patch updates the alert emails to include a gfx-alerts email on all
graphics probes, and removes any outdated emails.
MozReview-Commit-ID: 1p4mz1u9DMZ
--HG--
extra : rebase_source : 4908c9197c40fbcee6b2e433d139b7731e483c5a
This probe is collected but expired. I think it makes sense to renew this.
MozReview-Commit-ID: 2gTC1Ljjpbv
--HG--
extra : rebase_source : 05e9b4d6bec8e6865e5e970871f4e9349b4ac890
This probe is being collected but has expired. I think it makes sense to renew this.
MozReview-Commit-ID: 4mE5lvdDify
--HG--
extra : rebase_source : a39527464c44ab14f5d40e18b588d2ddd0948913
This probe is being collected but is expired. I think it's worth renewing.
MozReview-Commit-ID: 2sk7JkDgynq
--HG--
extra : rebase_source : 2da73a6188c6424402d55b353f7b104c48b5b350
Any info-level log entries emitted before session creation will
not be subject to the requested log level from moz:firefoxOptions.
This can confuse users, so instead of logging the geckodriver
version number on starting the program, we can return it later
during session creation as an extension capability.
Additionally this patch reduces the log level of the port geckodriver
listens to from info to debug for similar reasons.
This patch fixes redrawing of the popup element by removing the scale factor
from the invalid regions because the wl_surface_damage multiplies it with the
scale factor too.
Also we set scaling factor of the wl_surface right after we create it to avoid
flickering when the compositor switches from unscaled to scaled surface.
MozReview-Commit-ID: 1eGoFu87wtF
--HG--
extra : rebase_source : 08abe86889e34865f3eed0f3979b4a584cc74adb
Matthew Gaudet
Narcis Beleuzu
Nathan Froyd
Kartikaya Gupta
Ryan Hunt
Brian Hackett
Jan Varga
Tokio Kajitsuka
Jonathan Kingston
David Keeler
Csoregi Natalia
Gurzau Raul
Andreas Tolfsen
Christian Holler
Sylvestre Ledru
Jan Horak