1. 01 Jul, 2016 1 commit
    • niteria's avatar
      Remove uniqSetToList · cbfeff4b
      niteria authored
      This documents nondeterminism in code generation and removes
      the nondeterministic ufmToList function. In the future someone
      will have to use nonDetEltsUFM (with proper explanation)
      or pprUFM.
      cbfeff4b
  2. 06 Jan, 2015 1 commit
  3. 26 Feb, 2012 2 commits
  4. 04 Nov, 2011 1 commit
  5. 18 May, 2009 1 commit
    • Ben.Lippmeier@anu.edu.au's avatar
      Split Reg into vreg/hreg and add register pairs · f9288086
      Ben.Lippmeier@anu.edu.au authored
       * The old Reg type is now split into VirtualReg and RealReg.
       * For the graph coloring allocator, the type of the register graph
         is now (Graph VirtualReg RegClass RealReg), which shows that it colors
         in nodes representing virtual regs with colors representing real regs.
         (as was intended)  
       * RealReg contains two contructors, RealRegSingle and RealRegPair,
         where RealRegPair is used to represent a SPARC double reg 
         constructed from two single precision FP regs. 
       * On SPARC we can now allocate double regs into an arbitrary register
         pair, instead of reserving some reg ranges to only hold float/double values. 
      f9288086
  6. 07 Feb, 2008 2 commits
  7. 21 Sep, 2007 1 commit
  8. 17 Sep, 2007 2 commits
    • Ben.Lippmeier@anu.edu.au's avatar
      Tune coalescing in non-iterative register allocator · fff4dee0
      Ben.Lippmeier@anu.edu.au authored
      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.
      fff4dee0
    • Ben.Lippmeier@anu.edu.au's avatar
      Bugfix to iterative coalescer · 6a347ffc
      Ben.Lippmeier@anu.edu.au authored
      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.
      6a347ffc
  9. 14 Sep, 2007 1 commit
    • Ben.Lippmeier@anu.edu.au's avatar
      Change spill cost function back to inverse length of live range. · 26248bad
      Ben.Lippmeier@anu.edu.au authored
      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.
      26248bad
  10. 13 Sep, 2007 1 commit
  11. 12 Sep, 2007 2 commits
  12. 11 Sep, 2007 1 commit
  13. 10 Sep, 2007 1 commit
  14. 07 Sep, 2007 1 commit
    • Ben.Lippmeier@anu.edu.au's avatar
      Add iterative coalescing to graph coloring allocator · 12d0b388
      Ben.Lippmeier@anu.edu.au authored
      Iterative coalescing interleaves conservative coalesing with the regular
      simplify/scan passes. This increases the chance that nodes will be coalesced
      as they will have a lower degree than at the beginning of simplify. The end
      result is that more register to register moves will be eliminated in the
      output code, though the iterative nature of the algorithm makes it slower
      compared to non-iterative coloring.
      
      Use -fregs-iterative  for graph coloring allocation with iterative coalescing
          -fregs-graph      for non-iterative coalescing.
      
      The plan is for iterative coalescing to be enabled with -O2 and have a 
      quicker, non-iterative algorithm otherwise. The time/benefit tradeoff
      between iterative and not is still being tuned - optimal graph coloring
      is NP-hard, afterall..
      12d0b388
  15. 06 Sep, 2007 2 commits
  16. 05 Sep, 2007 2 commits
    • Ben.Lippmeier@anu.edu.au's avatar
      Improve GraphColor.colorScan · 1dd44153
      Ben.Lippmeier@anu.edu.au authored
      Testing whether a node in the conflict graph is trivially 
      colorable (triv) is still a somewhat expensive operation.
      
      When we find a triv node during scanning, even though we remove
      it and its edges from the graph, this is unlikely to to make the
      nodes we've just scanned become triv - so there's not much point
      re-scanning them right away.
      
      Scanning now takes place in passes. We scan the whole graph for
      triv nodes and remove all the ones found in a batch before rescanning
      old nodes.
      
      Register allocation for SHA1.lhs now takes (just) 40% of total
      compile time with -O2 -fregs-graph on x86
      1dd44153
    • Ben.Lippmeier@anu.edu.au's avatar
      warning police · 272f0ba8
      Ben.Lippmeier@anu.edu.au authored
      272f0ba8
  17. 03 Sep, 2007 1 commit
    • Ben.Lippmeier@anu.edu.au's avatar
      Do conservative coalescing in register allocator · a7f409e8
      Ben.Lippmeier@anu.edu.au authored
      Avoid coalescing nodes in the register conflict graph if the
      new node will not be trivially colorable. Also remove the
      front end aggressive coalescing pass.
        
      For typical Haskell code the graph coloring allocator now does
      about as well as the linear allocator.
        
      For code with a large amount of register pressure it does much
      better, but takes longer.
        
      For SHA1.lhs from darcs on x86
         
                spills    reloads    reg-reg-moves
                inserted   inserted  left in code   compile-time
        linear    1068      1311        229            7.69(s)
        graph      387       902        340           16.12(s)
      a7f409e8
  18. 04 Sep, 2007 1 commit
  19. 03 Sep, 2007 2 commits
  20. 28 Aug, 2007 1 commit
  21. 01 Sep, 2007 1 commit
  22. 14 Aug, 2007 1 commit
    • Ben.Lippmeier@anu.edu.au's avatar
      Add graph coloring register allocator. · 0f7d268d
      Ben.Lippmeier@anu.edu.au authored
      Refactored linear allocator into separate liveness annotation and allocation stages.
      Added graph coloring allocator, use -fregs-graph to enable.
        New dump flags are
          -ddump-asm-native          -- output of cmm -> native transform.
          -ddump-asm-liveness        -- code annotated with register liveness info
          -ddump-asm-coalesce        -- output of register move coalescing
                                          (this is a separate pass when using the coloring allocator)
                                          (this could change in the future)
          -ddump-asm-regalloc        -- code after register allocation
          -ddump-asm-regalloc-stages -- blocks after each build/spill stage of coloring allocator
          -ddump-asm-conflicts       -- a global register liveness graph in graphviz format 
              
      The new register allocator will allocate some registers, but it's not
      quite ready for prime-time yet. The spill code generator needs some work...
      0f7d268d