165ba091863c4a2deefbb9fd83047ba913110f37: Bug 1477332 - add aarch64 to mozinfo's known list of 64-bit cpus; r=chmanchester
Nathan Froyd <froydnj@mozilla.com> - Tue, 24 Jul 2018 15:49:16 -0400 - rev 428053
Push 105622 by nfroyd@mozilla.com at Tue, 24 Jul 2018 19:49:26 +0000
Bug 1477332 - add aarch64 to mozinfo's known list of 64-bit cpus; r=chmanchester
b9d4bff67989d578bf7b2fb533cf65799909f81e: Bug 1476973 - part 5 - make xpidl variables simply expanded; r=gps
Nathan Froyd <froydnj@mozilla.com> - Tue, 24 Jul 2018 15:41:47 -0400 - rev 428052
Push 105621 by nfroyd@mozilla.com at Tue, 24 Jul 2018 19:42:02 +0000
Bug 1476973 - part 5 - make xpidl variables simply expanded; r=gps These kind of variables are slightly more efficient in make.
c4400e353e3025805b11129ce3d9dae3b9ab5ceb: Bug 1476973 - part 4 - emit XPIDLModule, rather than multiple XPIDLFile; r=gps
Nathan Froyd <froydnj@mozilla.com> - Tue, 24 Jul 2018 15:41:47 -0400 - rev 428051
Push 105621 by nfroyd@mozilla.com at Tue, 24 Jul 2018 19:42:02 +0000
Bug 1476973 - part 4 - emit XPIDLModule, rather than multiple XPIDLFile; r=gps 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.
5a0ab5e5a8712f49e5f775ac77b6c9f98cd391ff: Bug 1476973 - part 3 - rationalize the backend's IDLManager; r=gps
Nathan Froyd <froydnj@mozilla.com> - Tue, 24 Jul 2018 15:41:47 -0400 - rev 428050
Push 105621 by nfroyd@mozilla.com at Tue, 24 Jul 2018 19:42:02 +0000
Bug 1476973 - part 3 - rationalize the backend's IDLManager; r=gps 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.
a15b3186d0bba642a33711275a48cbe68bec2833: Bug 1476973 - part 2 - assert that XPIDL_SOURCES files all exist; r=gps
Nathan Froyd <froydnj@mozilla.com> - Tue, 24 Jul 2018 15:41:47 -0400 - rev 428049
Push 105621 by nfroyd@mozilla.com at Tue, 24 Jul 2018 19:42:02 +0000
Bug 1476973 - part 2 - assert that XPIDL_SOURCES files all exist; r=gps We should have been checking for this from the beginning.
d1843ad25a8aa8edbd94ba3e1ea4534b83b369c0: Bug 1476973 - part 1 - make XPIDL_SOURCES a list of SourcePath objects; r=gps
Nathan Froyd <froydnj@mozilla.com> - Tue, 24 Jul 2018 15:41:47 -0400 - rev 428048
Push 105621 by nfroyd@mozilla.com at Tue, 24 Jul 2018 19:42:02 +0000
Bug 1476973 - part 1 - make XPIDL_SOURCES a list of SourcePath objects; r=gps 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.
bdb9d9781a8a555d9168342446f0ed7aa572ced3: Bug 1478111 - Update pdf.js to version 2.0.694. r=bdahl
Ryan VanderMeulen <ryanvm@gmail.com> - Tue, 24 Jul 2018 15:35:11 -0400 - rev 428047
Push 105620 by ryanvm@gmail.com at Tue, 24 Jul 2018 19:35:50 +0000
Bug 1478111 - Update pdf.js to version 2.0.694. r=bdahl
4598c8290ae4a1876d23a675d65f9667d11f9b61: Bug 1438727: [Part 8] Implement JSOP_MUL in CacheIR r=tcampbell
Matthew Gaudet <mgaudet@mozilla.com> - Mon, 26 Mar 2018 09:58:19 -0400 - rev 428046
Push 105619 by mgaudet@mozilla.com at Tue, 24 Jul 2018 19:01:04 +0000
Bug 1438727: [Part 8] Implement JSOP_MUL in CacheIR r=tcampbell
0f5a8676e1e8c3c057b3cedcab33143a5d38c0da: Bug 1438727: [Part 7] Clarify restrictions on imul and remove un-needed restriction r=tcampbell
Matthew Gaudet <mgaudet@mozilla.com> - Fri, 20 Apr 2018 16:36:07 +0200 - rev 428045
Push 105619 by mgaudet@mozilla.com at Tue, 24 Jul 2018 19:01:04 +0000
Bug 1438727: [Part 7] Clarify restrictions on imul and remove un-needed restriction r=tcampbell
d63f8f13573a6735a49168dbceb62e41c4f126f3: Bug 1438727: [Part 6] Allow allocateFixedRegister to spill in order to acquire a fixed register r=jandem
Matthew Gaudet <mgaudet@mozilla.com> - Tue, 27 Mar 2018 12:09:17 -0400 - rev 428044
Push 105619 by mgaudet@mozilla.com at Tue, 24 Jul 2018 19:01:04 +0000
Bug 1438727: [Part 6] Allow allocateFixedRegister to spill in order to acquire a fixed register r=jandem In some circumstances the fixed register that's desired may be available only after a spill.
8e1d2526dc1018dea19b4f2907192cd88c17b66a: Bug 1438727: [Part 5] Implement branchMul32 in MacroAssembler r=tcampbell
Matthew Gaudet <mgaudet@mozilla.com> - Mon, 26 Mar 2018 09:36:57 -0400 - rev 428043
Push 105619 by mgaudet@mozilla.com at Tue, 24 Jul 2018 19:01:04 +0000
Bug 1438727: [Part 5] Implement branchMul32 in MacroAssembler r=tcampbell
e4df17b00a7e51bab96a7a0c2fc9a86ad7c35d26: Bug 1438727: [Part 4] Implement CacheIR IC for bitwise operations on Int32s r=jandem
Matthew Gaudet <mgaudet@mozilla.com> - Thu, 22 Mar 2018 19:01:00 -0400 - rev 428042
Push 105619 by mgaudet@mozilla.com at Tue, 24 Jul 2018 19:01:04 +0000
Bug 1438727: [Part 4] Implement CacheIR IC for bitwise operations on Int32s r=jandem (As well as booleans combined with int32s)
e86f52052359a6bcf70045d370714c007606e9cb: Bug 1438727: [Part 3] Implement ADD+SUB for Boolean + Double|Int32 r=jandem
Matthew Gaudet <mgaudet@mozilla.com> - Thu, 22 Mar 2018 15:08:03 -0400 - rev 428041
Push 105619 by mgaudet@mozilla.com at Tue, 24 Jul 2018 19:01:04 +0000
Bug 1438727: [Part 3] Implement ADD+SUB for Boolean + Double|Int32 r=jandem
cc58162b8a3a7ba5c153c01bb211afd24b4323f9: Bug 1438727: [Part 2] Implement a subset of JSOP_SUB in CacheIR r=jandem
Matthew Gaudet <mgaudet@mozilla.com> - Thu, 22 Mar 2018 14:12:58 -0400 - rev 428040
Push 105619 by mgaudet@mozilla.com at Tue, 24 Jul 2018 19:01:04 +0000
Bug 1438727: [Part 2] Implement a subset of JSOP_SUB in CacheIR r=jandem
50d88eac66ca91857d88457c33540ba46c949730: Bug 1438727: [Part 1] Implement a subset of JSOP_ADD in CacheIR r=jandem
Matthew Gaudet <mgaudet@mozilla.com> - Thu, 29 Mar 2018 09:09:58 -0400 - rev 428039
Push 105619 by mgaudet@mozilla.com at Tue, 24 Jul 2018 19:01:04 +0000
Bug 1438727: [Part 1] Implement a subset of JSOP_ADD in CacheIR r=jandem 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.
1e3e3e15772c489a5f37739315c79d96f9b16726: Bug 1438727: [Part 0] Add test case for binary arithmetic operations r=tcampbell
Matthew Gaudet <mgaudet@mozilla.com> - Tue, 20 Mar 2018 16:08:40 -0400 - rev 428038
Push 105619 by mgaudet@mozilla.com at Tue, 24 Jul 2018 19:01:04 +0000
Bug 1438727: [Part 0] Add test case for binary arithmetic operations r=tcampbell
6d89e0d0f3b16250d643d6a1ff5a8b3d09fc55b8: Backed out 5 changesets (bug 1476973) for build tup bustages. CLOSED TREE
Narcis Beleuzu <nbeleuzu@mozilla.com> - Tue, 24 Jul 2018 21:51:43 +0300 - rev 428037
Push 105618 by nbeleuzu@mozilla.com at Tue, 24 Jul 2018 18:52:42 +0000
Backed out 5 changesets (bug 1476973) for build tup bustages. CLOSED TREE Backed out changeset e59a3967c1e4 (bug 1476973) Backed out changeset 19e5a88621d1 (bug 1476973) Backed out changeset 24bcc39a55f2 (bug 1476973) Backed out changeset 08370aca03f5 (bug 1476973) Backed out changeset 7d6a7a63abc0 (bug 1476973)
6fcf54117a3b21164e6e769343416d2262991f6e: Bug 1476423 - add --enable-cranelift option; r=gps,sunfish
Nathan Froyd <froydnj@mozilla.com> - Tue, 24 Jul 2018 14:31:45 -0400 - rev 428036
Push 105617 by nfroyd@mozilla.com at Tue, 24 Jul 2018 18:31:56 +0000
Bug 1476423 - add --enable-cranelift option; r=gps,sunfish
e59a3967c1e48ed155805fb4e6d3c7a11f778985: Bug 1476973 - part 5 - make xpidl variables simply expanded; r=gps
Nathan Froyd <froydnj@mozilla.com> - Tue, 24 Jul 2018 14:30:53 -0400 - rev 428035
Push 105616 by nfroyd@mozilla.com at Tue, 24 Jul 2018 18:31:20 +0000
Bug 1476973 - part 5 - make xpidl variables simply expanded; r=gps These kind of variables are slightly more efficient in make.
19e5a88621d13c526b6952bf707a2a824245a069: Bug 1476973 - part 4 - emit XPIDLModule, rather than multiple XPIDLFile; r=gps
Nathan Froyd <froydnj@mozilla.com> - Tue, 24 Jul 2018 14:30:53 -0400 - rev 428034
Push 105616 by nfroyd@mozilla.com at Tue, 24 Jul 2018 18:31:20 +0000
Bug 1476973 - part 4 - emit XPIDLModule, rather than multiple XPIDLFile; r=gps 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.
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip