This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 18 Mar, 2002 1 commit
  2. 04 Mar, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-03-04 17:01:26 by simonmar] · 0171936c
      simonmar authored
      Binary Interface Files - stage 1
      --------------------------------
      
      This commit changes the default interface file format from text to
      binary, in order to improve compilation performace.
      
      To view an interface file, use 'ghc --show-iface Foo.hi'.
      
      utils/Binary.hs is the basic Binary I/O library, based on the nhc98
      binary I/O library but much stripped-down and working in terms of
      bytes rather than bits, and with some special features for GHC: it
      remembers which Module is being emitted to avoid dumping too many
      qualified names, and it keeps track of a "dictionary" of FastStrings
      so that we don't dump the same FastString more than once into the
      binary file.  I'll make a generic version of this for the libraries at
      some point.
      
      main/BinIface.hs contains most of the Binary instances.  Some
      instances are in the same module as the data type (RdrName, Name,
      OccName in particular).  Most instances were generated using a
      modified version of DrIFT, which I'll commit later.  However, editing
      them by hand isn't hard (certainly easier than modifying
      ParseIface.y).
      
      The first thing in a binary interface is the interface version, so
      nice error messages will be generated if the binary format changes and
      you still have old interfaces lying around.  The version also now
      includes the "way" as an extra sanity check.
      
      Other changes
      -------------
      
      I don't like the way FastStrings contain both hashed strings (with
      O(1) comparison) and literal C strings (with O(n) comparison).  So as
      a first step to separating these I made serveral "literal" type
      strings into hashed strings.  SLIT() still generates a literal, and
      now FSLIT() generates a hashed string.  With DEBUG on, you'll get a
      warning if you try to compare any SLIT()s with anything, and the
      compiler will fall over if you try to dump any literal C strings into
      an interface file (usually indicating a use of SLIT() which should be
      FSLIT()).
      
      mkSysLocal no longer re-encodes its FastString argument each time it
      is called.
      
      I also fixed the -pgm options so that the argument can now optionally
      be separted from the option.
      
      Bugfix: PrelNames declared Names for several comparison primops, eg.
      eqCharName, eqIntName etc. but these had different uniques from the
      real primop names.  I've moved these to PrimOps and defined them using
      mkPrimOpIdName instead, and deleted some for which we don't have real
      primops (Manuel: please check that things still work for you after
      this change).
      0171936c
  3. 01 Nov, 2001 2 commits
    • simonpj's avatar
      [project @ 2001-11-01 13:20:42 by simonpj] · 2ca9a768
      simonpj authored
      wibble
      2ca9a768
    • simonpj's avatar
      [project @ 2001-11-01 13:20:05 by simonpj] · 51666a19
      simonpj authored
      ---------------------------------------
      	Fix a unboxed-binding bug in SpecConstr
      	---------------------------------------
      
      	[HEAD only]
      
      This fixes a rather obscure bug in the constructor
      specialiser discovered by Ralf Hinze.  It was
      generating a specialised version of the function
      with no arguments --- and the function returned an
      unboxed type.
      
      Solution: same as for worker-wrapper; add a dummy
      argument.
      
      Several files are affected because I added
      CoreUtils.mkPiTypes, as a useful helper function.
      51666a19
  4. 30 Oct, 2001 1 commit
  5. 25 Oct, 2001 1 commit
    • sof's avatar
      [project @ 2001-10-25 02:13:10 by sof] · 9e933350
      sof authored
      - Pet peeve removal / code tidyup, replaced various sub-optimal
        uses of 'length' with something a bit better, i.e., replaced
        the following patterns
      
         *  length as `cmpOp` length bs
         *  length as `cmpOp` val   -- incl. uses where val == 1 and val == 0
         *  {take,drop,splitAt} (length as) bs
         *  length [ () | pat <- as ]
      
        with uses of misc Util functions.
      
        I'd be surprised if there's a noticeable reduction in running
        times as a result of these changes, but every little bit helps.
      
        [ The changes have been tested wrt testsuite/ - I'm seeing a couple
          of unexpected breakages coming from CorePrep, but I'm currently
          assuming that these are due to other recent changes. ]
      
      - compMan/CompManager.lhs: restored 4.08 compilability + some code
        cleanup.
      
      None of these changes are HEADworthy.
      9e933350
  6. 26 Sep, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-09-26 15:12:33 by simonpj] · e0d750be
      simonpj authored
      ------------------
      		Simon's big commit
      		------------------
      
      This commit, which I don't think I can sensibly do piecemeal, consists
      of the things I've been doing recently, mainly directed at making
      Manuel, George, and Marcin happier with RULES.
      
      
      Reogranise the simplifier
      ~~~~~~~~~~~~~~~~~~~~~~~~~
      1. The simplifier's environment is now an explicit parameter.  This
      makes it a bit easier to figure out where it is going.
      
      2. Constructor arguments can now be arbitrary expressions, except
      when the application is the RHS of a let(rec).  This makes it much
      easier to match rules like
      
      	RULES
      	    "foo"  f (h x, g y) = f' x y
      
      In the simplifier, it's Simplify.mkAtomicArgs that ANF-ises a
      constructor application where necessary.  In the occurrence analyser,
      there's a new piece of context info (OccEncl) to say whether a
      constructor app is in a place where it should be in ANF.  (Unless
      it knows this it'll give occurrence info which will inline the
      argument back into the constructor app.)
      
      3. I'm experimenting with doing the "float-past big lambda" transformation
      in the full laziness pass, rather than mixed in with the simplifier (was
      tryRhsTyLam).
      
      4.  Arrange that
      	case (coerce (S,T) (x,y)) of ...
      will simplify.  Previous it didn't.
      A local change to CoreUtils.exprIsConApp_maybe.
      
      5. Do a better job in CoreUtils.exprEtaExpandArity when there's an
      error function in one branch.
      
      
      Phase numbers, RULES, and INLINE pragmas
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      1.  Phase numbers decrease from N towards zero (instead of increasing).
      This makes it easier to add new earlier phases, which is what users want
      to do.
      
      2.  RULES get their own phase number, N, and are disabled in phases before N.
      
      e.g. 	{-# RULES "foo" [2] forall x y.  f (x,y) = f' x y #-}
      
      Note the [2], which says "only active in phase 2 and later".
      
      3.  INLINE and NOINLINE pragmas have a phase number to.  This is now treated
      in just the same way as the phase number on RULE; that is, the Id is not inlined
      in phases earlier than N.  In phase N and later the Id *may* be inlined, and
      here is where INLINE and NOINLINE differ: INLNE makes the RHS look small, so
      as soon as it *may* be inlined it probably *will* be inlined.
      
      The syntax of the phase number on an INLINE/NOINLINE pragma has changed to be
      like the RULES case (i.e. in square brackets).  This should also make sure
      you examine all such phase numbers; many will need to change now the numbering
      is reversed.
      
      Inlining Ids is no longer affected at all by whether the Id appears on the
      LHS of a rule.  Now it's up to the programmer to put a suitable INLINE/NOINLINE
      pragma to stop it being inlined too early.
      
      
      Implementation notes:
      
      *  A new data type, BasicTypes.Activation says when a rule or inline pragma
      is active.   Functions isAlwaysActive, isNeverActive, isActive, do the
      obvious thing (all in BasicTypes).
      
      * Slight change in the SimplifierSwitch data type, which led to a lot of
      simplifier-specific code moving from CmdLineOpts to SimplMonad; a Good Thing.
      
      * The InlinePragma in the IdInfo of an Id is now simply an Activation saying
      when the Id can be inlined.  (It used to be a rather bizarre pair of a
      Bool and a (Maybe Phase), so this is much much easier to understand.)
      
      * The simplifier has a "mode" environment switch, replacing the old
      black list.  Unfortunately the data type decl has to be in
      CmdLineOpts, because it's an argument to the CoreDoSimplify switch
      
          data SimplifierMode = SimplGently | SimplPhase Int
      
      Here "gently" means "no rules, no inlining".   All the crucial
      inlining decisions are now collected together in SimplMonad
      (preInlineUnconditionally, postInlineUnconditionally, activeInline,
      activeRule).
      
      
      Specialisation
      ~~~~~~~~~~~~~~
      1.  Only dictionary *functions* are made INLINE, not dictionaries that
      have no parameters.  (This inline-dictionary-function thing is Marcin's
      idea and I'm still not sure whether it's a good idea.  But it's definitely
      a Bad Idea when there are no arguments.)
      
      2.  Be prepared to specialise an INLINE function: an easy fix in
      Specialise.lhs
      
      But there is still a problem, which is that the INLINE wins
      at the call site, so we don't use the specialised version anyway.
      I'm still unsure whether it makes sense to SPECIALISE something
      you want to INLINE.
      
      
      
      
      
      Random smaller things
      ~~~~~~~~~~~~~~~~~~~~~~
      
      * builtinRules (there was only one, but may be more) in PrelRules are now
        incorporated.   They were being ignored before...
      
      * OrdList.foldOL -->  OrdList.foldrOL, OrdList.foldlOL
      
      * Some tidying up of the tidyOpenTyVar, tidyTyVar functions.  I've
        forgotten exactly what!
      e0d750be
  7. 24 Aug, 2001 1 commit
  8. 09 May, 2001 1 commit
  9. 17 Apr, 2001 1 commit
  10. 08 Mar, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-03-08 12:07:38 by simonpj] · 51a571c0
      simonpj authored
      --------------------
      	A major hygiene pass
      	--------------------
      
      1. The main change here is to
      
      	Move what was the "IdFlavour" out of IdInfo,
      	and into the varDetails field of a Var
      
         It was a mess before, because the flavour was a permanent attribute
         of an Id, whereas the rest of the IdInfo was ephemeral.  It's
         all much tidier now.
      
         Main places to look:
      
      	   Var.lhs	Defn of VarDetails
      	   IdInfo.lhs	Defn of GlobalIdDetails
      
         The main remaining infelicity is that SpecPragmaIds are right down
         in Var.lhs, which seems unduly built-in for such an ephemeral thing.
         But that is no worse than before.
      
      
      2. Tidy up the HscMain story a little.  Move mkModDetails from MkIface
         into CoreTidy (where it belongs more nicely)
      
         This was partly forced by (1) above, because I didn't want to make
         DictFun Ids into a separate kind of Id (which is how it was before).
         Not having them separate means we have to keep a list of them right
         through, rather than pull them out of the bindings at the end.
      
      3. Add NameEnv as a separate module (to join NameSet).
      
      4. Remove unnecessary {-# SOURCE #-} imports from FieldLabel.
      51a571c0
  11. 06 Mar, 2001 1 commit
  12. 05 Mar, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-03-05 12:45:45 by simonpj] · e6dff21d
      simonpj authored
      Improve SpecConstr
      
      This commit fixes SpecConstr so that it can see the effect of
      enclosing case expressions properly.  That's what the "cons" field
      in ScEnv is for.
      
      As a result, consider this function:
      
        data AccessPath = Cont  AccessPath
      		  | Value Int
      
        demandAll n ap@(Cont (Value (I# i1)))
          = case n of
      	0     -> i1
      	other -> i1 +# demandAll (n-1) ap
      
      SpecConstr now successfully compiles it to this:
      
        $s$wdemandAll
          = \ i1 :: PrelGHC.Int# sc :: PrelGHC.Int# ->
            case sc of ds {
      	0 -> i1;
      	__DEFAULT -> PrelGHC.+# i1 (Foo.$s$wdemandAll i1 (PrelGHC.-# ds 1))
            }
      
      with the rule
      
       "SC:$wdemandAll1" __forall i1 :: PrelGHC.Int# ,
      			    sc :: PrelGHC.Int# .
      	Foo.$wdemandAll sc (Foo.$wCont (Foo.$wValue (PrelBase.$wI# i1)))
      	= Foo.$s$wdemandAll i1 sc ;
      e6dff21d
  13. 01 Mar, 2001 1 commit
  14. 28 Feb, 2001 1 commit
    • simonpj's avatar
      [project @ 2001-02-28 11:48:34 by simonpj] · 12e6a9a5
      simonpj authored
      Add most of the code for constructor specialisation.  The comment
      below is reproduced from specialise/SpecConstr.lhs.
      
      It doesn't quite work properly yet, because we need to have 
      rules in scope in a recursive function's own RHS, and that
      entails a bit of fiddling I havn't yet completed.  But SpecConstr
      itself is a nice neat 250 lines of code.
      
      -----------------------------------------------------
      			Game plan
      -----------------------------------------------------
      
      Consider
      	drop n []     = []
      	drop 0 xs     = []
      	drop n (x:xs) = drop (n-1) xs
      
      After the first time round, we could pass n unboxed.  This happens in
      numerical code too.  Here's what it looks like in Core:
      
      	drop n xs = case xs of
      		      []     -> []
      		      (y:ys) -> case n of 
      				  I# n# -> case n# of
      					     0 -> []
      					     _ -> drop (I# (n# -# 1#)) xs
      
      Notice that the recursive call has an explicit constructor as argument.
      Noticing this, we can make a specialised version of drop
      	
      	RULE: drop (I# n#) xs ==> drop' n# xs
      
      	drop' n# xs = let n = I# n# in ...orig RHS...
      
      Now the simplifier will apply the specialisation in the rhs of drop', giving
      
      	drop' n# xs = case xs of
      		      []     -> []
      		      (y:ys) -> case n# of
      				  0 -> []
      				  _ -> drop (n# -# 1#) xs
      
      Much better!  
      
      We'd also like to catch cases where a parameter is carried along unchanged,
      but evaluated each time round the loop:
      
      	f i n = if i>0 || i>n then i else f (i*2) n
      
      Here f isn't strict in n, but we'd like to avoid evaluating it each iteration.
      In Core, by the time we've w/wd (f is strict in i) we get
      
      	f i# n = case i# ># 0 of
      		   False -> I# i#
      		   True  -> case n of n' { I# n# ->
      			    case i# ># n# of
      				False -> I# i#
      				True  -> f (i# *# 2#) n'
      
      At the call to f, we see that the argument, n is know to be (I# n#),
      and n is evaluated elsewhere in the body of f, so we can play the same
      trick as above.  However we don't want to do that if the boxed version
      of n is needed (else we'd avoid the eval but pay more for re-boxing n).
      So in this case we want that the *only* uses of n are in case statements.
      
      
      So we look for
      
      * A self-recursive function.  Ignore mutual recursion for now, 
        because it's less common, and the code is simpler for self-recursion.
      
      * EITHER
      
         a) At a recursive call, one or more parameters is an explicit 
            constructor application
      	AND
            That same parameter is scrutinised by a case somewhere in 
            the RHS of the function
      
        OR
      
          b) At a recursive call, one or more parameters has an unfolding
             that is an explicit constructor application
      	AND
            That same parameter is scrutinised by a case somewhere in 
            the RHS of the function
      	AND
            Those are the only uses of the parameter
      12e6a9a5