searching for reviewer(djvj)
7bd0784e7a6f3702152bdca395b2305f16ca0479: Bug 1598347, part 2: pass "inner singleton" to NEWOBJECT group logic. r=djvj,iain
Chris Fallin <cfallin@mozilla.com> - Wed, 27 Nov 2019 22:49:33 +0000 - rev 504902
Push 36873 by shindli@mozilla.com at Tue, 03 Dec 2019 09:48:30 +0000
Bug 1598347, part 2: pass "inner singleton" to NEWOBJECT group logic. r=djvj,iain This change passes through the "inner singleton" status of a particular object literal to the group-assignment logic for JSOP_NEWOBJECT by instead using a variant opcode, JSOP_NEWOBJECT_WITHGROUP. "Inner singleton" status is meant to emulate old behavior (prior to ObjLiteral) in which the frontend built an entire tree of objects/arrays with a top-level singleton. In the old world, these objects were allocated by ParseNode::getConstantValue() in the frontend and built by ObjectGroup::newPlainObject, which looked up an object group by property names. In the new world, the default NEWOBJECT logic uses a separate test for whether an allocation site should have a singleton group, and even after we carefully emulate the old group behavior in the frontend, the new-object allocation itself will decide to allocate singleton groups. In the particular regression case motivating this change, these singleton groups break the TI information for a singleton array (typeset for all elems no longer has a single group) and as a result, a simple property access can no longer be inlined. This patch matches the old behavior and allows the inlining to occur. Differential Revision: https://phabricator.services.mozilla.com/D54609
6da3c648995f15cacd586ebb3c8022a690c9649f: Bug 1598347, part 1: Handle the inner-singleton case for array elem objs. r=djvj,iain
Chris Fallin <cfallin@mozilla.com> - Wed, 27 Nov 2019 22:48:40 +0000 - rev 504901
Push 36873 by shindli@mozilla.com at Tue, 03 Dec 2019 09:48:30 +0000
Bug 1598347, part 1: Handle the inner-singleton case for array elem objs. r=djvj,iain This patch extends the "inner singleton" hack to array element object literals in the parser. With the new ObjLiteral system, we are attempting to emulate the old (sometimes incidental) behavior of the parser's literal object allocation as closely as possible, to avoid regressions (such as this bug). The "inner singleton" status indicates that an object would have been allocated as part of a tree objects, with a singleton at the top, in the old world. In this case, we do something slightly different with the group setup. The second half of this patch will extend the inner-singleton bit back through to object allocation during execution. Differential Revision: https://phabricator.services.mozilla.com/D54236
78d02a12be591b6260f878e70fc8ba73d857e893: Bug 1580246: Remove object-literal singleton objects allocated at parse. r=djvj,mgaudet
Chris Fallin <cfallin@mozilla.com> - Mon, 04 Nov 2019 21:31:27 +0000 - rev 500468
Push 36765 by aiakab@mozilla.com at Tue, 05 Nov 2019 09:57:55 +0000
Bug 1580246: Remove object-literal singleton objects allocated at parse. r=djvj,mgaudet Instead, this patch introduces a new `ObjLiteral` mini-bytecode format that is used to carry object-literal information from parse time to a later time at which GC objects are safe to allocate. The mini-bytecode simply specifies a list of fields and constant field values. The original intent of this patch (realized in previous versions of it) was to make this an opcode, and completely replace object creation sequences (NEWINIT, INITPROP, INITPROP, ...) with one OBJLITERAL opcode. However, there are quite a few performance regressions that occur when replacing the finely-tuned set of optimizations around this with a new mechanism. As a result, this patch only defers allocation of the objects until the very end of parse. Each object literal adds an ObjLiteralCreationData instance to the GC-things list, and when the GC-things list is processed to perform deferred allocations, the described objects will be created. Differential Revision: https://phabricator.services.mozilla.com/D47985
8e192f9c8f844623a1b0a2d96b0c8ca22543f183: Bug 1580246: Remove object-literal singleton objects allocated at parse. r=djvj,mgaudet
Chris Fallin <cfallin@mozilla.com> - Mon, 04 Nov 2019 18:31:18 +0000 - rev 500426
Push 36764 by rmaries@mozilla.com at Tue, 05 Nov 2019 04:08:22 +0000
Bug 1580246: Remove object-literal singleton objects allocated at parse. r=djvj,mgaudet Instead, this patch introduces a new `ObjLiteral` mini-bytecode format that is used to carry object-literal information from parse time to a later time at which GC objects are safe to allocate. The mini-bytecode simply specifies a list of fields and constant field values. The original intent of this patch (realized in previous versions of it) was to make this an opcode, and completely replace object creation sequences (NEWINIT, INITPROP, INITPROP, ...) with one OBJLITERAL opcode. However, there are quite a few performance regressions that occur when replacing the finely-tuned set of optimizations around this with a new mechanism. As a result, this patch only defers allocation of the objects until the very end of parse. Each object literal adds an ObjLiteralCreationData instance to the GC-things list, and when the GC-things list is processed to perform deferred allocations, the described objects will be created. Differential Revision: https://phabricator.services.mozilla.com/D47985
4b4511cf734e381d12dc99f22efc962cd8ba7d3c: Bug 1492920: remove restriction on IC attachment for instanceof: allow RHS with a reassigned __proto__. r=djvj,jandem
Chris Fallin <cfallin@mozilla.com> - Thu, 22 Aug 2019 21:07:40 +0300 - rev 489564
Push 36477 by ncsoregi@mozilla.com at Fri, 23 Aug 2019 15:38:34 +0000
Bug 1492920: remove restriction on IC attachment for instanceof: allow RHS with a reassigned __proto__. r=djvj,jandem Based on discussions with :djvj, it seems that this IC attachment logic is overly conservative. We're seeing a case where the `__proto__` of a constructor function is reassigned, which causes all instanceof ICs to fail to attach. The test case is like: function C() { /* ... */ } C.__proto__ = D; var o = new C(); var result = o instanceof C; // this IC fails to attach This change generalizes the IC attachment logic to check whether @@hasInstance is defined anywhere below Function in the prototype chain of the RHS. If not, it is still safe to attach the IC; the IC simply needs to guard on the prototype chain to ensure no @@hasInstance override is inserted later. Differential Revision: https://phabricator.services.mozilla.com/D42366
7e12c8c5d1a322159ba36dde9457cec6e95c2bfc: Bug 1492920: remove restriction on IC attachment for instanceof: allow RHS with a reassigned __proto__. r=djvj,jandem
Chris Fallin <cfallin@mozilla.com> - Thu, 22 Aug 2019 18:08:37 +0000 - rev 489477
Push 36475 by ncsoregi@mozilla.com at Fri, 23 Aug 2019 09:45:38 +0000
Bug 1492920: remove restriction on IC attachment for instanceof: allow RHS with a reassigned __proto__. r=djvj,jandem Based on discussions with :djvj, it seems that this IC attachment logic is overly conservative. We're seeing a case where the `__proto__` of a constructor function is reassigned, which causes all instanceof ICs to fail to attach. The test case is like: function C() { /* ... */ } C.__proto__ = D; var o = new C(); var result = o instanceof C; // this IC fails to attach This change generalizes the IC attachment logic to check whether @@hasInstance is defined anywhere below Function in the prototype chain of the RHS. If not, it is still safe to attach the IC; the IC simply needs to guard on the prototype chain to ensure no @@hasInstance override is inserted later. Differential Revision: https://phabricator.services.mozilla.com/D42366
f48c581ece1bfd0f54d206d9f7d3bdf17789eded: Bug 1569063 - Refactor accessors for flags into BaseScript from JSScript and LazyScript. r=djvj,tcampbell
Chris Fallin <cfallin@mozilla.com> - Wed, 14 Aug 2019 22:07:51 +0000 - rev 488037
Push 36434 by cbrindusan@mozilla.com at Thu, 15 Aug 2019 09:44:30 +0000
Bug 1569063 - Refactor accessors for flags into BaseScript from JSScript and LazyScript. r=djvj,tcampbell Refactor accessors for flags into BaseScript from JSSript and LazyScript, following earlier change by tcampbell@ in a17d8450 to move flag enum definitions to common base. Differential Revision: https://phabricator.services.mozilla.com/D41839
e0fb78ca5c556091c725679639843627d095bc4e: Bug 1563889 - Use AutoEnterOOMUnsafeRegion in JitScript::ensureProfileString. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Thu, 01 Aug 2019 13:59:21 +0000 - rev 485786
Push 36373 by rmaries@mozilla.com at Fri, 02 Aug 2019 03:50:33 +0000
Bug 1563889 - Use AutoEnterOOMUnsafeRegion in JitScript::ensureProfileString. r=djvj Differential Revision: https://phabricator.services.mozilla.com/D38977
1487d7146b50d11e4d03b4ee8d5ca56f5209e123: Bug 1564337 - Rename BaselineCompiler.cpp/h to BaselineCodeGen.cpp/h. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Tue, 16 Jul 2019 18:29:30 +0000 - rev 483053
Push 36304 by dvarga@mozilla.com at Wed, 17 Jul 2019 15:47:02 +0000
Bug 1564337 - Rename BaselineCompiler.cpp/h to BaselineCodeGen.cpp/h. r=djvj Now that BaselineInterpreterGenerator is also defined there, it's nicer to use the name of the shared base class. Differential Revision: https://phabricator.services.mozilla.com/D38174
fbb42a9d132e10e96d275329bde3494f03714ba3: Bug 1505902: Clean up private Value representation r=djvj
Iain Ireland <iireland@mozilla.com> - Tue, 16 Jul 2019 19:10:30 +0000 - rev 483006
Push 36303 by dvarga@mozilla.com at Wed, 17 Jul 2019 09:36:40 +0000
Bug 1505902: Clean up private Value representation r=djvj Our previous representation of private values assumed that the private pointer was aligned, and did some bit twiddling to try to disguise it as a double. Since bug 1293313, it has been unnecessary to set the top bit for a double, so that bit twiddling is unnecessary. There are actual use cases where private values are unaligned, so we should fix this. While cleaning this up, I also removed unboxPrivateValue, because its only use could be better written using loadPrivateValue directly. Differential Revision: https://phabricator.services.mozilla.com/D38127
77bc29e90670098deb2fc7ce9f050a23f26e5f6e: Bug 1563510 part 3 - Use toggled jumps for more debugger instrumentation. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Tue, 09 Jul 2019 07:23:21 +0000 - rev 481834
Push 36265 by rgurzau@mozilla.com at Tue, 09 Jul 2019 15:37:42 +0000
Bug 1563510 part 3 - Use toggled jumps for more debugger instrumentation. r=djvj We now have a Vector of offsets instead of a single offset. Differential Revision: https://phabricator.services.mozilla.com/D36905
914ab31ebc59db337b02fbce5211088c8505522b: Bug 1563510 part 2 - Store function environment directly in emitInitFrameFields instead of storing nullptr first. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Tue, 09 Jul 2019 07:23:07 +0000 - rev 481833
Push 36265 by rgurzau@mozilla.com at Tue, 09 Jul 2019 15:37:42 +0000
Bug 1563510 part 2 - Store function environment directly in emitInitFrameFields instead of storing nullptr first. r=djvj Instead of initializing frame->environmentChain to nullptr first and then setting it to fun->environment() later, we can store fun->environment immediately. This also means the interpreter doesn't need to load and untag the callee token a second time. Differential Revision: https://phabricator.services.mozilla.com/D36904
e13e7f4d5f05a26980ff3246686cab93f76391d4: Bug 1563510 part 1 - Fold emitPreInitEnvironmentChain into emitInitFrameFields. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Tue, 09 Jul 2019 07:22:53 +0000 - rev 481832
Push 36265 by rgurzau@mozilla.com at Tue, 09 Jul 2019 15:37:42 +0000
Bug 1563510 part 1 - Fold emitPreInitEnvironmentChain into emitInitFrameFields. r=djvj This eliminates some branches and simplifies the code. Differential Revision: https://phabricator.services.mozilla.com/D36903
6a0498d1ac61fb944e84c5bccd9fc2a00a166602: Bug 1562602 part 1 - Fix JSJitProfilingFrameIterator::fixBaselineReturnAddress for interpreter frames. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Mon, 08 Jul 2019 08:18:58 +0000 - rev 481604
Push 36261 by nbeleuzu@mozilla.com at Tue, 09 Jul 2019 03:44:14 +0000
Bug 1562602 part 1 - Fix JSJitProfilingFrameIterator::fixBaselineReturnAddress for interpreter frames. r=djvj It needs to set resumePCinCurrentFrame_ to an address in the interpreter JitCode instead of nullptr (or else the profiler's JitCodeMap lookup will assert). Differential Revision: https://phabricator.services.mozilla.com/D36468
874fd6880afc7776b5d473cb186252a85a9c71bc: Bug 1562830 - Keep Baseline Interpreter bytecode pc in a register between VM/IC calls. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Sat, 06 Jul 2019 12:30:31 +0000 - rev 481540
Push 36249 by rmaries@mozilla.com at Sat, 06 Jul 2019 21:46:28 +0000
Bug 1562830 - Keep Baseline Interpreter bytecode pc in a register between VM/IC calls. r=djvj This is both simpler and faster than the old scheme where the pc was stored in a register but could be clobbered by R2. On x64 this wins about 9-10%. On 32-bit x86 we don't have enough registers so there we load the pc from the frame in more cases. That's about a 2-3% regression and is a reasonable trade-off. Differential Revision: https://phabricator.services.mozilla.com/D36583
01dd4bf87d24ac6492bddbbd28bb00021a6e6d23: Bug 1559072: MIPS fixes r=djvj
Iain Ireland <iireland@mozilla.com> - Tue, 25 Jun 2019 15:58:59 +0000 - rev 480158
Push 36205 by rgurzau@mozilla.com at Wed, 26 Jun 2019 21:52:21 +0000
Bug 1559072: MIPS fixes r=djvj Depends on D35549 Differential Revision: https://phabricator.services.mozilla.com/D35550
06eaa532a2da1eeb166d2ac0989d14af4f981b91: Bug 1559072: Revert Rust bindings to old boxing format r=djvj
Iain Ireland <iireland@mozilla.com> - Tue, 25 Jun 2019 17:11:15 +0000 - rev 480156
Push 36205 by rgurzau@mozilla.com at Wed, 26 Jun 2019 21:52:21 +0000
Bug 1559072: Revert Rust bindings to old boxing format r=djvj Depends on D35547 Differential Revision: https://phabricator.services.mozilla.com/D35548
0b15a4e88e9ce8752e2e527122bb18f9af72e09c: Bug 1559072: Revert to old boxing format r=djvj
Iain Ireland <iireland@mozilla.com> - Tue, 25 Jun 2019 17:34:50 +0000 - rev 480155
Push 36205 by rgurzau@mozilla.com at Wed, 26 Jun 2019 21:52:21 +0000
Bug 1559072: Revert to old boxing format r=djvj Differential Revision: https://phabricator.services.mozilla.com/D35547
ce56e2779818d25cfa2ac32f38ed84e6811d76a9: Bug 1551499 - Support Baseline Interpreter code in the profiler. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Fri, 21 Jun 2019 16:13:48 +0000 - rev 479811
Push 36183 by btara@mozilla.com at Fri, 21 Jun 2019 21:41:26 +0000
Bug 1551499 - Support Baseline Interpreter code in the profiler. r=djvj Because the return address cannot be used to uniquely identify script/pc, this is unfortunately quite different from what we do for Baseline/Ion code. The strategy is as follows: * When the profiler is enabled, ensure each JitScript has a pointer to the profile string (released when the script is finalized). * The BaselineInterpreter code is registered with the JitcodeMap. * The profiler code treats interpreter frames like C++ Interpreter frames, instead of doing the return address based mapping. Differential Revision: https://phabricator.services.mozilla.com/D31052
c9834e23330c28ee333fc83dfb8ba1cf1e113688: Bug 1541404 part 33 - Implement emitArgumentTypeChecks. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Wed, 15 May 2019 14:25:19 +0000 - rev 473940
Push 36019 by dvarga@mozilla.com at Wed, 15 May 2019 21:30:39 +0000
Bug 1541404 part 33 - Implement emitArgumentTypeChecks. r=djvj Differential Revision: https://phabricator.services.mozilla.com/D31039
ad2eae2743d4ffc3c0771efea055041e13b3954c: Bug 1541404 part 27 - Implement emitInterpreterLoop. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Wed, 15 May 2019 07:42:50 +0000 - rev 473897
Push 36018 by rgurzau@mozilla.com at Wed, 15 May 2019 15:58:16 +0000
Bug 1541404 part 27 - Implement emitInterpreterLoop. r=djvj This is a basic threaded interpreter design. Performance is pretty good but we can optimize it more in the future when everything else is in place. Differential Revision: https://phabricator.services.mozilla.com/D30370
8c4c1145857040627723cf4913e4d30702bd171c: Bug 1541404 part 25 - Various minor changes. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Fri, 10 May 2019 09:55:51 +0000 - rev 473374
Push 35996 by dvarga@mozilla.com at Fri, 10 May 2019 21:46:48 +0000
Bug 1541404 part 25 - Various minor changes. r=djvj Differential Revision: https://phabricator.services.mozilla.com/D29993
8da1d9e605dd7218ced00da67ec09c3e37565147: Bug 1541404 part 23 - Implement more BaselineInterpreterGenerator bits. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Fri, 10 May 2019 09:55:49 +0000 - rev 473373
Push 35996 by dvarga@mozilla.com at Fri, 10 May 2019 21:46:48 +0000
Bug 1541404 part 23 - Implement more BaselineInterpreterGenerator bits. r=djvj Differential Revision: https://phabricator.services.mozilla.com/D29989
b84d8c19fdea4022e92173ae3cb8b1ab284cf7af: Bug 1541404 part 22 - Add BaselineInterpreterGenerator::emitDebugTrap. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Fri, 10 May 2019 09:55:47 +0000 - rev 473372
Push 35996 by dvarga@mozilla.com at Fri, 10 May 2019 21:46:48 +0000
Bug 1541404 part 22 - Add BaselineInterpreterGenerator::emitDebugTrap. r=djvj Differential Revision: https://phabricator.services.mozilla.com/D29818
16ed123dc40181c309ed40a34b83ae3756136169: Bug 1541404 part 20 - Implement more BaselineInterpreterCodegen bits. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Wed, 08 May 2019 08:18:41 +0000 - rev 473032
Push 35986 by opoprus@mozilla.com at Wed, 08 May 2019 21:49:24 +0000
Bug 1541404 part 20 - Implement more BaselineInterpreterCodegen bits. r=djvj Differential Revision: https://phabricator.services.mozilla.com/D29463
e8322e4b5e3cdb01ba1449fad87234ae0ed9e617: Bug 1541404 part 17 - Fix InterpreterFrameInfo::popn to account for sizeof(Value). r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Thu, 25 Apr 2019 12:49:34 +0000 - rev 471474
Push 35920 by aiakab@mozilla.com at Fri, 26 Apr 2019 22:02:33 +0000
Bug 1541404 part 17 - Fix InterpreterFrameInfo::popn to account for sizeof(Value). r=djvj Differential Revision: https://phabricator.services.mozilla.com/D28596
ef9c8c88826b9823c01fd8fd4f8441bbde105ea3: Bug 1541404 part 14 - BaselineCompiler changes for JSOP_RESUME. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Wed, 24 Apr 2019 13:32:40 +0000 - rev 470652
Push 35910 by cbrindusan@mozilla.com at Wed, 24 Apr 2019 21:51:39 +0000
Bug 1541404 part 14 - BaselineCompiler changes for JSOP_RESUME. r=djvj When the Baseline Interpreter is enabled unconditionally we will be able to simplify this a bit more, but for now we support both cases. Differential Revision: https://phabricator.services.mozilla.com/D27665
8d11a480d4ae56576b438cfcf5baf1876db25565: Bug 1541404 part 1 - Move initEnvironmentChain from BaselineCompiler to BaselineCodeGen. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Fri, 12 Apr 2019 14:08:03 +0000 - rev 469471
Push 35872 by ncsoregi@mozilla.com at Mon, 15 Apr 2019 15:24:06 +0000
Bug 1541404 part 1 - Move initEnvironmentChain from BaselineCompiler to BaselineCodeGen. r=djvj Also has some other minor prologue-related changes. The interpreter code here is slightly less optimal than it could be, but that will be easier to address in follow-up changes. Differential Revision: https://phabricator.services.mozilla.com/D25930
eb4c19482386cbb55cdf5b24941fba456fa6b522: Bug 1522837 part 16 - Implement pushUint8BytecodeOperandArg and pushUint16BytecodeOperandArg in BaselineInterpreterCodeGen. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Thu, 28 Mar 2019 14:05:50 +0000 - rev 467750
Push 35810 by aciure@mozilla.com at Thu, 04 Apr 2019 04:33:36 +0000
Bug 1522837 part 16 - Implement pushUint8BytecodeOperandArg and pushUint16BytecodeOperandArg in BaselineInterpreterCodeGen. r=djvj Differential Revision: https://phabricator.services.mozilla.com/D23299
9b45c3cf37c678a5436d075fb9b347b53b132f93: Bug 1522837 part 15 - Implement aliased var ops in BaselineInterpreterCodeGen. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Tue, 02 Apr 2019 15:32:28 +0000 - rev 467749
Push 35810 by aciure@mozilla.com at Thu, 04 Apr 2019 04:33:36 +0000
Bug 1522837 part 15 - Implement aliased var ops in BaselineInterpreterCodeGen. r=djvj Differential Revision: https://phabricator.services.mozilla.com/D23298
91117189b7787e2e0ac4d05aa79d4dad65cb3f8f: Bug 1522837 part 14 - Implement JSOP_ENVCALLEE, JSOP_NEWTARGET and JSOP_CHECKLEXICAL in BaselineInterpreterCodeGen. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Wed, 03 Apr 2019 07:32:45 +0000 - rev 467748
Push 35810 by aciure@mozilla.com at Thu, 04 Apr 2019 04:33:36 +0000
Bug 1522837 part 14 - Implement JSOP_ENVCALLEE, JSOP_NEWTARGET and JSOP_CHECKLEXICAL in BaselineInterpreterCodeGen. r=djvj The JSOP_NEWTARGET code for non-arrow functions now uses cmov instead of an if-else. This is a bit simpler (especially for the interpreter) and shorter and I didn't see any difference in performance in some Baseline new.target micro-benchmarks. Differential Revision: https://phabricator.services.mozilla.com/D22971
0360f25e31db4b8a9358d13152f3c0b44b0369e4: Bug 1522837 part 13 - Implement emitFormalArgAccess in BaselineCodeGen. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Sun, 10 Mar 2019 19:44:06 +0000 - rev 463418
Push 35678 by rgurzau@mozilla.com at Mon, 11 Mar 2019 09:34:25 +0000
Bug 1522837 part 13 - Implement emitFormalArgAccess in BaselineCodeGen. r=djvj Differential Revision: https://phabricator.services.mozilla.com/D19174
cbba4888990efd52952797d97b60e06dfddc7aac: Bug 1522837 part 12 - Support JSOP_NEWARRAY and JSOP_INITELEM_ARRAY in BaselineCodeGen. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Sun, 10 Mar 2019 19:43:44 +0000 - rev 463417
Push 35678 by rgurzau@mozilla.com at Mon, 11 Mar 2019 09:34:25 +0000
Bug 1522837 part 12 - Support JSOP_NEWARRAY and JSOP_INITELEM_ARRAY in BaselineCodeGen. r=djvj Differential Revision: https://phabricator.services.mozilla.com/D19173
7a376bfac6dea0340625911e8bb02ad30c21d5e8: Bug 1522837 part 11 - Implement some simple ops in BaselineInterpreterCodeGen. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Sun, 10 Mar 2019 19:43:26 +0000 - rev 463416
Push 35678 by rgurzau@mozilla.com at Mon, 11 Mar 2019 09:34:25 +0000
Bug 1522837 part 11 - Implement some simple ops in BaselineInterpreterCodeGen. r=djvj Differential Revision: https://phabricator.services.mozilla.com/D18253
cb6108540cef8f493ec19b75517e8d7c70501a59: Bug 1522837 part 10 - Add interpreter fields to BaselineFrame. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Sun, 10 Mar 2019 19:43:08 +0000 - rev 463415
Push 35678 by rgurzau@mozilla.com at Mon, 11 Mar 2019 09:34:25 +0000
Bug 1522837 part 10 - Add interpreter fields to BaselineFrame. r=djvj Differential Revision: https://phabricator.services.mozilla.com/D18252
a8bb75678922337675d05ec4c7261ab34dfb995b: Bug 1384808 - Implement a linear cache for searching the shape lineage r=djvj
Denis Palmeiro <dpalmeiro@mozilla.com> - Sun, 03 Feb 2019 00:03:35 +0000 - rev 456643
Push 35498 by ccoroiu@mozilla.com at Mon, 04 Feb 2019 21:41:17 +0000
Bug 1384808 - Implement a linear cache for searching the shape lineage r=djvj Linearly searching the shape lineage can be expensive. It is going to cause branch misses and cache misses since we are traversing a linked list. Since this is done frequently enough, it may be worth while to "cache" results from the linear search. This revision hopes to lazily allocate a small linear cache after the first linear search on a shape. The results from each linear search afterwards will be placed into the cache. If the jsid that is being searched for is frequently looked up then we obtain a "cache hit" from a quick search in the cache. Otherwise, we fall back to a linear search and append the new entry to the cache. Once the cache is full, it will transform into a shape hash table like the previous approach. Differential Revision: https://phabricator.services.mozilla.com/D12155
a9e0cc55d71ad830d58994bc994b7aba1df69ac6: Bug 1522837 part 1 - Implement loadScript, emitInitializeLocals, storeFrameSizeAndPushDescriptor for BaselineInterpreterHandler. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Sun, 03 Feb 2019 10:06:39 +0000 - rev 456583
Push 35492 by cbrindusan@mozilla.com at Sun, 03 Feb 2019 21:40:38 +0000
Bug 1522837 part 1 - Implement loadScript, emitInitializeLocals, storeFrameSizeAndPushDescriptor for BaselineInterpreterHandler. r=djvj This also removes computeFullFrameSize because we don't really need it. Differential Revision: https://phabricator.services.mozilla.com/D17644
3eeb76f0f5d8b02423b0701b8dcf3306c6578178: Bug 1522837 part 1 - Implement loadScript, emitInitializeLocals, storeFrameSizeAndPushDescriptor for BaselineInterpreterHandler. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Thu, 31 Jan 2019 20:06:06 +0000 - rev 456383
Push 35483 by aciure@mozilla.com at Fri, 01 Feb 2019 17:55:19 +0000
Bug 1522837 part 1 - Implement loadScript, emitInitializeLocals, storeFrameSizeAndPushDescriptor for BaselineInterpreterHandler. r=djvj This also removes computeFullFrameSize because we don't really need it. Differential Revision: https://phabricator.services.mozilla.com/D17644
e9fb9b21984703366a643e6472cedff5726d7ee4: Bug 1522792 part 3 - Add some offsetOf methods we will need later. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Mon, 28 Jan 2019 20:40:14 +0000 - rev 455871
Push 35462 by shindli@mozilla.com at Tue, 29 Jan 2019 21:36:31 +0000
Bug 1522792 part 3 - Add some offsetOf methods we will need later. r=djvj Depends on D17624 Differential Revision: https://phabricator.services.mozilla.com/D17625
dd40395ed807a09a53b06be1176c6000870f6e68: Bug 1520744 - Move prologue/epilogue methods from BaselineCompiler to BaselineCodeGen. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Sun, 27 Jan 2019 08:55:18 +0000 - rev 455567
Push 35446 by btara@mozilla.com at Sun, 27 Jan 2019 21:32:00 +0000
Bug 1520744 - Move prologue/epilogue methods from BaselineCompiler to BaselineCodeGen. r=djvj This will change a bit in the future but I think this is a reasonable initial version. Differential Revision: https://phabricator.services.mozilla.com/D16801
ef038a8b19442250bef744c830b4fecb884ad426: Bug 1520452 part 2 - Move remaining compiler-specific fields from BaselineCodeGen to BaselineCompilerHandler. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Sun, 27 Jan 2019 08:54:48 +0000 - rev 455565
Push 35446 by btara@mozilla.com at Sun, 27 Jan 2019 21:32:00 +0000
Bug 1520452 part 2 - Move remaining compiler-specific fields from BaselineCodeGen to BaselineCompilerHandler. r=djvj Differential Revision: https://phabricator.services.mozilla.com/D16690
eff43158adb80f26363c448b52f5d37dbfae7575: Bug 1522075 part 3 - Add MacroAssembler::guardedCallPreBarrierAnyZone for use in trampolines. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Thu, 24 Jan 2019 17:36:12 +0000 - rev 455292
Push 35428 by nbeleuzu@mozilla.com at Thu, 24 Jan 2019 21:42:11 +0000
Bug 1522075 part 3 - Add MacroAssembler::guardedCallPreBarrierAnyZone for use in trampolines. r=djvj When generating the interpreter, we assert in guardedCallPreBarrier because JitContext::realm is nullptr. This adds guardedCallPreBarrierAnyZone for that use case: it loads cx->zone dynamically instead of baking it in. Differential Revision: https://phabricator.services.mozilla.com/D17367
59e188c6e83500abb433777237af9ba231901445: Bug 1522075 part 2 - Move prepareVMCall calls into lambdas because prepareVMCall and callVM have to be balanced. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Thu, 24 Jan 2019 17:35:47 +0000 - rev 455291
Push 35428 by nbeleuzu@mozilla.com at Thu, 24 Jan 2019 21:42:11 +0000
Bug 1522075 part 2 - Move prepareVMCall calls into lambdas because prepareVMCall and callVM have to be balanced. r=djvj This fixes some assertion failures when generating the interpreter. Differential Revision: https://phabricator.services.mozilla.com/D17366
d42906b3c65e3009761774c8353a5104335ac4c6: Bug 1520452 part 1 - Move script field from BaselineCodeGen to BaselineCompilerHandler. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Thu, 24 Jan 2019 12:59:04 +0000 - rev 455264
Push 35428 by nbeleuzu@mozilla.com at Thu, 24 Jan 2019 21:42:11 +0000
Bug 1520452 part 1 - Move script field from BaselineCodeGen to BaselineCompilerHandler. r=djvj Differential Revision: https://phabricator.services.mozilla.com/D16689
d11bb3bd81951e0e5a66bc9e3ae80ca22d2ad13f: Bug 1519880 part 2 - Split Baseline's FrameInfo class in CompilerFrameInfo and InterpreterFrameInfo. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Thu, 17 Jan 2019 12:19:06 +0000 - rev 454266
Push 35390 by shindli@mozilla.com at Thu, 17 Jan 2019 16:13:20 +0000
Bug 1519880 part 2 - Split Baseline's FrameInfo class in CompilerFrameInfo and InterpreterFrameInfo. r=djvj InterpreterFrameInfo is just a very simple interface on top of masm. CompilerFrameInfo maintains the virtual stack based on the script it's compiling. Differential Revision: https://phabricator.services.mozilla.com/D16480
f24ec43206d74a563fbd401faf3761dde41707f8: Bug 1519880 part 1 - Stop exposing StackValue* to BaselineCodeGen. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Thu, 17 Jan 2019 12:18:35 +0000 - rev 454265
Push 35390 by shindli@mozilla.com at Thu, 17 Jan 2019 16:13:20 +0000
Bug 1519880 part 1 - Stop exposing StackValue* to BaselineCodeGen. r=djvj The interpreter won't use the virtual stack and StackValue, so we need to refactor things a bit so we don't call frame.peek(x) outside the FrameInfo class. StackValue will be just an implementation detail of CompilerFrameInfo in the next patch. Differential Revision: https://phabricator.services.mozilla.com/D16479
cbe224190304b678b8ca0c9647cd5989e3a93609: Bug 1519792 part 2 - Move pc field from BaselineCodeGen to BaselineCompilerHandler. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Thu, 17 Jan 2019 09:20:15 +0000 - rev 454249
Push 35390 by shindli@mozilla.com at Thu, 17 Jan 2019 16:13:20 +0000
Bug 1519792 part 2 - Move pc field from BaselineCodeGen to BaselineCompilerHandler. r=djvj JSOPs like JSOP_INT8 that depend on the pc need to be specialized now for the interpreter. I added MOZ_CRASH versions of these that we can implement later. This split is a bit pessimistic: we should actually (partially) share codegen for some of these ops like JSOP_RESUME. However it's easier to revisit this later when we need to implement these ops for the interpreter. Differential Revision: https://phabricator.services.mozilla.com/D16442
1e52ffae5eb49e06edc3ec9701e3365ef7649c78: Bug 1519792 part 1 - Move some BaselineCompiler methods to the end of the file. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Thu, 17 Jan 2019 09:19:50 +0000 - rev 454248
Push 35390 by shindli@mozilla.com at Thu, 17 Jan 2019 16:13:20 +0000
Bug 1519792 part 1 - Move some BaselineCompiler methods to the end of the file. r=djvj The next patch will template-specialize some of the emit_JSOP_FOO methods, but the C++ compiler wants that to happen before we call these methods in emitBody. Differential Revision: https://phabricator.services.mozilla.com/D16441
00614ec6e765206c325364b51b8810fddf29234d: Bug 1519779 - Add some helper methods for pushing script/pc or script name/object/scope for VM calls in BaselineCodeGen. r=djvj
Jan de Mooij <jdemooij@mozilla.com> - Wed, 16 Jan 2019 21:05:31 +0000 - rev 454244
Push 35390 by shindli@mozilla.com at Thu, 17 Jan 2019 16:13:20 +0000
Bug 1519779 - Add some helper methods for pushing script/pc or script name/object/scope for VM calls in BaselineCodeGen. r=djvj Interpreter and compiler will implement these differently, but this allows sharing codegen for a large number of JSOps. Differential Revision: https://phabricator.services.mozilla.com/D16438
9882be81c9e458ee7db63788f01ac8a85a47df72: Bug 1519700: Add testcase to jit-tests r=djvj
Iain Ireland <iireland@mozilla.com> - Wed, 16 Jan 2019 19:02:05 +0000 - rev 454135
Push 35387 by aiakab@mozilla.com at Thu, 17 Jan 2019 04:19:37 +0000
Bug 1519700: Add testcase to jit-tests r=djvj Differential Revision: https://phabricator.services.mozilla.com/D16512