1. 02 Jul, 2007 1 commit
  2. 03 Jul, 2007 1 commit
  3. 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
  4. 27 Jun, 2007 6 commits
  5. 26 Jun, 2007 1 commit
  6. 21 Jun, 2007 1 commit
  7. 19 Jun, 2007 1 commit
  8. 25 May, 2007 1 commit
    • Michael D. Adams's avatar
      Moved global register saving from the backend to codeGen · bd3a364d
      Michael D. Adams authored
      This frees the Cmm data type from keeping a list of live global registers
      in CmmCall which helps prepare for the CPS conversion phase.
      
      CPS conversion does its own liveness analysis and takes input that should
      not directly refer to parameter registers (e.g. R1, F5, D3, L2).  Since
      these are the only things which could occur in the live global register
      list, CPS conversion makes that field of the CmmCall constructor obsolite.
      
      Once the CPS conversion pass is fully implemented, global register saving
      will move from codeGen into the CPS pass.  Until then, this patch
      is worth scrutinizing and testing to ensure it doesn't cause any performance
      or correctness problems as the code passed to the backends by the CPS
      converting will look very similar to the code that this patch makes codeGen
      pass to the backend.
      bd3a364d
  9. 22 May, 2007 1 commit
    • Michael D. Adams's avatar
      Make CmmProc take CmmFormals as argument · 418175d3
      Michael D. Adams authored
      Since a CmmCall returns CmmFormals which may include
      global registers (and indeed one place in the code
      returns the results of a CmmCall into BaseReg) and
      since CPS conversion will change those return slots
      into formal arguments for the continuation of the call,
      CmmProc has to have CmmFormals for the formal arguments.
      
      Oddly, the old code never made use of procedure arguments
      so this change only effects the types and not any of the code.
      (Because [] is both of type [LocalReg] and CmmFormals.)
      418175d3
  10. 08 Jun, 2007 1 commit
  11. 22 Jun, 2007 1 commit
  12. 13 Jun, 2007 1 commit
    • Simon Marlow's avatar
      FIX #1418 (partially) · 23e5985c
      Simon Marlow authored
      When the con_desc field of an info table was made into a relative
      reference, this had the side effect of making the profiling fields
      (closure_desc and closure_type) also relative, but only when compiling
      via C, and the heap profiler was still treating them as absolute,
      leading to crashes when profiling with -hd or -hy.
      
      This patch fixes up the story to be consistent: these fields really
      should be relative (otherwise we couldn't make shared versions of the
      profiling libraries), so I've made them relative and fixed up the RTS
      to know about this.
      23e5985c
  13. 25 May, 2007 1 commit
  14. 21 May, 2007 1 commit
  15. 11 May, 2007 1 commit
  16. 10 May, 2007 1 commit
  17. 09 May, 2007 1 commit
  18. 30 Apr, 2007 1 commit
    • andy@galois.com's avatar
      Changing internal data structures used by Hpc · 55a5d8d9
      andy@galois.com authored
       - .tix files are now a list of MixModule, which contain a hash of the contents of the .mix file.
       - .mix files now have (the same) hash number.
      
      This changes allow different binaries that use the same module compiled in the same way
      to share coverage information.
      55a5d8d9
  19. 27 Apr, 2007 1 commit
  20. 24 Apr, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Make ticky work, at least partly, on 64-bit machines · a01188d1
      simonpj@microsoft.com authored
      The ticky StgEntCounter structure was trying to be clever by using a
      fixed-width 32-bit field for the registeredp value.  But the code generators
      are not up to handling structures packed tightly like this (on a 64-bit
      architecture); result seg-fault on 64-bit.
      
      Really there should be some complaint from the code generators, not simply
      a seg fault.
      
      Anyway I switched to using native words for StgEntCounter fields, and
      now at least it works.
      a01188d1
  21. 08 Mar, 2007 1 commit
    • wolfgang.thaller@gmx.net's avatar
      Make constructor names in info tables position independent · b648333f
      wolfgang.thaller@gmx.net authored
      Info tables, like everything else in the text section, MUST NOT contain
      pointers. A pointer is, by definition, position dependent and is therefore
      fundamentally incompatible with generating position independent code.
      
      Therefore, we have to store an offset from the info label to the string
      instead of the pointer, just as we already did for other things referred
      to by the info table (SRTs, large bitmaps, etc.)
      b648333f
  22. 28 Feb, 2007 1 commit
  23. 20 Feb, 2007 1 commit
    • bjpop@csse.unimelb.edu.au's avatar
      Constructor names in info tables · 7d6dffe5
      bjpop@csse.unimelb.edu.au authored
      This patch adds data constructor names into their info tables. 
      This is useful in the ghci debugger. It replaces the old scheme which
      was based on tracking data con names in the linker. 
      7d6dffe5
  24. 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
  25. 22 Jan, 2007 2 commits
    • Simon Marlow's avatar
      Semi-tagging optimisation · a2d78ebe
      Simon Marlow authored
      In the generated code for case-of-variable, test the tag of the
      scrutinee closure and only enter if it is unevaluated.  Also turn
      *off* vectored returns.
      a2d78ebe
    • Simon Marlow's avatar
      Semi-tagging optimisation · 7f1bc015
      Simon Marlow authored
      In the generated code for case-of-variable, test the tag of the
      scrutinee closure and only enter if it is unevaluated.  Also turn
      *off* vectored returns.
      7f1bc015
  26. 19 Jan, 2007 2 commits
  27. 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
  28. 13 Dec, 2006 1 commit
  29. 09 Dec, 2006 1 commit
  30. 07 Nov, 2006 1 commit
  31. 25 Oct, 2006 1 commit
  32. 24 Oct, 2006 1 commit
    • andy@galois.com's avatar
      Haskell Program Coverage · d5934bbb
      andy@galois.com authored
      This large checkin is the new ghc version of Haskell
      Program Coverage, an expression-level coverage tool for Haskell.
      
      Parts:
      
       - Hpc.[ch] - small runtime support for Hpc; reading/writing *.tix files.
       - Coverage.lhs - Annotates the HsSyn with coverage tickboxes.
        - New Note's in Core,
            - TickBox      -- ticked on entry to sub-expression
            - BinaryTickBox  -- ticked on exit to sub-expression, depending
      	       	     -- on the boolean result.
      
        - New Stg level TickBox (no BinaryTickBoxes, though) 
      
      You can run the coverage tool with -fhpc at compile time. 
      Main must be compiled with -fhpc. 
      				      
      d5934bbb
  33. 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