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


Ignore:
Timestamp:
Sep 19, 2007 4:02:07 PM (7 years ago)
Author:
guest
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/Backends/NCG/RegisterAllocator

    v23 v24  
    118118 
    119119 * '''Revisit trivColorable / aliasing of register sets'''[[BR]] 
    120    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. 
     120   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. 
    121121 
    122   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. 
     122  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. 
    123123