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.
In some circumstances the fixed register that's desired may be available only after a spill.
--HG--
extra : rebase_source : 8d51e0c53765bb0f84d43bf4aac8445d01270d59
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
Nathan Froyd
Ryan VanderMeulen
Matthew Gaudet
Narcis Beleuzu
Kartikaya Gupta
Ryan Hunt
Brian Hackett
Jan Varga
Tokio Kajitsuka
Jonathan Kingston