Open Bug 1375495 Opened 7 years ago Updated 2 years ago

Can we store type information for inlining separately from standalone JIT compiling?

Categories

(Core :: JavaScript Engine: JIT, enhancement, P3)

enhancement

Tracking

()

ASSIGNED

People

(Reporter: arai, Assigned: arai)

References

Details

(Keywords: triage-deferred)

derived from bug 1366263.

currently type information is stored per script. that means if the function is called from different place with different types, those 2 type information will be mixed in TypeScript.  While inlining the function, type information collected from other callsite could make the quality of the generated code worse, and also introduce unnecessary inlining while JIT compiling.

If we could store type information per each callsite, or maybe argument type combinations, we could generate better inlined code, and also reduce the JIT compilation time.
(In reply to Tooru Fujisawa [:arai] from comment #0)
> If we could store type information per each callsite, or maybe argument type
> combinations, we could generate better inlined code, and also reduce the JIT
> compilation time.

Being able to map a signature (arguments types) to an array of StackTypeSet sounds like an interesting approach.

In which case all monitoring function should be called with either the current set of arguments, or a way to identify the current signature of arguments.

CC bhackett, as he knows all the ins and outs of the type inference.
maybe, it needs some more trick in addition to store type information purely per each signature, since multiple signature can be used in single callsite, and in that case we need a way to get the list of signature or type information for single callsite, while inlining.

so, what we actually need would be:
  1. being able to get the type information suitable for inlining the function at specific callsite, that is:
    * all type information used at the callsite
    * reduce the effect of type information from other unrelated callsite as much as possible
  2. being able to get merged type information for standalone JIT compiling
  3. store the type information in efficient way
I'm going to take this as long-term bug.
Assignee: nobody → arai.unmht
Status: NEW → ASSIGNED
This is a bit like the "callsite cloning" mechanism we had for PJS. It's a hard problem to solve, but it's worth exploring.
Keywords: triage-deferred
Priority: -- → P3
hmm, properly monitoring type information per signature in Baseline requires a lot of modification, because of the optimization there...
the main issue is, type monitoring is omitted in Baseline when it's no more necessary in current type feedback,
that is, if type is known and it won't change (guarded by optimized path).

for example, if JSOP_LENGTH is applied to ArrayObject, type monitoring is omitted for optimized path (GetPropIRGenerator::tryAttachObjectLength).

when storing type information per each signature, we should monitor what type appears for each signature.
so, whether the type monitoring is necessary or not differs than current situation.

at least we should check signature in optimized path, to see if the signature is already checked or not.
I wonder, would it be helpful if we were able to know the frequency of each call-site, prior to splitting the type information from a generic type info into a specific to a given call-site?

I am planning to get similar info for improving our inlining decision, and improving our devtools, by changing the way we aggregate code coverage information.  Does that sounds like something interesting to add / depend on?
(In reply to Nicolas B. Pierron [:nbp] from comment #7)
> I wonder, would it be helpful if we were able to know the frequency of each
> call-site, prior to splitting the type information from a generic type info
> into a specific to a given call-site?
> 
> I am planning to get similar info for improving our inlining decision, and
> improving our devtools, by changing the way we aggregate code coverage
> information.  Does that sounds like something interesting to add / depend on?

currently I'm always using per-signature type info (so, it's already split from the beginning).
I agree that it's better using generic (single) type info if storing per each signature is not so much useful for the function (based on callsites usage/frequency), but I haven't yet reached at that point.

thanks anyway :)
See Also: → 1487366
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.