1. 06 Sep, 2011 2 commits
    • batterseapower's avatar
      Implement -XConstraintKind · 9729fe7c
      batterseapower authored
      Basically as documented in http://hackage.haskell.org/trac/ghc/wiki/KindFact,
      this patch adds a new kind Constraint such that:
      
        Show :: * -> Constraint
        (?x::Int) :: Constraint
        (Int ~ a) :: Constraint
      
      And you can write *any* type with kind Constraint to the left of (=>):
      even if that type is a type synonym, type variable, indexed type or so on.
      
      The following (somewhat related) changes are also made:
       1. We now box equality evidence. This is required because we want
          to give (Int ~ a) the *lifted* kind Constraint
       2. For similar reasons, implicit parameters can now only be of
          a lifted kind. (?x::Int#) => ty is now ruled out
       3. Implicit parameter constraints are now allowed in superclasses
          and instance contexts (this just falls out as OK with the new
          constraint solver)
      
      Internally the following major changes were made:
       1. There is now no PredTy in the Type data type. Instead
          GHC checks the kind of a type to figure out if it is a predicate
       2. There is now no AClass TyThing: we represent classes as TyThings
          just as a ATyCon (classes had TyCons anyway)
       3. What used to be (~) is now pretty-printed as (~#). The box
          constructor EqBox :: (a ~# b) -> (a ~ b)
       4. The type LCoercion is used internally in the constraint solver
          and type checker to represent coercions with free variables
          of type (a ~ b) rather than (a ~# b)
      9729fe7c
    • Simon Marlow's avatar
      fix the eager-blackholing check, which I inadvertently broke in · 6ffaf6ff
      Simon Marlow authored
      1c2f8953 (symptom was broken
      biographical profiling, see #5451).
      6ffaf6ff
  2. 25 Aug, 2011 8 commits
  3. 03 Aug, 2011 1 commit
  4. 28 Jul, 2011 4 commits
  5. 07 Jul, 2011 1 commit
  6. 30 Jun, 2011 1 commit
  7. 04 Apr, 2011 1 commit
  8. 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
  9. 07 Jul, 2009 1 commit
  10. 18 Dec, 2008 1 commit
  11. 26 Nov, 2008 2 commits
  12. 13 Oct, 2008 1 commit
    • dias@eecs.harvard.edu's avatar
      Big collection of patches for the new codegen branch. · e6243a81
      dias@eecs.harvard.edu authored
      o Fixed bug that emitted the copy-in code for closure entry
        in the wrong place -- at the initialization of the closure.
      o Refactored some of the closure entry code.
      o Added code to check that no LocalRegs are live-in to a procedure
         -- trip up some buggy programs earlier
      o Fixed environment bindings for thunks
         -- we weren't (re)binding the free variables in a thunk
      o Fixed a bug in proc-point splitting that dropped some updates
        to the entry block in a procedure.
      o Fixed improper calls to code that generates CmmLit's for strings
      o New invariant on cg_loc in CgIdInfo: the expression is always tagged
      o Code to load free vars on entry to a thunk was (wrongly) placed before
        the heap check.
      o Some of the StgCmm code was redundantly passing around Id's
        along with CgIdInfo's; no more.
      o Initialize the LocalReg's that point to a closure before allocating and
        initializing the closure itself -- otherwise, we have problems with
        recursive closure bindings
      o BlockEnv and BlockSet types are now abstract.
      o Update frames:
        - push arguments in Old call area
        - keep track of the return sp in the FCode monad
        - keep the return sp in every call, tail call, and return
            (because it might be different at different call sites,
             e.g. tail calls to the gc after a heap check are performed
                  before pushing the update frame)
        - set the sp appropriately on returns and tail calls
      o Reduce call, tail call, and return to a single LastCall node
      o Added slow entry code, using different calling conventions on entry and tail call
      o More fixes to the calling convention code.
        The tricky stuff is all about the closure environment: it must be passed in R1,
        but in non-closures, there is no such argument, so we can't treat all arguments
        the same way: the closure environment is special. Maybe the right step forward
        would be to define a different calling convention for closure arguments.
      o Let-no-escapes need to be emitted out-of-line -- otherwise, we drop code.
      o Respect RTS requirement of word alignment for pointers
        My stack allocation can pack sub-word values into a single word on the stack,
        but it wasn't requiring word-alignment for pointers. It does now,
        by word-aligning both pointer registers and call areas.
      o CmmLint was over-aggresively ruling out non-word-aligned memory references,
        which may be kosher now that we can spill small values into a single word.
      o Wrong label order on a conditional branch when compiling switches.
      o void args weren't dropped in many cases.
        To help prevent this kind of mistake, I defined a NonVoid wrapper,
        which I'm applying only to Id's for now, although there are probably
        other good candidates.
      o A little code refactoring: separate modules for procpoint analysis splitting, 
        stack layout, and building infotables.
      o Stack limit check: insert along with the heap limit check, using a symbolic
        constant (a special CmmLit), then replace it when the stack layout is known.
      o Removed last node: MidAddToContext 
      o Adding block id as a literal: means that the lowering of the calling conventions
        no longer has to produce labels early, which was inhibiting common-block elimination.
        Will also make it easier for the non-procpoint-splitting path.
      o Info tables: don't try to describe the update frame!
      o Over aggressive use of NonVoid!!!!
        Don't drop the non-void args before setting the type of the closure!!!
      o Sanity checking:
        Added a pass to stub dead dead slots on the stack
        (only ~10 lines with the dataflow framework)
      o More sanity checking:
        Check that incoming pointer arguments are non-stubbed.
        Note: these checks are still subject to dead-code removal, but they should
        still be quite helpful.
      o Better sanity checking: why stop at function arguments?
        Instead, in mkAssign, check that _any_ assignment to a pointer type is non-null
        -- the sooner the crash, the easier it is to debug.
        Still need to add the debugging flag to turn these checks on explicitly.
      o Fixed yet another calling convention bug.
        This time, the calls to the GC were wrong. I've added a new convention
        for GC calls and invoked it where appropriate.
        We should really straighten out the calling convention stuff:
          some of the code (and documentation) is spread across the compiler,
          and there's some magical use of the node register that should really
          be handled (not avoided) by calling conventions.
      o Switch bug: the arms in mkCmmLitSwitch weren't returning to a single join point.
      o Environment shadowing problem in Stg->Cmm:
        When a closure f is bound at the top-level, we should not bind f to the
        node register on entry to the closure.
        Why? Because if the body of f contains a let-bound closure g that refers
        to f, we want to make sure that it refers to the static closure for f.
        Normally, this would all be fine, because when we compile a closure,
        we rebind free variables in the environment. But f doesn't look like
        a free variable because it's a static value. So, the binding for f
        remains in the environment when we compile g, inconveniently referring
        to the wrong thing.
        Now, I bind the variable in the local environment only if the closure is not
        bound at the top level. It's still okay to make assumptions about the
        node holding the closure environment; we just won't find the binding
        in the environment, so code that names the closure will now directly
        get the label of the static closure, not the node register holding a
        pointer to the static closure.
      o Don't generate bogus Cmm code containing SRTs during the STG -> Cmm pass!
        The tables made reference to some labels that don't exist when we compute and
        generate the tables in the back end.
      o Safe foreign calls need some special treatment (at least until we have the integrated
        codegen). In particular:
        o they need info tables
        o they are not procpoints -- the successor had better be in the same procedure
        o we cannot (yet) implement the calling conventions early, which means we have
          to carry the calling-conv info all the way to the end
      o We weren't following the old convention when registering a module.
        Now, we use update frames to push any new modules that have to be registered
        and enter the youngest one on the stack.
        We also use the update frame machinery to specify that the return should pop
        the return address off the stack.
      o At each safe foreign call, an infotable must be at the bottom of the stack,
        and the TSO->sp must point to it.
      o More problems with void args in a direct call to a function:
        We were checking the args (minus voids) to check whether the call was saturated,
        which caused problems when the function really wasn't saturated because it
        took an extra void argument.
      o Forgot to distinguish integer != from floating != during Stg->Cmm
      o Updating slotEnv and areaMap to include safe foreign calls
        The dataflow analyses that produce the slotEnv and areaMap give
        results for each basic block, but we also need the results for
        a safe foreign call, which is a middle node.
        After running the dataflow analysis, we have another pass that
        updates the results to includ any safe foreign calls.
      o Added a static flag for the debugging technique that inserts
        instructions to stub dead slots on the stack and crashes when
        a stubbed value is loaded into a pointer-typed LocalReg.
      o C back end expects to see return continuations before their call sites.
        Sorted the flowgraphs appropriately after splitting.
      o PrimOp calling conventions are special -- unlimited registers, no stack
        Yet another calling convention...
      o More void value problems: if the RHS of a case arm is a void-typed variable,
        don't try to return it.
      o When calling some primOp, they may allocate memory; if so, we need to
        do a heap check when we return from the call.
      e6243a81
  13. 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
  14. 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
  15. 18 Sep, 2008 1 commit
  16. 20 Jul, 2008 1 commit
  17. 12 Apr, 2008 1 commit
  18. 15 Mar, 2008 1 commit
  19. 04 Sep, 2007 1 commit
  20. 03 Sep, 2007 1 commit
  21. 01 Sep, 2007 1 commit
  22. 31 Jul, 2007 1 commit
    • Clemens Fruhwirth's avatar
      Change the strategy to determine dynamic data access · 81b2276f
      Clemens Fruhwirth authored
      Instead of attaching the information whether a Label is going to be
      accessed dynamically or not (distinction between IdLabel/DynLabel and
      additional flags in ModuleInitLabel and PlainModuleInitLabel), we hand
      dflags through the CmmOpt monad and the NatM monad. Before calling
      labelDynamic in PositionIndependentCode, we extract thisPackage from
      dflags and supply the current package to labelDynamic, so it can take
      this information into account instead of extracting it from the labels
      itself. This simplifies a lot of code in codeGen that just hands
      through this_pkg.
      81b2276f
  23. 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
  24. 02 Jul, 2007 1 commit
    • Michael D. Adams's avatar
      Multiple improvements to CPS algorithm. · a2d5d3c9
      Michael D. Adams authored
      These include:
       - Stack size detection now includes function arguments.
       - Stack size detection now avoids stack checks just because of
         the GC block.
       - A CmmCall followed by a CmmBranch will no longer generate an extra
         continuation consisting just of the brach.
       - Multiple CmmCall/CmmBranch pairs that all go to the same place
         will try to use the same continuation.  If they can't (because
         the return value signature is different), adaptor block are built.
       - Function entry statements are now in a separate block.
         (Fixed bug with branches to the entry block having unintended effects.)
       - Other changes that I can't recall right now.
      a2d5d3c9
  25. 27 Jun, 2007 2 commits
  26. 11 Jan, 2007 1 commit
    • chevalier@alum.wellesley.edu's avatar
      Remove bogus assertion in getCallMethod · c0987224
      chevalier@alum.wellesley.edu authored
      With my as-yet-uncommitted changes to the demand analyzer, code got
       generated for some programs that caused this assertion to fail.  The
       transformation I was doing was correct; it was the assertion that
       wasn't. So, the assertion is removed.
       
       This is actually Simon PJ's patch rather than mine, but I noticed that
       it wasn't checked in and it seems completely safe to do so.
      c0987224
  27. 18 Oct, 2006 1 commit
    • simonpj@microsoft.com's avatar
      Add the primitive type Any, and use it for Dynamics · c128930d
      simonpj@microsoft.com authored
      GHC's code generator can only enter a closure if it's guaranteed
      not to be a function.  In the Dynamic module, we were using the 
      type (forall a.a) as the type to which the dynamic type was unsafely
      cast:
      	type Obj = forall a.a
      
      Gut alas this polytype was sometimes instantiated to (), something 
      like this (it only bit when profiling was enabled)
      	let y::() = dyn ()
      	in (y `cast` ..) p q
      As a result, an ASSERT in ClosureInfo fired (hooray).
      
      I've tided this up by making a new, primitive, lifted type Any, and
      arranging that Dynamic uses Any, thus:
      	type Obj = ANy
      
      While I was at it, I also arranged that when the type checker instantiates 
      un-constrained type variables, it now instantiates them to Any, not ()
      	e.g.  length Any []
      
      [There remains a Horrible Hack when we want Any-like things at arbitrary 
      kinds.  This essentially never happens, but see comments with 
      TysPrim.mkAnyPrimTyCon.]
      
      Anyway, this fixes Trac #905
      c128930d