BaselineCompiler: IonCompile scripts when their useCounts get high from within baseline

RESOLVED FIXED

Status

()

Core
JavaScript Engine
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: djvj, Assigned: djvj)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
Currently, OSR takes care of entering Ion from within loops.  However, if a function contains no loops, and it's been baseline-compiled, then it will never get Ion compiled because the UseCount fallback stub only compiles on LOOPENTRY ops.

Fix the UseCount stub to ion-compile (but not enter) scripts with high use counts.
(Assignee)

Updated

5 years ago
Assignee: general → kvijayan
(Assignee)

Comment 1

5 years ago
Created attachment 710430 [details] [diff] [review]
Patch

Note: I realize I'll have to rebase these changes around your fixes to the OSR code.  Shouldn't be too bad though.

This patch does a couple of things:
Changes UseCount_Fallback to store a copy of the script and the pcOffset so that it's not expensive to retrieve.  It may be feasible to remove these once we adopt the proper practice of inserting case-specific optimized stubs (I've added TODOs for that) to avoid reaching the fallback stub in the first place.

It also changes the DoUseCountFallback function to potentially invoke an ion compilation even if the PC is not at a LOOPENTRY.  The expectation is that the next time the function is entered, we'll enter the ion code.

This cuts access-binary-trees runtime to a third of what it was before with baseline+Ion.
Attachment #710430 - Flags: review?(jdemooij)
Comment on attachment 710430 [details] [diff] [review]
Patch

Review of attachment 710430 [details] [diff] [review]:
-----------------------------------------------------------------

Nice, r=me with the comment below addressed.

::: js/src/ion/BaselineIC.h
@@ +829,5 @@
>  class ICUseCount_Fallback : public ICFallbackStub
>  {
>      friend class ICStubSpace;
> +    HeapPtrScript script_;
> +    uint32_t pcOffset_;

With the OSR patch I just pushed, we don't have to store the script here but can get it from the BaselineFrame * pointer passed in. We can get the pcOffset from icEntry()->pcOffset() I think. Especially b2g has very strict memory requirements, so every word we can save in our IC stubs is great.
Attachment #710430 - Flags: review?(jdemooij) → review+
(Assignee)

Comment 3

5 years ago
https://hg.mozilla.org/projects/ionmonkey/rev/10f51d74f9f3
(Assignee)

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.