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

ASSIGNED
Assigned to

Status

()

Core
JavaScript Engine: JIT
P3
normal
ASSIGNED
6 months ago
5 days ago

People

(Reporter: arai, Assigned: arai)

Tracking

({triage-deferred})

Trunk
triage-deferred
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

6 months ago
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.
(Assignee)

Comment 2

6 months ago
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
(Assignee)

Comment 3

6 months ago
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
(Assignee)

Comment 5

17 days ago
hmm, properly monitoring type information per signature in Baseline requires a lot of modification, because of the optimization there...
You need to log in before you can comment on or make changes to this bug.