Confirmed users
156
edits
TypeInference: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
mNo edit summary |
mNo edit summary |
||
| Line 33: | Line 33: | ||
= Technology = | = Technology = | ||
== Implementation == | |||
Type inference has a somewhat invasive integration into the engine as a whole, but is designed to integrate with JaegerMonkey with as few changes to the compiler as possible. It uses the existing FrameState API to act as an oracle for JaegerMonkey's register allocator and type information queries. | Type inference has a somewhat invasive integration into the engine as a whole, but is designed to integrate with JaegerMonkey with as few changes to the compiler as possible. It uses the existing FrameState API to act as an oracle for JaegerMonkey's register allocator and type information queries. | ||
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. | |||
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. | ||