Confirmed users
156
edits
IonMonkey/LIR: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
m (→LIR) |
mNo edit summary |
||
| Line 109: | Line 109: | ||
If the <tt>LDefinition</tt> does not have a <tt>PRESET</tt> or <tt>REDEFINED</tt> policy, its <tt>LAllocation</tt> is filled in during register allocation. | If the <tt>LDefinition</tt> does not have a <tt>PRESET</tt> or <tt>REDEFINED</tt> policy, its <tt>LAllocation</tt> is filled in during register allocation. | ||
= Lowering = | |||
The process of converting MIR to LIR is Lowering. Lowering is implemented by LIRGenerator, which defines functions to lower each MIR instruction. To maximize the amount of code we can share between all platforms, LIRGenerator has a somewhat roundabout class hierarchy: | |||
[[Image:Ionmonkey-lirgenerator.png]] | |||
The base class, <tt>LIRGeneratorShared</tt>, contains basic functionality that is used by derived classes. <tt>LIRGenerator$(ARCH)</tt> implements architecture-specific lowering. Finally, <tt>LIRGenerator</tt> derives from exactly one of the architecture-specific base classes, depending on the platform. | |||
We try to move as much logic into the derived-most <tt>LIRGenerator</tt> as possible. For example, math operations almost always have a conceptual three-register form (two inputs and an output), but on x86 generate two-register form code. Rather than exposing these differences in the structure of LIR, we expose them in allocation policies, and thus math-oriented policies are simply exposed on a per-architecture basis. | |||