Skip to content
GitLab
Switch branch/tag
  1. 20 Mar, 2019 2 commits
  3. 19 Mar, 2019 1 commit
  5. 20 Mar, 2019 13 commits
  7. 19 Mar, 2019 10 commits
    • Iain Ireland's avatar
      Bug 1533890: Add scripted constructor support to CacheIR r=mgaudet · c87e4c23
      Iain Ireland authored 
      This patch adds support for scripted constructors, using the existing template object infrastructure.

Comparison points:
- BaselineCacheIRCompiler::createThis/updateReturnValue correspond to big "if (isConstructing) ..." blocks in ICCallScriptedCompiler::generateStubCode.
- CallIRGenerator::getTemplateObjectForScripted corresponds to the block in tryAttachCallStub starting with the comment "// Remember the template object ..."

Notes:
1. In the original CreateThis code, there was the following comment:
  // Reload callee script. Note that a GC triggered by CreateThis may
  // have destroyed the callee BaselineScript and IonScript. CreateThis
  // is safely repeatable though, so in this case we just leave the stub
  // frame and jump to the next stub.
This comment was out of date; as of bug 1415853, the code pointer is always valid. The comment does not exist in the new version.

2. Bug 870478 added code to the old version of |updateReturnValue| to load |this| from the baseline frame instead of the baseline stub frame, because we would not trace the copy of |this| if a rectifier frame was created. A better fix was delivered in bug 945275 (we now trace |this| in rectifier frames). The new version of |updateReturnValue| loads |this| out of the stub frame, because it is both easier to read and more efficient.

3. Unlike BaselineInspector::getTemplateObjectFor(Native|ClassHook), the scripted version does not use the callee as a guard to make sure that we have the correct template object. This is the same as the status quo. It works because we only retrieve the template object if the IC chain has exactly one non-fallback stub. We still store the callee in the metadata, because it is needed for BaselineInspector::getSingleCallee. This whole area of the BaselineInspector API should probably be redesigned, but it seemed out of scope for this patch.

Differential Revision: https://phabricator.services.mozilla.com/D22782

--HG--
extra : moz-landing-system : lando
      c87e4c23
    • Iain Ireland's avatar
      Bug 1533890: Add native constructor call support to CacheIR r=mgaudet · 3c073ca1
      Iain Ireland authored 
      This patch uses the infrastructure from the previous patch to add constructor support for native calls.

Comparison points:
- CallIRGenerator::getTemplateObjectForNative corresponds to GetTemplateObjectForNative in BaselineIC.cpp

Differential Revision: https://phabricator.services.mozilla.com/D22781

--HG--
extra : moz-landing-system : lando
      3c073ca1
    • Iain Ireland's avatar
      Bug 1533890: Add constructor hook support to CacheIR r=mgaudet · 27304d17
      Iain Ireland authored 
      Constructor stubs in the existing implementation contain template objects, which are unused by the stub itself but consumed by Ion. To make this work in CacheIR, this patch introduces meta ops, which generate no code but can be consumed by BaselineInspector.

This patch adds the infrastructure for meta ops and uses it to implement constructor class hooks, because it is a simple place to start. Subsequent patches add support for native constructor calls and scripted constructor calls.

