Changes between Version 68 and Version 69 of Commentary/Compiler/NewCodeGen


Ignore:
Timestamp:
Apr 27, 2011 5:18:06 PM (3 years ago)
Author:
ezyang
Comment:

add another state of play

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/NewCodeGen

    v68 v69  
    8484 
    8585 
     86== Status report April 2011 == 
     87 
     88Term’s starting up for me again, and as a result, I will have less time to throw at the new code generator. As such, here is the state of play, as of April 2011. 
     89 
     90We currently have a code generator that is correct, but slow and stupid. The primary optimization problem that I was tackling at the end of Spring Break was the following: newly compiled programs used a lot more stack space than their old equivalents, due to poor usage of call areas for register reloading and an over-conservative stack layout algorithm. Our new plan is to overhaul the spiller and the stack layout engine in the following manner: 
     91 
     921. We teach the register spiller about another location: a value may be in a register, on the stack in a register slot, OR (and this is the new bit) inside a call area. If it’s in a call area, reload from that instead of of its slot location. This might require borrowing some code from the code motion improvements in my private branch (http://github.com/ezyang/ghc). 
     93 
     942. We change the stack layout code to perform interference on a per-word, rather than per-area level. Because this may cause a very huge interference graph, we bound the number of conflicts we remember; instead of recording every slot a slot may conflict with, we remember some number, and if there are more, we just say it conflicts with everything. (There is some potential for statistics and tuning parameters here.) 
    8695 
    8796