Tue Sep 18 03:22:56 PDT 2007 [EMAIL PROTECTED]
* Merge of register allocator patches.
This is a conflict avoiding merge of several patches which finish off
the new register allocator. After this patch all tests should go through
with both -fregs-graph and -fregs-iterative.
Mon Sep 17 14:26:14 BST 2007 [EMAIL PROTECTED]
* Tune coalescing in non-iterative register allocator
If iterative coalescing isn't turned on, then do a single aggressive
coalescing pass for the first build/color cycle and then back off to
conservative coalescing for subseqent passes.
Aggressive coalescing is a cheap way to eliminate lots of the reg-reg
moves, but it can make the graph less colorable - if we turn it on
for every pass then allocation for code with a large amount of register
pressure (ie SHA1) doesn't converge in a sensible number of cycles.
Mon Sep 17 13:42:41 BST 2007 [EMAIL PROTECTED]
* Bugfix to iterative coalescer
Coalescences must be applied to the unsimplified graph in the same order
they were found by the iterative coalescing algorithm - otherwise
the vreg rewrite mapping will be wrong and badness will ensue.
Mon Sep 17 12:30:24 BST 2007 [EMAIL PROTECTED]
* Add -dasm-lint
When -dasm-lint is turned on the register conflict graph is checked for
internal consistency after each build/color pass. Make sure that all
edges point to valid nodes, that nodes are colored differently to their
neighbours, and if the graph is supposed to be colored, that all nodes
actually have a color.
Fri Sep 14 17:42:34 BST 2007 [EMAIL PROTECTED]
* Count CmmTops processed so far in the native code generator
To help with debugging / nicer -ddump-asm-regalloc-stages
Fri Sep 14 17:14:08 BST 2007 [EMAIL PROTECTED]
* Change spill cost function back to inverse length of live range.
On further testing it turns out that using Chaitin's spill cost formula
of counting the number of uses of a var and then dividing by the degree
of the node isn't actually a win. Perhaps because this isn't counting
the number of actual spills inserted in the output code.
This would be worth revisiting if other work manages to increase the
register pressure in the native code.
Fri Sep 14 10:39:07 BST 2007 [EMAIL PROTECTED]
* Better cleaning of spills in spill cleaner
Track what slots each basic block reloads from. When cleaning spill
instructions we can use this information to decide whether the slot
spilled to will ever be read from on this path.
Thu Sep 13 16:54:07 BST 2007 [EMAIL PROTECTED]
* Better calculation of spill costs / selection of spill candidates.
Use Chaitin's formula for calculation of spill costs.
Cost to spill some vreg = (num writes + num reads) / degree of node
With 2 extra provisos:
1) Don't spill vregs that live for only 1 instruction.
2) Always prefer to spill vregs that live for a number of instructions
more than 10 times the number of vregs in that class.
Proviso 2 is there to help deal with basic blocks containing very long
live ranges - SHA1 has live ranges > 1700 instructions. We don't ever
try to keep these long lived ranges in regs at the expense of others.
Because stack slots are allocated from a global pool, and there is no
slot coalescing yet, without this condition the allocation of SHA1 dosn't
converge fast enough and eventually runs out of stack slots.
Prior to this patch we were just choosing to spill the range with the
longest lifetime, so we didn't bump into this particular problem.
M ./compiler/main/DynFlags.hs +2
M ./compiler/nativeGen/AsmCodeGen.lhs -6 +13
M ./compiler/nativeGen/GraphColor.hs -8 +17
M ./compiler/nativeGen/GraphOps.hs -23 +69
M ./compiler/nativeGen/MachRegs.lhs +1
M ./compiler/nativeGen/RegAllocColor.hs -83 +42
M ./compiler/nativeGen/RegAllocStats.hs -10 +23
M ./compiler/nativeGen/RegLiveness.hs -43
M ./compiler/nativeGen/RegSpillClean.hs -50 +122
A ./compiler/nativeGen/RegSpillCost.hs
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
