Confirmed users
156
edits
IonMonkey/LIR: Difference between revisions
Jump to navigation
Jump to search
m
→LIR
m (→Allocations) |
m (→LIR) |
||
| Line 23: | Line 23: | ||
To make accessing and allocating nodes as fast as possible, <tt>LInstructionHelper<D, I, T></tt> is a template class where <tt>D</tt> is the number of definitions, <tt>I</tt> is the number of input operands, and <tt>T</tt> is the number of temporaries. Instructions should inherit from this class if possible. | To make accessing and allocating nodes as fast as possible, <tt>LInstructionHelper<D, I, T></tt> is a template class where <tt>D</tt> is the number of definitions, <tt>I</tt> is the number of input operands, and <tt>T</tt> is the number of temporaries. Instructions should inherit from this class if possible. | ||
== Representing Values == | |||
One tricky aspect of LIR is that we would like to abstract it as much as possible, however, the representation of a <tt>js::Value</tt> is architecture-specific. For instructions that define values, or take in values as operands, we use a <tt>BOX_PIECES</tt> macro which is <tt>1</tt> for punboxing and <tt>2</tt> for nunboxing. | |||
We treat value inputs and definitions as untyped, and therefore, they are always non-constant. | |||
== Allocations == | == Allocations == | ||
| Line 65: | Line 71: | ||
This is possible with one data structure, because of the ''policies'' attached to operands and definitions. While the structure of an <tt>LAddI</tt> always looks the same, different architectures may specify different register allocation schemes. This is explained below. | This is possible with one data structure, because of the ''policies'' attached to operands and definitions. While the structure of an <tt>LAddI</tt> always looks the same, different architectures may specify different register allocation schemes. This is explained below. | ||
= Virtual Registers and Policies = | = Virtual Registers and Policies = | ||