Confirmed users
156
edits
IonMonkey/MIR: Difference between revisions
m
no edit summary
No edit summary |
mNo edit summary |
||
| Line 25: | Line 25: | ||
*List of successors. | *List of successors. | ||
*Dominator information. | *Dominator information. | ||
*An entry " | *An entry "resume point" (described later). | ||
During MIR building, an MBasicBlock also models the interpreter stack, mapping local variables and stack slots to SSA names. | During MIR building, an MBasicBlock also models the interpreter stack, mapping local variables and stack slots to SSA names. | ||
| Line 37: | Line 37: | ||
[[File:ionmonkey_mir.png]] | [[File:ionmonkey_mir.png]] | ||
IR nodes are separated into definitions (which provide an SSA name) and | IR nodes are separated into definitions (which provide an SSA name) and resume points, which are purely informative and described later. | ||
*'''MDefinition''': A node which provides an SSA name. | *'''MDefinition''': A node which provides an SSA name. | ||
| Line 49: | Line 49: | ||
*A list of IR nodes which use this definition. Def-use chains are created automatically when adding input operands. | *A list of IR nodes which use this definition. Def-use chains are created automatically when adding input operands. | ||
*An instruction ID, assigned incrementally in reverse postorder. | *An instruction ID, assigned incrementally in reverse postorder. | ||
*A | *A resume point, described later. | ||
=Building MIR= | =Building MIR= | ||
| Line 85: | Line 85: | ||
'''Note 2:''' Copy or constant propagation is NOT ALLOWED during MIR generation. This would break phi replacement, for reasons described in <tt>MIRGraph.cpp</tt>. | '''Note 2:''' Copy or constant propagation is NOT ALLOWED during MIR generation. This would break phi replacement, for reasons described in <tt>MIRGraph.cpp</tt>. | ||
== | ==Resume Points== | ||
Resume points are special IR nodes whose function is at the heart of IonMonkey. When deoptimization occurs, it is necessary that we resume the JavaScript program in another execution mode. This means translating the highly optimized Ion state back into the interpreter. Resume points capture the information necessary to make this happen. | |||
For a given point in the program, | For a given point in the program, MResumePoints save the SSA names corresponding to each local variable and slot in the expression stack. MResumePoints can be taken anywhere, but minimally, '''MUST''' be taken at these critical points: | ||
*At the start of basic blocks. Execution cannot resume before an already-taken control keyword. | *At the start of basic blocks. Execution cannot resume before an already-taken control keyword. | ||
*After non-idempotent instructions. For example, calls, or modifications to the heap, are both observable. | *After non-idempotent instructions. For example, calls, or modifications to the heap, are both observable. | ||
This is because when deoptimization occurs, we resume the JavaScript program at the most recently-taken | This is because when deoptimization occurs, we resume the JavaScript program at the most recently-taken resume point. If this re-executes idempotent code, that is okay. If it re-executes an observable operation, it could lead to a correctness bug. | ||
MResumePoints participate in def-use chains, but are not actual definitions or instructions. Rather, they are attached to instructions or basic blocks. When attached to instructions, they are meant to be captured ''after'' the instruction. '''This means an MInstruction's effects must be atomic.''' There is no facility to resume in the "middle" of an instruction. | |||
==Graph Fixups== | ==Graph Fixups== | ||
| Line 127: | Line 127: | ||
*Propagation specialization. | *Propagation specialization. | ||
For example, an "add" operation that has been specialized to take 32-bit integers, may actually have a floating-point input. In this case, the add will respecialize. When an instruction is respecialized, any uses of the instruction are re-analyzed. (Note that nodes can never respecialize from idempotent to non-idempotent, unless they have a | For example, an "add" operation that has been specialized to take 32-bit integers, may actually have a floating-point input. In this case, the add will respecialize. When an instruction is respecialized, any uses of the instruction are re-analyzed. (Note that nodes can never respecialize from idempotent to non-idempotent, unless they have a resume point.) | ||
Next, an "add" operation may notice that one of its inputs' types is not known: for example, the result of call. In this case, the add's specialization is propagated to the input. Every untyped input has a set containing the types it should be specialized as. If an untyped input has only one specialization request, that type is considered its ''observed'' or effective type. | Next, an "add" operation may notice that one of its inputs' types is not known: for example, the result of call. In this case, the add's specialization is propagated to the input. Every untyped input has a set containing the types it should be specialized as. If an untyped input has only one specialization request, that type is considered its ''observed'' or effective type. | ||