1. 06 Dec, 2006 2 commits
  2. 04 Dec, 2006 2 commits
  3. 05 Dec, 2006 4 commits
  4. 04 Dec, 2006 1 commit
  5. 03 Dec, 2006 2 commits
  6. 01 Dec, 2006 4 commits
    • Simon Marlow's avatar
      Add support for the IO manager thread on Windows · 80a766fd
      Simon Marlow authored
      Fixes #637.
      The implications of this change are:
        - threadDelay on Windows no longer creates a new OS thread each time,
          instead it communicates with the IO manager thread in the same way as
          on Unix.
        - deadlock detection now works the same way on Windows as on Unix; that
          is the timer interrupt wakes up the IO manager thread, which causes
          the scheduler to check for deadlock.
        - Console events now get sent to the IO manager thread, in the same way as
          signals do on Unix.  This means that console events should behave more
          reliably with -threaded on Windows.
      
      All this applies only with -threaded.  Without -threaded, the old
      ConsoleEvent code is still used.
      
      After some testing, this could be pushed to the 6.6 branch.
      80a766fd
    • Simon Marlow's avatar
      Remove the Windows Async IO Manager completely in THREADED_RTS mode · de6c8e52
      Simon Marlow authored
      It isn't used here anyway, just making sure the code doesn't get compiled in.
      de6c8e52
    • wolfgang.thaller@gmx.net's avatar
      Decouple -O from -fvia-C · 8971f720
      wolfgang.thaller@gmx.net authored
      Nowadays, there are situations where -fvia-C is definitely unwanted, such
      as when -fPIC is used on some platforms, so we do not want implicit -fvia-C
      any more.
      8971f720
    • simonpj@microsoft.com's avatar
      q · ea2d0a53
      simonpj@microsoft.com authored
      ea2d0a53
  7. 21 Nov, 2006 1 commit
  8. 17 Nov, 2006 1 commit
  9. 09 Oct, 2006 1 commit
  10. 06 Oct, 2006 1 commit
  11. 29 Nov, 2006 9 commits
    • simonpj@microsoft.com's avatar
      Remove trace · b20a90d8
      simonpj@microsoft.com authored
      b20a90d8
    • simonpj@microsoft.com's avatar
      Remove bogus comment · 4706dd57
      simonpj@microsoft.com authored
      4706dd57
    • simonpj@microsoft.com's avatar
      Teach SpecConstr how to handle mutually-recursive functions · 9fad5a80
      simonpj@microsoft.com authored
      Roman found cases where it was important to do SpecConstr for
      mutually-recursive definitions.  Here is one:
      	foo :: Maybe Int -> Int
      	foo Nothing  = 0
      	foo (Just 0) = foo Nothing
      	foo (Just n) = foo (Just (n-1))
      By the time SpecConstr gets to it, it looks like this:
      	lvl = foo Nothing
      	foo Nothing  = 0
      	foo (Just 0) = lvl
      	foo (Just n) = foo (Just (n-1))
      
      Happily, it turns out to be rather straightforward to generalise the
      transformation to mutually-recursive functions.  Look, ma, only 4 
      extra lines of ocde!
      
      
      9fad5a80
    • simonpj@microsoft.com's avatar
      Improve the loop-breaking heuristics · 1dca1587
      simonpj@microsoft.com authored
      The loop-breaking heuristics were making it a high priority to
      avoid choosing a variable as a loop breaker if its *type* was a 
      data type.  The reason is that it's very good to be able to "see"
      constructor applications.
      
      But it's only good if the constructor application is *visible*, 
      so that is what I test for now.  I found a case (when testing 
      SpecConstr) where I had a Rec like this:
      	rec { lvl = foo Nothing
      	      foo = ...
      	        RULE foo Nothing = ...
         	    }
      
      Even if lvl has a data type, it's much better to make lvl the loop
      breaker, not foo, so that foo's RULE is visible in lvl's RHS.
      1dca1587
    • simonpj@microsoft.com's avatar
      Comments only · beade0a1
      simonpj@microsoft.com authored
      beade0a1
    • simonpj@microsoft.com's avatar
      Make SpecConstr work right for nullary constructors · 4d109022
      simonpj@microsoft.com authored
      For totally stupid reasons, SpecConstr didn't work for the (particularly
      easy) case of nullary constructors like True and False.  I just had some
      equations in the wrong order, so that a Var case came first, which 
      matches a nullary constructor, with the constructor-application case
      afterwards.
      
      The fix is easy.  I did a bit of refactoring at the same time.
      4d109022
    • wolfgang.thaller@gmx.net's avatar
      x86_64 NCG: fix register usage for CALLs · 561e5742
      wolfgang.thaller@gmx.net authored
      For varargs calls, CALL reads the %al register; record that fact for the benefit of the
      register allocator.
      (There was a previous attempt to do this, but it was broken.)
      561e5742
    • sof@galois.com's avatar
      Add Win32/configure.ac to the mix · 3495dc88
      sof@galois.com authored
      3495dc88
    • andy@galois.com's avatar
      TickBox representation change · 8100cd43
      andy@galois.com authored
      This changes the internal representation of TickBoxes,
      from
              Note (TickBox "module" n)  <expr>
      into
      
              case tick<module,n> of
                _ -> <expr>
      
      tick has type :: #State #World, when the module and tick numbe
      are stored inside IdInfo.
      
      Binary tick boxes change from
      
               Note (BinaryTickBox "module" t f) <expr>
      
      into
      
                btick<module,t,f> <expr>
      
      btick has type :: Bool -> Bool, with the module and tick number
      stored inside IdInfo.
      8100cd43
  12. 01 Nov, 2006 1 commit
  13. 29 Nov, 2006 1 commit
  14. 28 Nov, 2006 2 commits
  15. 27 Nov, 2006 1 commit
  16. 24 Nov, 2006 2 commits
  17. 20 Nov, 2006 1 commit
    • wolfgang.thaller@gmx.net's avatar
      i386-darwin: disable use of code stubs for dynamic linking · 5cfeedcc
      wolfgang.thaller@gmx.net authored
      We can't use lazy binding for tail-calls accross shared libraries, because dyld
      will crash due to incorrect stack layout. We can't get the stack alignment right for
      both cross-library tailcalls and foreign calls, so we have to bypass the stub code altogether
      and load the address to branch to from the non-lazy pointer table.
      5cfeedcc
  18. 22 Oct, 2006 2 commits
  19. 25 Nov, 2006 2 commits