1. 02 Jun, 2008 1 commit
  2. 29 May, 2008 1 commit
    • dias@eecs.harvard.edu's avatar
      Replacing copyins and copyouts with data-movement instructions · 0d80489c
      dias@eecs.harvard.edu authored
      o Moved BlockId stuff to a new file to avoid module recursion
      o Defined stack areas for parameter-passing locations and spill slots
      o Part way through replacing copy in and copy out nodes
        - added movement instructions for stack pointer
        - added movement instructions for call and return parameters
          (but not with the proper calling conventions)
      o Inserting spills and reloads for proc points is now procpoint-aware
        (it was relying on the presence of a CopyIn node as a proxy for
         procpoint knowledge)
      o Changed ZipDataflow to expect AGraphs (instead of being polymorphic in
         the type of graph)
      0d80489c
  3. 28 May, 2008 1 commit
    • Simon Marlow's avatar
      Use MD5 checksums for recompilation checking (fixes #1372, #1959) · 526c3af1
      Simon Marlow authored
      This is a much more robust way to do recompilation checking.  The idea
      is to create a fingerprint of the ABI of an interface, and track
      dependencies by recording the fingerprints of ABIs that a module
      depends on.  If any of those ABIs have changed, then we need to
      recompile.
      
      In bug #1372 we weren't recording dependencies on package modules,
      this patch fixes that by recording fingerprints of package modules
      that we depend on.  Within a package there is still fine-grained
      recompilation avoidance as before.
      
      We currently use MD5 for fingerprints, being a good compromise between
      efficiency and security.  We're not worried about attackers, but we
      are worried about accidental collisions.
      
      All the MD5 sums do make interface files a bit bigger, but compile
      times on the whole are about the same as before.  Recompilation
      avoidance should be a bit more accurate than in 6.8.2 due to fixing
      #1959, especially when using -O.
      526c3af1
  4. 04 May, 2008 1 commit
  5. 26 Apr, 2008 2 commits
  6. 17 Mar, 2008 2 commits
  7. 17 Jan, 2008 1 commit
  8. 10 Oct, 2007 1 commit
    • Dan Licata's avatar
      View patterns, record wildcards, and record puns · 6a05ec5e
      Dan Licata authored
      This patch implements three new features:
      * view patterns (syntax: expression -> pat in a pattern)
      * working versions of record wildcards and record puns
      See the manual for detailed descriptions.
      
      Other minor observable changes:
      * There is a check prohibiting local fixity declarations
        when the variable being fixed is not defined in the same let
      * The warn-unused-binds option now reports warnings for do and mdo stmts
      
      Implementation notes: 
      
      * The pattern renamer is now in its own module, RnPat, and the
      implementation is now in a CPS style so that the correct context is
      delivered to pattern expressions.
      
      * These features required a fairly major upheaval to the renamer.
      Whereas the old version used to collect up all the bindings from a let
      (or top-level, or recursive do statement, ...) and put them into scope
      before renaming anything, the new version does the collection as it
      renames.  This allows us to do the right thing with record wildcard
      patterns (which need to be expanded to see what names should be
      collected), and it allows us to implement the desired semantics for view
      patterns in lets.  This change had a bunch of domino effects brought on
      by fiddling with the top-level renaming.
      
      * Prior to this patch, there was a tricky bug in mkRecordSelId in HEAD,
      which did not maintain the invariant necessary for loadDecl.  See note
      [Tricky iface loop] for details.
      6a05ec5e
  9. 21 Sep, 2007 1 commit
  10. 04 Sep, 2007 1 commit
  11. 03 Sep, 2007 1 commit
  12. 01 Sep, 2007 1 commit
  13. 17 Jul, 2007 1 commit
    • andy@galois.com's avatar
      Adding pushing of hpc translation status through hi files. · c1681a73
      andy@galois.com authored
      Now, if a single module *anywhere* on the module tree is built with
      -fhpc, the binary will enable reading/writing of <bin>.tix.
      
      Previously, you needed to compile Main to allow coverage to operate.
      
      This changes the file format for .hi files; you will need to recompile every library.
      c1681a73
  14. 11 Jul, 2007 1 commit
  15. 02 Jul, 2007 1 commit
  16. 22 May, 2007 1 commit
  17. 15 May, 2007 1 commit
  18. 11 May, 2007 2 commits
  19. 04 May, 2007 1 commit
  20. 25 Apr, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Retain inline-pragma information on unfoldings in interface files · d33c0b24
      simonpj@microsoft.com authored
      	WARNING: this patch changes interface-file formats slightly
      	 	 you will need to recompile your libraries
      
      Duncan Coutts wanted to export a function that has a NOINLNE pragma
      in a local let-defintion.  This works fine within a module, but was 
      not surviving across the interface-file serialisation.
      
      http://www.haskell.org/pipermail/glasgow-haskell-users/2007-March/012171.html
      
      Regardless of whether or not he's doing something sensible, it seems
      reasonable to try to retain local-binder IdInfo across interface files.
      This initial patch just retains inline-pragma info, on the grounds that
      other IdInfo can be re-inferred at the inline site.
      
      Interface files get a tiny bit bigger, but it seesm slight.
      
      d33c0b24
  21. 08 Jan, 2007 1 commit
  22. 29 Nov, 2006 1 commit
    • 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
  23. 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
  24. 13 Oct, 2006 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Keep track of family instance modules · 311b1cdf
      chak@cse.unsw.edu.au. authored
      - Now each modules carries
        (1) a flag saying whether it contains family instance declarations and
        (2) a list of all modules further down in the import tree that contain
            family instance declarations.
        (The information is split into these two parts for the exact same reasons why
        the info about orphan modules is split, too.)
      - This is the first step to *optimised* overlap checking of family instances
        coming from imported modules.
      
      *** WARNING: This patch changes the interface file format! ***
      ***          Recompile libraries and stage2 from scratch!  ***
      311b1cdf
  25. 11 Oct, 2006 2 commits
    • 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
    • Simon Marlow's avatar
      Interface file optimisation and removal of nameParent · b00b5bc0
      Simon Marlow authored
      This large commit combines several interrelated changes:
      
        - IfaceSyn now contains actual Names rather than the special
          IfaceExtName type.  The binary interface file contains
          a symbol table of Names, where each entry is a (package,
          ModuleName, OccName) triple.  Names in the IfaceSyn point
          to entries in the symbol table.
      
          This reduces the size of interface files, which should
          hopefully improve performance (not measured yet).
      
          The toIfaceXXX functions now do not need to pass around
          a function from Name -> IfaceExtName, which makes that
          code simpler.
      
        - Names now do not point directly to their parents, and the
          nameParent operation has gone away.  It turned out to be hard to
          keep this information consistent in practice, and the parent info
          was only valid in some Names.  Instead we made the following
          changes:
      
          * ImportAvails contains a new field 
                imp_parent :: NameEnv AvailInfo
            which gives the family info for any Name in scope, and
            is used by the renamer when renaming export lists, amongst
            other things.  This info is thrown away after renaming.
      
          * The mi_ver_fn field of ModIface now maps to
            (OccName,Version) instead of just Version, where the
            OccName is the parent name.  This mapping is used when
            constructing the usage info for dependent modules.
            There may be entries in mi_ver_fn for things that are not in
            scope, whereas imp_parent only deals with in-scope things.
      
          * The md_exports field of ModDetails now contains
            [AvailInfo] rather than NameSet.  This gives us
            family info for the exported names of a module.
      
      Also:
      
         - ifaceDeclSubBinders moved to IfaceSyn (seems like the
           right place for it).
      
         - heavily refactored renaming of import/export lists.
      
         - Unfortunately external core is now broken, as it relied on
           IfaceSyn.  It requires some attention.
      b00b5bc0
  26. 10 Oct, 2006 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Rough matches for family instances · 2a8cdc3a
      chak@cse.unsw.edu.au. authored
      - Class and type family instances just got a lot more similar.
      - FamInst, like Instance, now has a rough match signature.  The idea is the
        same: if the rough match doesn't match, there is no need to pull in the while
        tycon describing the instance (from a lazily read iface).
      - IfaceFamInst changes in a similar way and the list of all IFaceFamInsts is
        now written into the binary iface (as for class instances), as deriving it
        from the tycon (as before) would render the whole rough matching useless.
      - As a result of this, the plumbing of class instances and type instances 
        through the various environments, ModIface, ModGuts, and ModDetails is now
        almost the same.  (The remaining difference are mostly because the dfun of a
        class instance is an Id, but type instance refer to a TyCon, not an Id.)
      
      *** WARNING: The interface file format changed! ***
      ***	     Rebuild from scratch.		***
      2a8cdc3a
  27. 29 Sep, 2006 1 commit
  28. 20 Sep, 2006 5 commits
    • chak@cse.unsw.edu.au.'s avatar
      Import/export of data constructors in family instances · a835e9fa
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:50:42 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Import/export of data constructors in family instances
        Tue Sep 12 13:54:37 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Import/export of data constructors in family instances
          - Data constructors of a data/newtype family F can be exported and imported
            by writing F(..) or F(ConName).
          - This appears the most natural from a user's persepctive - although, it has a
            slightly different flavour than similar import/exports items for closed data 
            types.  The data constructors denoted by F(..) vary in dependence on the 
            visible data instances.
          - This has been non-trivial to achieve as RnNames derives its knowledge of what
            sub-binders an F(..) item exports/imports from the relation specified by 
            Name.nameParent - ie, the constructors of a data/newtype instance need to 
            have the family name (not the internal name of the representation tycon) as 
            their parent.
          
          *** WARNING: This patched changes the iface format! ***
          ***          Please re-compile from scratch!	    ***
      a835e9fa
    • chak@cse.unsw.edu.au.'s avatar
      Introduce coercions for data instance decls · 909d2dd8
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:07:30 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Introduce coercions for data instance decls
        Tue Aug 22 20:33:46 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Introduce coercions for data instance decls
          - data instance declarations implicitly generate a coercion moving between the
            representation type and family instance type.
          - The coercion is *implicitly* generated when type checking both source and 
            ifaces.  Ie, we don't safe it in ifaces - this is really exactly as newtype 
            coercions are handled.
          - The previous addition of the instance types to DataCons has been moved to 
            the representation TyCon.  This is more efficient as it is shared between all
            constructors of one representation tycon and it also gathers everything about
            data instances (family tycon, instance types, and coercion) in one place: the
            algTcParent field of TyCon.
          - The coercion is already used in the datacon wrappers, but not yet during type
            checking pattern matching of indexed data types.
          - The code has only been lightly tested, but doesn't seem to break features not
            related to indexed types.  For indexed data types only the pattern matching
            tc code (in TcPat.tcConPat) and some well-formedness checks are still 
            missing.  And there will surely be some bugs to fix.  (newtypes still require
            some more work.)
          
          	   ** WARNING: Interface file format changed! **
          	   **          Recompile from scratch!        **
      909d2dd8
    • chak@cse.unsw.edu.au.'s avatar
      Extend TyCons and DataCons to represent data instance decls · 80c89b80
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 19:05:18 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Extend TyCons and DataCons to represent data instance decls
        Fri Aug 18 19:11:37 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Extend TyCons and DataCons to represent data instance decls
          - This is a faily involved patch, but it is not entirely complete:
            + The data con wrapper code for instance data cons needs to apply the
              coercions (which we still have to generate).
            + There are still bugs, but it doesn't seem to affect the compilation of
              code that doesn't use type families.
          
          ** WARNING: Yet another change of the iface format.  **
          **          Recompile everything.                    **
      80c89b80
    • chak@cse.unsw.edu.au.'s avatar
      Extend Class.Class to include the TyCons of ATs · bb106f28
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 18:58:51 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Extend Class.Class to include the TyCons of ATs
        Wed Aug 16 16:15:31 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Extend Class.Class to include the TyCons of ATs
      bb106f28
    • chak@cse.unsw.edu.au.'s avatar
      Extended TyCon and friends to represent family declarations · e8a591c1
      chak@cse.unsw.edu.au. authored
      Mon Sep 18 18:50:35 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Extended TyCon and friends to represent family declarations
        Tue Aug 15 16:52:31 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
          * Extended TyCon and friends to represent family declarations
      e8a591c1
  29. 18 Sep, 2006 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Remove argument variance info of tycons · 3e0b6b25
      chak@cse.unsw.edu.au. authored
      Fri Aug 11 13:53:24 EDT 2006  Manuel M T Chakravarty <chak@cse.unsw.edu.au>
        * Remove argument variance info of tycons
        - Following SPJ's suggestion, this patch removes the variance information from
          type constructors.  This information was computed, but never used.
        
        ** WARNING: This patch changes the format of interface files **
        **          You will need to rebuild from scratch.           **
      3e0b6b25
  30. 04 Aug, 2006 1 commit
  31. 25 Jul, 2006 1 commit
    • Simon Marlow's avatar
      Generalise Package Support · 61d2625a
      Simon Marlow authored
      This patch pushes through one fundamental change: a module is now
      identified by the pair of its package and module name, whereas
      previously it was identified by its module name alone.  This means
      that now a program can contain multiple modules with the same name, as
      long as they belong to different packages.
      
      This is a language change - the Haskell report says nothing about
      packages, but it is now necessary to understand packages in order to
      understand GHC's module system.  For example, a type T from module M
      in package P is different from a type T from module M in package Q.
      Previously this wasn't an issue because there could only be a single
      module M in the program.
      
      The "module restriction" on combining packages has therefore been
      lifted, and a program can contain multiple versions of the same
      package.
      
      Note that none of the proposed syntax changes have yet been
      implemented, but the architecture is geared towards supporting import
      declarations qualified by package name, and that is probably the next
      step.
      
      It is now necessary to specify the package name when compiling a
      package, using the -package-name flag (which has been un-deprecated).
      Fortunately Cabal still uses -package-name.
      
      Certain packages are "wired in".  Currently the wired-in packages are:
      base, haskell98, template-haskell and rts, and are always referred to
      by these versionless names.  Other packages are referred to with full
      package IDs (eg. "network-1.0").  This is because the compiler needs
      to refer to entities in the wired-in packages, and we didn't want to
      bake the version of these packages into the comiler.  It's conceivable
      that someone might want to upgrade the base package independently of
      GHC.
      
      Internal changes:
      
        - There are two module-related types:
      
              ModuleName      just a FastString, the name of a module
              Module          a pair of a PackageId and ModuleName
      
          A mapping from ModuleName can be a UniqFM, but a mapping from Module
          must be a FiniteMap (we provide it as ModuleEnv).
      
        - The "HomeModules" type that was passed around the compiler is now
          gone, replaced in most cases by the current package name which is
          contained in DynFlags.  We can tell whether a Module comes from the
          current package by comparing its package name against the current
          package.
      
        - While I was here, I changed PrintUnqual to be a little more useful:
          it now returns the ModuleName that the identifier should be qualified
          with according to the current scope, rather than its original
          module.  Also, PrintUnqual tells whether to qualify module names with
          package names (currently unused).
      
      Docs to follow.
      61d2625a
  32. 23 Jun, 2006 1 commit