1. 09 Aug, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Better scoring for loop breakers; fixes simplifier loop in nofib/minimax · fea8c9e4
      simonpj@microsoft.com authored
      See Note [Inline candidates] in OccurAnal.  We were getting a recursive
      loop exposed, which led to infinite inlinings.  Doesn't bite much, but
      was obviously wrong.
      
      I've change the "scoring order" for loop breakers, which could possibly
      have a performance impact on other programs.  A full nofib run exposed
      a 0.00% change in allocation in any nofib program, so I don't think it's
      likely, but keep an eye out.
      
      fea8c9e4
  2. 03 Aug, 2007 1 commit
  3. 09 Aug, 2007 1 commit
  4. 14 Jul, 2007 1 commit
    • Clemens Fruhwirth's avatar
      joinToTargets to emit fixup code even when movement graph contains cycles · 64f0661e
      Clemens Fruhwirth authored
      First, cycles can only start of with registers and their destination
      must involve a register location. This is because memory locations are
      allocated exclusively for a virtual register and hence can never cause
      a conflict in the assignment, hence need no fixup code. Therefore, we
      only have to deal with InReg -> InReg, or InReg -> InReg/InMem
      movements.  
      
      The strategy is to take the first cycle element, which is guaranteed
      to start with a register, spill it to a fresh memory location, compute
      the fixup for the rest, and restore from the spill slot to its
      destinations. The "rest" will degenerate into an acyclic scc, so we do
      not need take care of the empty list case in CyclicScc. 
       ***END OF DESCRIPTION***
      
      Place the long patch description above the ***END OF DESCRIPTION*** marker.
      The first line of this file will be the patch name.
      
      
      This patch contains the following changes:
      
      M ./compiler/nativeGen/RegisterAlloc.hs -6 +27
      64f0661e
  5. 05 Aug, 2007 2 commits
    • simonpj@microsoft.com's avatar
      Make SpecConstr specialise for constant arguments again · 57a4597d
      simonpj@microsoft.com authored
      Consider
        lvl = Just True
      
        foo :: Maybe Bool -> Int -> Int
        foo (Just True) i = i
        foo _           i = foo lvl i
      
      SpecConstr should specialise foo, but it wasn't doing so (spotted
      by Roman).
      
      Reason: lvl's unfolding wasn't in the cloned version of lvl.
      Solution: extend the value environment to record top-level bindings too
      
      At the same time I made it work if 'lvl' is a lambda, in which case it
      is again worth specialisg.  This meant renaming ConEnv to ValueEnv,
      and adding a case for 'LambdaVal'.
      
      (To make specialisation on lambdas work properly, we have to do lambda
      lifting as well, but this gets part of the way, and fixes a bug too.)
      
      57a4597d
    • simonpj@microsoft.com's avatar
  6. 04 Aug, 2007 4 commits
  7. 09 Aug, 2007 1 commit
  8. 08 Aug, 2007 2 commits
  9. 07 Aug, 2007 1 commit
  10. 06 Aug, 2007 1 commit
  11. 07 Aug, 2007 3 commits
  12. 06 Aug, 2007 1 commit
  13. 05 Aug, 2007 4 commits
  14. 04 Aug, 2007 12 commits
  15. 03 Aug, 2007 5 commits