Confirmed users
156
edits
mNo edit summary |
m (→Implementation) |
||
| Line 38: | Line 38: | ||
Type sets for stack slots are queried based on a script, program counter, and stack/local/argument index. Type information for object properties is stored in each JSObject, and eventually be merged with js::Shape and JSObject::prototype. For both, the type information forms the constraint graph necessary for propagating new additions to type sets, causing recompilation if necessary. | Type sets for stack slots are queried based on a script, program counter, and stack/local/argument index. Type information for object properties is stored in each JSObject, and eventually be merged with js::Shape and JSObject::prototype. For both, the type information forms the constraint graph necessary for propagating new additions to type sets, causing recompilation if necessary. | ||
This propagation is critical for correctness in code that depends on type inference information, and thus the interpreter and VM helpers must carefully place type checks where necessary. | |||
The register allocator uses liveness information computed in a backwards pass. During loop compilation the compiler decides which values should be kept in registers across the backwards edge. That means the full set of loop-carried registers is not unknown until the bottom of the loop. | The register allocator uses liveness information computed in a backwards pass. During loop compilation the compiler decides which values should be kept in registers across the backwards edge. That means the full set of loop-carried registers is not unknown until the bottom of the loop. | ||