Skip to content
  • Simon Peyton Jones's avatar
    [project @ 2001-09-26 15:12:33 by simonpj] · e0d750be
    Simon Peyton Jones 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!