Changes between Version 23 and Version 24 of Commentary/Compiler/Backends/NCG/RegisterAllocator

Timestamp:

09/19/07 09:02:07 (6 years ago)

Author:

guest

Comment:

--

Commentary/Compiler/Backends/NCG/RegisterAllocator

@@ -118 +118 @@
 
  * '''Revisit trivColorable / aliasing of register sets'''[[BR]]
-   For the architectures currently supported, x86, x86_64 and ppc, the native code generator currently emits code using only two register classes {{{RcInteger}}} and {{{RcDouble}}}. As these classes are disjoint (ie, none of the regs from one class alias with with regs from another), checking whether a certain node is trivially colorable reduces to counting up the number of neighbors of the same class.
+   For the architectures currently supported, x86, x86_64 and ppc, the native code generator currently emits code using only two register classes {{{RcInteger}}} and {{{RcDouble}}}. As these classes are disjoint (ie, none of the regs from one class alias with with regs from another), checking whether a node of a certain class is trivially colorable reduces to counting up the number of neighbours of that class.
 
-  If the native code starts to use aliasing register classes eg: both 32bit {{{RcFloat}}}s and 64bit {{{RcDouble}}}s on sparc; combinations of 8, 16, and 32 bit integers on x86 / x86_x6; usage of sse / altivec regs in different modes, then this could be supported via the method described in [Smith et al]. The allocator was designed with this in mind - ie, by passing a function to test if a node is trivially colorable as a parameter to the coloring function - and there is already a description of the register set for X86 in ... , but the native code generator doesn't emit code to test it against.
+  If the NCG starts to use aliasing register classes eg: both 32bit {{{RcFloat}}}s and 64bit {{{RcDouble}}}s on sparc; combinations of 8, 16, and 32 bit integers on x86 / x86_x6 or usage of sse / altivec regs in different modes, then this can be supported via the method described in [Smith et al]. The allocator was designed with this in mind - ie, by passing a function to test if a node is trivially colorable as a parameter to the coloring function - and there is already a description of the register set for X86 in ... , but the native code generator doesn't currently emit code to test it against.