Browse files

New regalloc design.

svn path=/trunk/mono/; revision=30937
  • Loading branch information...
1 parent fe46d4c commit ba3f5b85caf586ea033ee7362ab25bb97ada844f @illupus illupus committed Jul 9, 2004
Showing with 68 additions and 0 deletions.
  1. +68 −0 docs/new-regalloc
@@ -0,0 +1,68 @@
+We need to switch to a new register allocator.
+The current one is split in a global and a local register allocator.
+The global one can assign only callee-saves registers and happens
+on the tree-based internal representation: it assigns local variables
+to hardware registers.
+The local one happens on the linear representation on a per basic
+block basis and assigns hard registers to virtual registers (which
+hold temporary values during expression executions) and it deals also
+with the platform-specific issues (fixed registers, call conventions).
+Moving to a different register will help solve some of the performance
+issues introduced by the above split, make the register more easily
+portable and solve some of the issues generated by dealing with trees.
+The general design ideas are below.
+The new allocator should have a global view of all the method, so it can be
+able to assign variables also to some of the volatile registers if possible,
+even across basic blocks (this would improve performance).
+The allocator would be driven by per-arch declarative data, so porting
+should be easier: an architecture needs to specify register classes,
+call convention and instructions requirements (similar to the gcc code).
+The allocator should operate on the linear representation, this way it's
+easier and faster to track usages more correctly. We need to assign virtual
+registers on a per-method basis instead of per basic block. We can assign
+virtual registers to variables, too. Note that since we fix the stack offset
+of local vars only after this step (which happens after the burg rules are run),
+some of the burg rules that try to optimize the code won't apply anymore:
+the peephole code may need to be enhanced to do the optimizations instead.
+We need to handle floating point registers in the global allocator, too.
+The new allocator also needs to keep track precisely of which registers
+contain references or managed pointers to allow us to move to a precise GC.
+It may be worth to use a single increasing set of integers for the virtual
+registers, with the class of the register stored separately (unless the
+current local allocator which keeps interger and fp registers separate).
+Since this is a large task, we need to do it in steps as much as possible.
+The first is to run the register allocator _after_ the burg rules: this
+requires a rewrite of the liveness code, too, to use linear indexes instead
+of basic-block/tree number combinations. This can be done by:
+*) allocating virtual regs to all the locals that can be register allocated
+*) running the burg rules (some may require adjustments): the local virtual
+registers are assigned starting from global-virt-regs+1, instead of the current
+hardware-regs+1, so we can tell apart global and local virt regs.
+*) running the liveness/whatever code is needed to allocate the global registers
+*) allocate the rest of the local variables to stack slots
+*) continue with the current local allocator
+This work could take 2-3 weeks.
+The next step is to define the kind of declarative data an architecture needs
+and assigning virtual regs to all the registers and making the allocator
+assign from the volatile registers, too.
+Note that some of the code that is currently emitted in the arch-specific
+code, will need to be emitted as instructions that the reg allocator
+can inspect: think of a method that returns the first argument which is
+received in a register: the current code copies it to either a local slot or
+to a global reg in the prolog an copies it back to the return register
+int he basic block, but since neither the regallocator nor the peephole code
+knows about the prolog code, the first store cannot be optimized away.
+The gcc code has some example of how to specify register classes in a
+declarative way.

0 comments on commit ba3f5b8

Please sign in to comment.