This project is mirrored from 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. 30 Oct, 2001 1 commit
  2. 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
      None of these changes are HEADworthy.
  3. 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
      	    "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
      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,
      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
      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!
  4. 24 Aug, 2001 1 commit
  5. 09 May, 2001 1 commit
  6. 17 Apr, 2001 1 commit
  7. 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.
  8. 06 Mar, 2001 1 commit
  9. 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:
          = \ 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 ;
  10. 01 Mar, 2001 1 commit
  11. 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
      	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
            That same parameter is scrutinised by a case somewhere in 
            the RHS of the function
          b) At a recursive call, one or more parameters has an unfolding
             that is an explicit constructor application
            That same parameter is scrutinised by a case somewhere in 
            the RHS of the function
            Those are the only uses of the parameter