1. 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
  2. 24 Nov, 2009 3 commits
  3. 23 Nov, 2009 1 commit
  4. 20 Nov, 2009 5 commits
  5. 19 Nov, 2009 4 commits
  6. 12 Nov, 2009 1 commit
  7. 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
  8. 17 Nov, 2009 1 commit
  9. 19 Nov, 2009 7 commits
  10. 18 Nov, 2009 5 commits
  11. 17 Nov, 2009 3 commits
  12. 14 Nov, 2009 2 commits