In each case, BaselineInspector needs two pieces of information: a) The template object itself, and b) the callee, which BaselineInspector checks to make sure it is getting the correct template object. (The precise nature of the template object varies: it's a class pointer for hooks, but a pointer to the actual callee object for native and scripted constructors.) The meta op's arguments are a tag (in this case, "ClassTemplateObject") and two stub field offsets. NB: the class offset is reused from an earlier guard. To make this work, addStubField now returns the offset of the new field.

Other notes:

1. I changed an assertion in CompactBufferReader::seek to make it possible to seek directly to the end of the buffer. This is safe, because we already check to make sure we aren't at the end before reading from the buffer.
2. It turns out that the code to iterate through CacheIR bytecode is nicer if the CacheIR op table defines the length of the arguments to an op, without including the op itself. I made the change.

Comparison points:
- CallIRGenerator::getTemplateObjectForClassHook corresponds to GetTemplateObjectForClassHook in BaselineIC.cpp

Differential Revision: https://phabricator.services.mozilla.com/D22780

--HG--
extra : moz-landing-system : lando
      27304d17
    • Iain Ireland's avatar
      Bug 1528270: Clean up pushCallArguments and pushSpreadCallArguments r=mgaudet · 90b37eb4
      Iain Ireland authored 
      This patch makes a couple of improvements to pushCallArguments, and one improvement to pushSpreadCallArguments.

1. The old code used two instructions to generate argPtr, where one instruction will do.
2. The old code jumped through some hoops to avoid adding |callee| and |this| to count before aligning the stack for jit frames. However, AlignJitStackBasedOnNArgs only cares whether nargs is even or odd. Since it doesn't make a difference whether we add 2 to nargs before or after alignment, this patch removes the "optimization".
3. The previous version of pushSpreadCallArguments used three instructions to find the end of the argument array, where one computeEffectiveAddress would do.

(It also improves the comments.)

Differential Revision: https://phabricator.services.mozilla.com/D22779

--HG--
extra : moz-landing-system : lando
      90b37eb4
    • Iain Ireland's avatar
      Bug 1533890: Add spread call support to CacheIR r=mgaudet · bef7376a
      Iain Ireland authored 
      This patch adds spread call support for scripted calls, native calls, and class hooks. (The old code did not have spread support for class hooks, but it's easy to add.)

Notes:
1. We don't support spread constructors yet. That will come later, after regular constructors are supported.
2. The old implementation called ICCallStubCompiler::guardSpreadCall to limit the size of the spread array. As an undocumented side-effect, guardSpreadCall also modifies the argc input register. The CacheIR version uses a fresh register, and relies on the magic of the CacheIR register allocator to preserve the input register.

Comparison points:
- GuardAndGetSpreadArgc corresponds to ICCallStubCompiler::guardSpreadCall.
- BaselineCacheIRCompiler::pushSpreadCallArguments corresponds to ICCallStubCompiler::pushSpreadCallArguments
- DoSpreadCallFallback is modified to correspond to DoCallFallback.

Differential Revision: https://phabricator.services.mozilla.com/D22778

--HG--
extra : moz-landing-system : lando
      bef7376a
    • Iain Ireland's avatar
      Bug 1533890: Migrate call hooks to CacheIR r=mgaudet · 9f41a88b
      Iain Ireland authored 
      This patch implements class hooks in CacheIR. It only supports call hooks; constructor calls are handled in a later patch.

The implementation of class hooks overlaps almost completely with the implementation of native calls; the only difference is how we load the address of the callee.

Comparison points:
- The old logic is in TryAttachCallStub and ICCall_ClassHook::Compiler::generateStubCode.

Differential Revision: https://phabricator.services.mozilla.com/D22777

--HG--
extra : moz-landing-system : lando
      9f41a88b
    • Iain Ireland's avatar
      Bug 1533890: Migrate CallScripted to CacheIR r=mgaudet · c9173651
      Iain Ireland authored 
      This patch implements calls to native functions in CacheIR. Spread calls and constructor calls are handled in a later patch.

Notes:
1. This patch adds GuardFunctionHasJitEntry as a separate CacheIR op, which guards against relazification. The same functionality currently exists inside of ScriptedGetterResult. My original intent was to refactor ScriptedGetterResult to use the op, but if Ted's plans to add a delazification trampoline work out then the issue goes away entirely and we can just delete both versions of the code.
2. Like the callNative patch, this patch bakes argc into the stub code.
3. The existing code pops callee off the stack and unboxes it, immediately after copying the args. This doesn't make any sense, because we have already unboxed it once and it's still in a register.
4. There are a couple of places in tryAttachCallScripted where we want to decline to attach without counting it as a failure. Right now, if the CacheIR path fails, the old implementation will do the right thing for us. A future patch will add isTemporarilyUnoptimizable support to CallIRGenerator.

Comparison points:
   - CallIRGenerator::tryAttachCallScripted and BaselineCacheIRCompiler::emitCallScriptedFunction correspond to TryAttachCallStub and ICCallScriptedCompiler::generateStubCode

Differential Revision: https://phabricator.services.mozilla.com/D22776

--HG--
extra : moz-landing-system : lando
      c9173651
    • Iain Ireland's avatar
      Bug 1533890: Add simulator support for IgnoresReturnValue version of native functions r=mgaudet · 97c11967
      Iain Ireland authored 
      Native calls in the simulator have to be redirected to a special swi instruction. In the old implementation, this redirection did not support calling the IgnoresReturnValue version of a native function. This patch fixes that problem in the new implementation.

Differential Revision: https://phabricator.services.mozilla.com/D22775

--HG--
extra : moz-landing-system : lando
      97c11967
    • Iain Ireland's avatar
      Bug 1533890: Migrate CallNative to CacheIR r=mgaudet · 777a20a7
      Iain Ireland authored 
      This patch implements calls to native functions in CacheIR. Spread calls and constructor calls are handled in a later patch.

Notes:

1. When running in the simulator, native call stubs have an extra stub field to hold the redirected swi wrapper. We use some ugly ifdefs to make that work.
2. The simulator version of native call stubs also doesn't support ignoresReturnValue calls. This bug is fixed in a later patch.
3. pushCallArguments is based directly on the existing code. A later patch improves the comments and tightens up the generated code.
4. Compared to the previous implementation, this patch bakes argc into each stub (by using it to compute the address of |callee| in tryAttachCallNative). This increases the number of versions of the stub code we generate by some (hopefully small) factor. In a future patch (not yet written), this will be changed so that we unroll the loop in pushCallArguments for small argc, and share stub code for large argc.

Comparison points:
   - BaselineCacheIRCompiler::pushCallArguments corresponds to ICCallStubCompiler::pushCallArguments
   - CallIRGenerator::tryAttachCallNative and BaselineCacheIRCompiler::emitCallNativeFunction correspond to TryAttachCallStub and ICCall_Native::Compiler::generateStubCode. (The dividing line between the two functions is different between the old and new code, but aside from the exceptions detailed above the logic should be the same.)

Differential Revision: https://phabricator.services.mozilla.com/D22774

--HG--
extra : moz-landing-system : lando
      777a20a7
    • Iain Ireland's avatar
      Bug 1533890: Refactor TryAttachCallStub and add disableCacheIRCalls pref r=mgaudet · 02c1f979
      Iain Ireland authored 
      This patch lays the groundwork for CacheIR call ICs. It refactors CallIRGenerator slightly, and adds a preference (on by default) to disable the new ICs. This lets us review and land future patches in a logical order without worrying about the attachment order of the new ICs vs the old ones. (For example, we don't want a CacheIR implementation of CallNative to shadow the old implementation of CallScriptedFunApply.)

I also removed the old disableCacheIRBinaryArith pref, after confirming with Matt that it is obsolete.

To avoid huge diffs every time the length of the longest CacheIR op changes, I padded the table out to 80 chars with a comment. Thanks, clang-format!

Differential Revision: https://phabricator.services.mozilla.com/D22773

--HG--
extra : moz-landing-system : lando
      02c1f979
  9. 20 Mar, 2019 5 commits
  11. 18 Mar, 2019 1 commit
  13. 20 Mar, 2019 1 commit
  15. 19 Mar, 2019 1 commit
  17. 20 Mar, 2019 2 commits
  19. 19 Mar, 2019 1 commit
    • Petru Lingurar's avatar
      Bug 1534213 - Reduce the number of WebpageItemRow layout refreshes; r=JanH · bee3c060
      Petru Lingurar authored 
      Previously, WebpageItemRow's layout would be updated everytime a new Tab for
it's url would be ADDED/CLOSED/LOCATION_CHANGED to force a recheck of the need
to show the "Switch to tab hint".
To prevent multiple layout refreshes for every such event we will check the
current display status of the "Switch to tab hint" against the newly computed
value after an ADDED/CLOSED/LOCATION_CHANGED event was received.
Eagerly changing the value for 'switchToTabHintShown' along with informing
about the need for layout refresh to prevent any race conditions between
receiving more events and actualy refreshing the layout.
(In my tests I saw ADDED/LOCATION_CHANGE refreshing the same layout needlessly)

Differential Revision: https://phabricator.services.mozilla.com/D24013

--HG--
extra : moz-landing-system : lando
      bee3c060
  21. 20 Mar, 2019 3 commits