1. 18 Sep, 2009 1 commit
  2. 25 Nov, 2009 1 commit
  3. 26 Nov, 2009 1 commit
  4. 25 Nov, 2009 7 commits
  5. 24 Nov, 2009 1 commit
  6. 25 Nov, 2009 3 commits
    • Simon Marlow's avatar
      threadStackOverflow: check whether stack squeezing released some stack (#3677) · d2c874dc
      Simon Marlow authored
      In a stack overflow situation, stack squeezing may reduce the stack
      size, but we don't know whether it has been reduced enough for the
      stack check to succeed if we try again.  Fortunately stack squeezing
      is idempotent, so all we need to do is record whether *any* squeezing
      happened.  If we are at the stack's absolute -K limit, and stack
      squeezing happened, then we try running the thread again.
      
      We also want to avoid enlarging the stack if squeezing has already
      released some of it.  However, we don't want to get into a
      pathalogical situation where a thread has a nearly full stack (near
      its current limit, but not near the absolute -K limit), keeps
      allocating a little bit, squeezing removes a little bit, and then it
      runs again.  So to avoid this, if we squeezed *and* there is still
      less than BLOCK_SIZE_W words free, then we enlarge the stack anyway.
      d2c874dc
    • Simon Marlow's avatar
      add a comment to TSO_MARKED · 69ba3e6b
      Simon Marlow authored
      69ba3e6b
    • rl@cse.unsw.edu.au's avatar
  7. 24 Nov, 2009 3 commits
  8. 23 Nov, 2009 1 commit
  9. 20 Nov, 2009 5 commits
  10. 19 Nov, 2009 4 commits
  11. 12 Nov, 2009 1 commit
  12. 19 Nov, 2009 5 commits
    • simonpj@microsoft.com's avatar
      Remove the (very) old strictness analyser · 2662dbc5
      simonpj@microsoft.com authored
      I finally got tired of the #ifdef OLD_STRICTNESS stuff.  I had been
      keeping it around in the hope of doing old-to-new comparisions, but
      have failed to do so for many years, so I don't think it's going to
      happen.  This patch deletes the clutter.
      2662dbc5
    • simonpj@microsoft.com's avatar
      Make INLINE warning more precise · c8ef1c4a
      simonpj@microsoft.com authored
      c8ef1c4a
    • simonpj@microsoft.com's avatar
      Implement -fexpose-all-unfoldings, and fix a non-termination bug · 6a944ae7
      simonpj@microsoft.com authored
      The -fexpose-all-unfoldings flag arranges to put unfoldings for *everything*
      in the interface file.  Of course,  this makes the file a lot bigger, but
      it also makes it complete, and that's great for supercompilation; or indeed
      any whole-program work.
      
      Consequences:
        * Interface files need to record loop-breaker-hood.  (Previously,
          loop breakers were never exposed, so that info wasn't necessary.)
          Hence a small interface file format change. 
      
        * When inlining, must check loop-breaker-hood. (Previously, loop
          breakers didn't have an unfolding at all, so no need to check.)
      
        * Ditto in exprIsConApp_maybe.  Roman actually tripped this bug, 
          because a DFun, which had an unfolding, was also a loop breaker
      
        * TidyPgm.tidyIdInfo must be careful to preserve loop-breaker-hood
      
      So Id.idUnfolding checks for loop-breaker-hood and returns NoUnfolding
      if so. When you want the unfolding regardless of loop-breaker-hood, 
      use Id.realIdUnfolding.
      
      I have not documented the flag yet, because it's experimental.  Nor
      have I tested it thoroughly.  But with the flag off (the normal case)
      everything should work.
      6a944ae7
    • simonpj@microsoft.com's avatar
      Re-implement the binder-swap stuff in OccurAnal · c93e8323
      simonpj@microsoft.com authored
      This is a pretty big patch, but it has a very local effect.
      It affects only the binder-swap mechanism in OccurAnal, which
      was not working well becuase it's more subtle than I'd realised
      (See Note [getProxies is subtle]).  I think this does a much
      better job.
      c93e8323
    • simonpj@microsoft.com's avatar
      Try harder not to make DFuns into loop breakers · 522c1e96
      simonpj@microsoft.com authored
      See Note [DFuns should not be loop breakers]
      522c1e96
  13. 17 Nov, 2009 1 commit
  14. 19 Nov, 2009 6 commits
    • Ian Lynagh's avatar
    • Ian Lynagh's avatar
      852373b7
    • simonpj@microsoft.com's avatar
      Refactor case-merging and identical-alternative optimisations · 367e603d
      simonpj@microsoft.com authored
      These two optimisations were originally done by SimplUtils.mkCase
      *after* all the pieces have been simplified.  Some while ago I
      moved them *before*, so they were done by SimplUtils.prepareAlts.
      It think the reason was that I couldn't rely on the dead-binder 
      information on OutIds, and that info is useful in these optimisations.
      
      However, 
       (a) Other changes (notably moving case-binder-swap to OccurAnal)
           have meant that dead-binder information is accurate in 
           OutIds
      
       (b) When there is a cascade of case-merges, they happen in 
           one sweep if you do it after, but in many sweeps if you
           do it before.  Reason: doing it after means you are looking
           at nice simplified Core.
      367e603d
    • simonpj@microsoft.com's avatar
      Fix a nasty infelicity in the size computation of CoreUnfold · d21c80ea
      simonpj@microsoft.com authored
      The size computation was treating gigantic case expressions as
      practically free, which they really aren't.  It was exacerbated by
      recent decisions to charge 0 for naked variables and constructors, so
      the RHS of the case might look free too.  A good example was 
      Foreign.C.Error.errnoToIOError, which hsa lots of join points
      that were getting inlined way to vigorously, so we had:
      
        *** Simplifier Phase 2 [main]:
            Result size = 2983
        *** Core Linted result of Simplifier mode 2 [main], iteration 1 out of 4:
            Result size = 640327
        *** Core Linted result of Simplifier mode 2 [main], iteration 2 out of 4:
            Result size = 1659
      
      Notice that gigantic intermediate!
      
      This patch adds a small charge for each *alternative*.  Of course,
      that'll also mean that there's a bit less inling of things involving
      case expressions.
      d21c80ea
    • simonpj@microsoft.com's avatar
      Comments and white space only · 8a85f89b
      simonpj@microsoft.com authored
      8a85f89b
    • rl@cse.unsw.edu.au's avatar
      Fix splitAppTys · f240e9ab
      rl@cse.unsw.edu.au authored
      f240e9ab