1. 13 Mar, 2009 1 commit
    • Simon Marlow's avatar
      Instead of a separate context-switch flag, set HpLim to zero · 304e7fb7
      Simon Marlow authored
      This reduces the latency between a context-switch being triggered and
      the thread returning to the scheduler, which in turn should reduce the
      cost of the GC barrier when there are many cores.
      
      We still retain the old context_switch flag which is checked at the
      end of each block of allocation.  The idea is that setting HpLim may
      fail if the the target thread is modifying HpLim at the same time; the
      context_switch flag is a fallback.  It also allows us to "context
      switch soon" without forcing an immediate switch, which can be costly.
      304e7fb7
  2. 11 Mar, 2009 1 commit
  3. 06 Mar, 2009 1 commit
    • Simon Marlow's avatar
      Partial fix for #2917 · 1b62aece
      Simon Marlow authored
       - add newAlignedPinnedByteArray# for allocating pinned BAs with
         arbitrary alignment
      
       - the old newPinnedByteArray# now aligns to 16 bytes
      
      Foreign.alloca will use newAlignedPinnedByteArray#, and so might end
      up wasting less space than before (we used to align to 8 by default).
      Foreign.allocaBytes and Foreign.mallocForeignPtrBytes will get 16-byte
      aligned memory, which is enough to avoid problems with SSE
      instructions on x86, for example.
      
      There was a bug in the old newPinnedByteArray#: it aligned to 8 bytes,
      but would have failed if the header was not a multiple of 8
      (fortunately it always was, even with profiling).  Also we
      occasionally wasted some space unnecessarily due to alignment in
      allocatePinned().
      
      I haven't done anything about Foreign.malloc/mallocBytes, which will
      give you the same alignment guarantees as malloc() (8 bytes on
      Linux/x86 here).
      1b62aece
  4. 19 Feb, 2009 2 commits
  5. 27 Jan, 2009 1 commit
  6. 07 Jan, 2009 1 commit
  7. 10 Dec, 2008 1 commit
  8. 14 Aug, 2008 1 commit
    • dias@eecs.harvard.edu's avatar
      Merging in the new codegen branch · 176fa33f
      dias@eecs.harvard.edu authored
      This merge does not turn on the new codegen (which only compiles
      a select few programs at this point),
      but it does introduce some changes to the old code generator.
      
      The high bits:
      1. The Rep Swamp patch is finally here.
         The highlight is that the representation of types at the
         machine level has changed.
         Consequently, this patch contains updates across several back ends.
      2. The new Stg -> Cmm path is here, although it appears to have a
         fair number of bugs lurking.
      3. Many improvements along the CmmCPSZ path, including:
         o stack layout
         o some code for infotables, half of which is right and half wrong
         o proc-point splitting
      176fa33f
  9. 07 Nov, 2008 1 commit
  10. 06 Nov, 2008 2 commits
  11. 10 Oct, 2008 1 commit
  12. 08 Oct, 2008 1 commit
  13. 19 Sep, 2008 1 commit
  14. 12 Aug, 2008 1 commit
  15. 30 Jul, 2008 1 commit
  16. 28 Jul, 2008 1 commit
    • Simon Marlow's avatar
      Change the calling conventions for unboxed tuples slightly · 02620e7c
      Simon Marlow authored
      When returning an unboxed tuple with a single non-void component, we
      now use the same calling convention as for returning a value of the
      same type as that component.  This means that the return convention
      for IO now doesn't vary depending on the platform, which make some
      parts of the RTS simpler, and fixes a problem I was having with making
      the FFI work in unregisterised GHCi (the byte-code compiler makes
      some assumptions about calling conventions to keep things simple).
      02620e7c
  17. 10 Jul, 2008 2 commits
  18. 09 Jul, 2008 1 commit
  19. 17 Jun, 2008 1 commit
  20. 03 Jun, 2008 1 commit
  21. 16 Apr, 2008 3 commits
  22. 14 Jun, 2008 1 commit
  23. 26 Apr, 2008 1 commit
  24. 24 Apr, 2008 1 commit
  25. 17 Apr, 2008 1 commit
  26. 02 Apr, 2008 1 commit
    • Simon Marlow's avatar
      Do not #include external header files when compiling via C · c245355e
      Simon Marlow authored
      This has several advantages:
      
       - -fvia-C is consistent with -fasm with respect to FFI declarations:
         both bind to the ABI, not the API.
      
       - foreign calls can now be inlined freely across module boundaries, since
         a header file is not required when compiling the call.
      
       - bootstrapping via C will be more reliable, because this difference
         in behavour between the two backends has been removed.
      
      There is one disadvantage:
      
       - we get no checking by the C compiler that the FFI declaration
         is correct.
      
      So now, the c-includes field in a .cabal file is always ignored by
      GHC, as are header files specified in an FFI declaration.  This was
      previously the case only for -fasm compilations, now it is also the
      case for -fvia-C too.
      c245355e
  27. 01 Jan, 2008 1 commit
  28. 04 Dec, 2007 1 commit
  29. 18 Oct, 2007 1 commit
  30. 11 Oct, 2007 1 commit
    • Simon Marlow's avatar
      Add a proper write barrier for MVars · 1ed01a87
      Simon Marlow authored
      Previously MVars were always on the mutable list of the old
      generation, which meant every MVar was visited during every minor GC.
      With lots of MVars hanging around, this gets expensive.  We addressed
      this problem for MUT_VARs (aka IORefs) a while ago, the solution is to
      use a traditional GC write-barrier when the object is modified.  This
      patch does the same thing for MVars.
      
      TVars are still done the old way, they could probably benefit from the
      same treatment too.
      1ed01a87
  31. 05 Sep, 2007 2 commits
  32. 04 Sep, 2007 1 commit
  33. 29 Aug, 2007 1 commit
  34. 20 Aug, 2007 1 commit