1. 11 Apr, 2011 1 commit
  2. 24 Jan, 2011 1 commit
    • Simon Marlow's avatar
      Merge in new code generator branch. · 889c084e
      Simon Marlow authored
      This changes the new code generator to make use of the Hoopl package
      for dataflow analysis.  Hoopl is a new boot package, and is maintained
      in a separate upstream git repository (as usual, GHC has its own
      lagging darcs mirror in http://darcs.haskell.org/packages/hoopl).
      
      During this merge I squashed recent history into one patch.  I tried
      to rebase, but the history had some internal conflicts of its own
      which made rebase extremely confusing, so I gave up. The history I
      squashed was:
      
        - Update new codegen to work with latest Hoopl
        - Add some notes on new code gen to cmm-notes
        - Enable Hoopl lag package.
        - Add SPJ note to cmm-notes
        - Improve GC calls on new code generator.
      
      Work in this branch was done by:
         - Milan Straka <fox@ucw.cz>
         - John Dias <dias@cs.tufts.edu>
         - David Terei <davidterei@gmail.com>
      
      Edward Z. Yang <ezyang@mit.edu> merged in further changes from GHC HEAD
      and fixed a few bugs.
      889c084e
  3. 29 Mar, 2010 1 commit
    • Simon Marlow's avatar
      New implementation of BLACKHOLEs · 5d52d9b6
      Simon Marlow authored
      This replaces the global blackhole_queue with a clever scheme that
      enables us to queue up blocked threads on the closure that they are
      blocked on, while still avoiding atomic instructions in the common
      case.
      
      Advantages:
      
       - gets rid of a locked global data structure and some tricky GC code
         (replacing it with some per-thread data structures and different
         tricky GC code :)
      
       - wakeups are more prompt: parallel/concurrent performance should
         benefit.  I haven't seen anything dramatic in the parallel
         benchmarks so far, but a couple of threading benchmarks do improve
         a bit.
      
       - waking up a thread blocked on a blackhole is now O(1) (e.g. if
         it is the target of throwTo).
      
       - less sharing and better separation of Capabilities: communication
         is done with messages, the data structures are strictly owned by a
         Capability and cannot be modified except by sending messages.
      
       - this change will utlimately enable us to do more intelligent
         scheduling when threads block on each other.  This is what started
         off the whole thing, but it isn't done yet (#3838).
      
      I'll be documenting all this on the wiki in due course.
      5d52d9b6
  4. 31 Dec, 2009 1 commit
  5. 06 Nov, 2009 1 commit
    • Ben.Lippmeier@anu.edu.au's avatar
      * Refactor CLabel.RtsLabel to CLabel.CmmLabel · a02e7f40
      Ben.Lippmeier@anu.edu.au authored
      The type of the CmmLabel ctor is now
        CmmLabel :: PackageId -> FastString -> CmmLabelInfo -> CLabel
        
       - When you construct a CmmLabel you have to explicitly say what
         package it is in. Many of these will just use rtsPackageId, but
         I've left it this way to remind people not to pretend labels are
         in the RTS package when they're not. 
         
       - When parsing a Cmm file, labels that are not defined in the 
         current file are assumed to be in the RTS package. 
         
         Labels imported like
            import label
         are assumed to be in a generic "foreign" package, which is different
         from the current one.
         
         Labels imported like
            import "package-name" label
         are marked as coming from the named package.
         
         This last one is needed for the integer-gmp library as we want to
         refer to labels that are not in the same compilation unit, but
         are in the same non-rts package.
         
         This should help remove the nasty #ifdef __PIC__ stuff from
         integer-gmp/cbits/gmp-wrappers.cmm
         
      a02e7f40
  6. 18 Oct, 2009 1 commit
  7. 30 Sep, 2009 1 commit
  8. 31 Mar, 2009 1 commit
  9. 18 Dec, 2008 1 commit
  10. 17 Dec, 2008 1 commit
  11. 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
  12. 18 Nov, 2008 1 commit
    • Simon Marlow's avatar
      Add optional eager black-holing, with new flag -feager-blackholing · d600bf7a
      Simon Marlow authored
      Eager blackholing can improve parallel performance by reducing the
      chances that two threads perform the same computation.  However, it
      has a cost: one extra memory write per thunk entry.  
      
      To get the best results, any code which may be executed in parallel
      should be compiled with eager blackholing turned on.  But since
      there's a cost for sequential code, we make it optional and turn it on
      for the parallel package only.  It might be a good idea to compile
      applications (or modules) with parallel code in with
      -feager-blackholing.
      
      ToDo: document -feager-blackholing.
      d600bf7a
  13. 03 May, 2008 1 commit
  14. 12 Apr, 2008 1 commit
  15. 04 Jan, 2008 1 commit
  16. 04 Sep, 2007 1 commit
  17. 03 Sep, 2007 1 commit
  18. 01 Sep, 2007 1 commit
  19. 27 Jul, 2007 1 commit
    • Simon Marlow's avatar
      Pointer Tagging · 6015a94f
      Simon Marlow authored
        
      This patch implements pointer tagging as per our ICFP'07 paper "Faster
      laziness using dynamic pointer tagging".  It improves performance by
      10-15% for most workloads, including GHC itself.
      
      The original patches were by Alexey Rodriguez Yakushev
      <mrchebas@gmail.com>, with additions and improvements by me.  I've
      re-recorded the development as a single patch.
      
      The basic idea is this: we use the low 2 bits of a pointer to a heap
      object (3 bits on a 64-bit architecture) to encode some information
      about the object pointed to.  For a constructor, we encode the "tag"
      of the constructor (e.g. True vs. False), for a function closure its
      arity.  This enables some decisions to be made without dereferencing
      the pointer, which speeds up some common operations.  In particular it
      enables us to avoid costly indirect jumps in many cases.
      
      More information in the commentary:
      
      http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/PointerTagging
      6015a94f
  20. 02 Jul, 2007 1 commit
  21. 27 Jun, 2007 2 commits
  22. 10 May, 2007 1 commit
  23. 07 Feb, 2007 1 commit
    • chevalier@alum.wellesley.edu's avatar
      Lightweight ticky-ticky profiling · 5ddee764
      chevalier@alum.wellesley.edu authored
      The following changes restore ticky-ticky profiling to functionality
      from its formerly bit-rotted state. Sort of. (It got bit-rotted as part
      of the switch to the C-- back-end.)
      
      The way that ticky-ticky is supposed to work is documented in Section 5.7
      of the GHC manual (though the manual doesn't mention that it hasn't worked
      since sometime around 6.0, alas). Changes from this are as follows (which
      I'll document on the wiki):
      
      * In the past, you had to build all of the libraries with way=t in order to
      use ticky-ticky, because it entailed a different closure layout. No longer.
      You still need to do make way=t in rts/ in order to build the ticky RTS,
      but you should now be able to mix ticky and non-ticky modules.
      
      * Some of the counters that worked in the past aren't implemented yet.
      I was originally just trying to get entry counts to work, so those should
      be correct. The list of counters was never documented in the first place,
      so I hope it's not too much of a disaster that some don't appear anymore.
      Someday, someone (perhaps me) should document all the counters and what 
      they do. For now, all of the counters are either accurate (or at least as
      accurate as they always were), zero, or missing from the ticky profiling
      report altogether.
      
      This hasn't been particularly well-tested, but these changes shouldn't
      affect anything except when compiling with -fticky-ticky (famous last
      words...)
      
      Implementation details:
      
      I got rid of StgTicky.h, which in the past had the macros and declarations 
      for all of the ticky counters. Now, those macros are defined in Cmm.h.
      StgTicky.h was still there for inclusion in C code. Now, any remaining C
      code simply cannot call the ticky macros -- or rather, they do call those
      macros, but from the perspective of C code, they're defined as no-ops. 
      (This shouldn't be too big a problem.)
      
      I added a new file TickyCounter.h that has all the declarations for ticky
      counters, as well as dummy macros for use in C code. Someday, these 
      declarations should really be automatically generated, since they need
      to be kept consistent with the macros defined in Cmm.h.
      
      Other changes include getting rid of the header that was getting added to
      closures before, and getting rid of various code having to do with eager
      blackholing and permanent indirections (the changes under compiler/ 
      and rts/Updates.*).
      5ddee764
  24. 11 Oct, 2006 1 commit
    • Simon Marlow's avatar
      Module header tidyup, phase 1 · 49c98d14
      Simon Marlow authored
      This patch is a start on removing import lists and generally tidying
      up the top of each module.  In addition to removing import lists:
      
         - Change DATA.IOREF -> Data.IORef etc.
         - Change List -> Data.List etc.
         - Remove $Id$
         - Update copyrights
         - Re-order imports to put non-GHC imports last
         - Remove some unused and duplicate imports
      49c98d14
  25. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
      0065d5ab
  26. 18 May, 2005 2 commits
  27. 17 May, 2005 1 commit
  28. 21 Apr, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-04-21 15:28:20 by simonmar] · effd3425
      simonmar authored
      SMP: thunks get an extra header word so that the payload doesn't
      occupy the same space as the updated value.  This is the sum total of
      the changes to compiler/, which are pleasingly few.
      effd3425
  29. 31 Mar, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-03-31 10:16:33 by simonmar] · 853e20a3
      simonmar authored
      Tweaks to get the GHC sources through Haddock.  Doesn't quite work
      yet, because Haddock complains about the recursive modules.  Haddock
      needs to understand SOURCE imports (it can probably just ignore them
      as a first attempt).
      853e20a3
  30. 18 Mar, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-03-18 13:37:27 by simonmar] · d1c1b7d0
      simonmar authored
      Flags cleanup.
      
      Basically the purpose of this commit is to move more of the compiler's
      global state into DynFlags, which is moving in the direction we need
      to go for the GHC API which can have multiple active sessions
      supported by a single GHC instance.
      
      Before:
      
      $ grep 'global_var' */*hs | wc -l
           78
      
      After:
      
      $ grep 'global_var' */*hs | wc -l
           27
      
      Well, it's an improvement.  Most of what's left won't really affect
      our ability to host multiple sessions.
      
      Lots of static flags have become dynamic flags (yay!).  Notably lots
      of flags that we used to think of as "driver" flags, like -I and -L,
      are now dynamic.  The most notable static flags left behind are the
      "way" flags, eg. -prof.  It would be nice to fix this, but it isn't
      urgent.
      
      On the way, lots of cleanup has happened.  Everything related to
      static and dynamic flags lives in StaticFlags and DynFlags
      respectively, and they share a common command-line parser library in
      CmdLineParser.  The flags related to modes (--makde, --interactive
      etc.) are now private to the front end: in fact private to Main
      itself, for now.
      d1c1b7d0
  31. 08 Dec, 2004 1 commit
  32. 26 Nov, 2004 1 commit
    • simonmar's avatar
      [project @ 2004-11-26 16:19:45 by simonmar] · ef5b4b14
      simonmar authored
      Further integration with the new package story.  GHC now supports
      pretty much everything in the package proposal.
      
        - GHC now works in terms of PackageIds (<pkg>-<version>) rather than
          just package names.  You can still specify package names without
          versions on the command line, as long as the name is unambiguous.
      
        - GHC understands hidden/exposed modules in a package, and will refuse
          to import a hidden module.  Also, the hidden/eposed status of packages
          is taken into account.
      
        - I had to remove the old package syntax from ghc-pkg, backwards
          compatibility isn't really practical.
      
        - All the package.conf.in files have been rewritten in the new syntax,
          and contain a complete list of modules in the package.  I've set all
          the versions to 1.0 for now - please check your package(s) and fix the
          version number & other info appropriately.
      
        - New options:
      
      	-hide-package P    sets the expose flag on package P to False
      	-ignore-package P  unregisters P for this compilation
      
      	For comparison, -package P sets the expose flag on package P
              to True, and also causes P to be linked in eagerly.
      
              -package-name is no longer officially supported.  Unofficially, it's
      	a synonym for -ignore-package, which has more or less the same effect
      	as -package-name used to.
      
      	Note that a package may be hidden and yet still be linked into
      	the program, by virtue of being a dependency of some other package.
      	To completely remove a package from the compiler's internal database,
              use -ignore-package.
      
      	The compiler will complain if any two packages in the
              transitive closure of exposed packages contain the same
              module.
      
      	You *must* use -ignore-package P when compiling modules for
              package P, if package P (or an older version of P) is already
              registered.  The compiler will helpfully complain if you don't.
      	The fptools build system does this.
      
         - Note: the Cabal library won't work yet.  It still thinks GHC uses
           the old package config syntax.
      
      Internal changes/cleanups:
      
         - The ModuleName type has gone away.  Modules are now just (a
           newtype of) FastStrings, and don't contain any package information.
           All the package-related knowledge is in DynFlags, which is passed
           down to where it is needed.
      
         - DynFlags manipulation has been cleaned up somewhat: there are no
           global variables holding DynFlags any more, instead the DynFlags
           are passed around properly.
      
         - There are a few less global variables in GHC.  Lots more are
           scheduled for removal.
      
         - -i is now a dynamic flag, as are all the package-related flags (but
           using them in {-# OPTIONS #-} is Officially Not Recommended).
      
         - make -j now appears to work under fptools/libraries/.  Probably
           wouldn't take much to get it working for a whole build.
      ef5b4b14
  33. 30 Sep, 2004 1 commit
    • simonpj's avatar
      [project @ 2004-09-30 10:35:15 by simonpj] · 23f40f0e
      simonpj authored
      ------------------------------------
      	Add Generalised Algebraic Data Types
      	------------------------------------
      
      This rather big commit adds support for GADTs.  For example,
      
          data Term a where
       	  Lit :: Int -> Term Int
      	  App :: Term (a->b) -> Term a -> Term b
      	  If  :: Term Bool -> Term a -> Term a
      	  ..etc..
      
          eval :: Term a -> a
          eval (Lit i) = i
          eval (App a b) = eval a (eval b)
          eval (If p q r) | eval p    = eval q
          		    | otherwise = eval r
      
      
      Lots and lots of of related changes throughout the compiler to make
      this fit nicely.
      
      One important change, only loosely related to GADTs, is that skolem
      constants in the typechecker are genuinely immutable and constant, so
      we often get better error messages from the type checker.  See
      TcType.TcTyVarDetails.
      
      There's a new module types/Unify.lhs, which has purely-functional
      unification and matching for Type. This is used both in the typechecker
      (for type refinement of GADTs) and in Core Lint (also for type refinement).
      23f40f0e
  34. 13 Aug, 2004 1 commit
  35. 17 Nov, 2003 1 commit
  36. 30 Oct, 2003 1 commit
    • simonpj's avatar
      [project @ 2003-10-30 16:01:49 by simonpj] · 57573e7e
      simonpj authored
      This commit does a long-overdue tidy-up
      
      * Remove PprType (gets rid of one more bunch of hi-boot files)
      
      * Put pretty-printing for types in TypeRep
      
      * Make a specialised pretty-printer for Types, rather than
        converting to IfaceTypes and printing those
      57573e7e
  37. 14 May, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-05-14 09:13:52 by simonmar] · 7a236a56
      simonmar authored
      Change the way SRTs are represented:
      
      Previously, the SRT associated with a function or thunk would be a
      sub-list of the enclosing top-level function's SRT.  But this approach
      can lead to lots of duplication: if a CAF is referenced in several
      different thunks, then it may appear several times in the SRT.
      Let-no-escapes compound the problem, because the occurrence of a
      let-no-escape-bound variable would expand to all the CAFs referred to
      by the let-no-escape.
      
      The new way is to describe the SRT associated with a function or thunk
      as a (pointer+offset,bitmap) pair, where the pointer+offset points
      into some SRT table (the enclosing function's SRT), and the bitmap
      indicates which entries in this table are "live" for this closure.
      The bitmap is stored in the 16 bits previously used for the length
      field, but this rarely overflows.  When it does overflow, we store the
      bitmap externally in a new "SRT descriptor".
      
      Now the enclosing SRT can be a set, hence eliminating the duplicates.
      
      Also, we now have one SRT per top-level function in a recursive group,
      where previously we used to have one SRT for the whole group.  This
      helps keep the size of SRTs down.
      
      Bottom line: very little difference most of the time.  GHC itself got
      slightly smaller.  One bad case of a module in GHC which had a huge
      SRT has gone away.
      
      While I was in the area:
      
        - Several parts of the back-end require bitmaps.  Functions for
          creating bitmaps are now centralised in the Bitmap module.
      
        - We were trying to be independent of word-size in a couple of
          places in the back end, but we've now abandoned that strategy so I
          simplified things a bit.
      7a236a56
  38. 11 Dec, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-12-11 15:36:20 by simonmar] · 0bffc410
      simonmar authored
      Merge the eval-apply-branch on to the HEAD
      ------------------------------------------
      
      This is a change to GHC's evaluation model in order to ultimately make
      GHC more portable and to reduce complexity in some areas.
      
      At some point we'll update the commentary to describe the new state of
      the RTS.  Pending that, the highlights of this change are:
      
        - No more Su.  The Su register is gone, update frames are one
          word smaller.
      
        - Slow-entry points and arg checks are gone.  Unknown function calls
          are handled by automatically-generated RTS entry points (AutoApply.hc,
          generated by the program in utils/genapply).
      
        - The stack layout is stricter: there are no "pending arguments" on
          the stack any more, the stack is always strictly a sequence of
          stack frames.
      
          This means that there's no need for LOOKS_LIKE_GHC_INFO() or
          LOOKS_LIKE_STATIC_CLOSURE() any more, and GHC doesn't need to know
          how to find the boundary between the text and data segments (BIG WIN!).
      
        - A couple of nasty hacks in the mangler caused by the neet to
          identify closure ptrs vs. info tables have gone away.
      
        - Info tables are a bit more complicated.  See InfoTables.h for the
          details.
      
        - As a side effect, GHCi can now deal with polymorphic seq.  Some bugs
          in GHCi which affected primitives and unboxed tuples are now
          fixed.
      
        - Binary sizes are reduced by about 7% on x86.  Performance is roughly
          similar, some programs get faster while some get slower.  I've seen
          GHCi perform worse on some examples, but haven't investigated
          further yet (GHCi performance *should* be about the same or better
          in theory).
      
        - Internally the code generator is rather better organised.  I've moved
          info-table generation from the NCG into the main codeGen where it is
          shared with the C back-end; info tables are now emitted as arrays
          of words in both back-ends.  The NCG is one step closer to being able
          to support profiling.
      
      This has all been fairly thoroughly tested, but no doubt I've messed
      up the commit in some way.
      0bffc410