IonMonkey/MIR: Difference between revisions

mNo edit summary
Line 110: Line 110:
==Specialization==
==Specialization==


''Found in: <tt>ion/TypeOracle.h</tt>''
''Found in: <tt>jit/IonBuilder.cpp</tt>''


While building MIR, we attempt to attach type information to certain nodes. For example, the likely inputs and outputs of arithmetic operations, the likely targets of a call, or the likely shapes of objects for property accesses. This information is queried from a <tt>TypeOracle</tt>. Currently, there is only one (bogus) oracle, but oracles based on Brian Hackett's type inference, and runtime profiling, are planned.
While building MIR, we attempt to attach type information to certain nodes. For example, the likely inputs and outputs of arithmetic operations, the likely targets of a call, or the likely shapes of objects for property accesses. This information is retrieved from Type Inference or baseline caches.


The oracle helps guide specialization. There are generally three modes of specialization:
Type Inference:
* Unknown. Nothing is known about the operation, and it may have to be assumed effectful.
During execution the types are saved and TI gives back this list of output types that were observed. During compilation this list is frozen and cannot get adjusted anymore without requiring to invalidate the IonScript based on this type information.
* Observed. A particular type (or set of types) has been observed, so we will compile expecting those. This may introduce guard instructions which protect these assumptions, deoptimizing if the guards do not hold.
 
* Known. A particular type has been proven to hold (for example, via type inference).
Baseline Engine:
During execution the baseline compiler needs to create specialized stubs. When specializing we can take put specialized information on those stubs and use these hints to better optimize the MIR nodes. Since those are hints we still need to guard during execution this is true.


==Respecialization==
==Respecialization==
Confirmed users
24

edits